Make QR Codes for WiFi, WhatsApp and Email

Plain links: the baseline case

The URL code is where to start because its behavior is transparent: encode the address, and scanning opens it in the browser. The quality decisions are practical rather than technical. Use the full address including the protocol — scanners handle complete URLs more predictably than bare domains. Shorten long addresses through a stable shortener or your own redirect if the dense code becomes hard to scan; code density grows with length, and very long URLs produce crowded modules that fail at small print sizes.

The longevity question dominates link codes. A code printed on packaging, signage, or print material lives as long as the material, and the destination must too — a dead link behind a printed code is a small public failure repeated at every scan. Where destinations may change, encode a redirect you control rather than the final page: the code stays valid while the target moves. And always test the finished code on at least two devices — iOS and Android camera apps handle codes with small differences, and a code that scans on your phone is not yet proven on everyone else's. The baseline case teaches the whole discipline: complete data, durable destination, cross-device testing.

WiFi codes: the format that saves the password speech

The WiFi QR format is a standardized payload, not a URL: a structured string carrying the network name, security type, and password in a defined arrangement, which camera apps recognize and offer to join directly — no typing, no spelling aloud, no 'is that a zero or an O.' The format's fields explain its failure modes: the network name must match exactly, including capitalization, because WiFi identifiers are case-sensitive; the security type must match the network's actual configuration; and special characters in passwords — colons, semicolons, backslashes — need escaping in the payload or the string parses wrong.

The password-escaping trap is the classic implementation bug: a network password containing the format's delimiter characters breaks the payload unless escaped, producing a code that scans but fails to connect. Generators that handle escaping automatically remove this whole class of error, which is the honest argument for using one over hand-building the string. Placement guidance follows the social context: a WiFi code belongs where guests sit, printed large enough to scan from a chair, labeled plainly. Security deserves a sentence of honesty: the code exposes the password to anyone who scans it — appropriate for guest networks, inappropriate for the network your business runs on. Guest WiFi and a code are a perfect pairing; primary credentials are not what codes are for.

WhatsApp and messaging codes

Messaging codes use deep-link formats that open a specific conversation rather than an app's home screen. The WhatsApp pattern encodes a phone number in international format — country code, no leading zero, no plus sign or spaces — optionally with a prefilled message, and scanning opens a chat with that number ready to send. The format's sensitivity is in the number: any deviation from international format fails or routes wrongly, so the number deserves the same verification as a payment detail, because it is one.

The prefilled-message option is the conversion lever: a code labeled 'Scan to ask about availability' that opens with the question already drafted removes the composition friction that stops most inquiries. Keep the prefilled text short and editable — it should start the conversation, not script it. Business applications: a counter code for booking questions, a booth code for follow-ups, a service-desk code that routes inquiries to the right number without exposing the number in plain text to every shoulder. The privacy note is genuine: the code publishes the number to every scanner, so use a business number you intend to be reachable, and pair high-volume codes with expectations for response — a code that opens an unanswered chat teaches the wrong lesson about the business.

Email codes: the mailto pattern

Email codes encode a mailto construction: the recipient address, optionally a subject and body, assembled into the format mail apps understand. Scanning opens the user's mail composer addressed and prefilled — the action that used to require reading an address off a sign and typing it without errors. The format handles spaces and special characters through encoding, which generators do automatically; the human decisions are elsewhere.

The practical decisions: a specific subject line routes the message correctly when it lands — 'Question from the trade fair booth' tells the inbox what it is before opening — and a prefilled body can carry the questions you want answered, though brevity preserves editability. The failure modes worth knowing: mailto codes depend on the scanning device having a configured mail app, which phones increasingly do not — the code can produce a 'no mail app' result on devices that live in chat apps. The mitigation is audience knowledge: email codes suit contexts where email is the norm — professional events, printed documents, support materials — while consumer-facing moments may be better served by messaging or form codes. The format is reliable; the channel assumption is the design decision.

The mistakes that produce dead codes

The failure catalog, assembled from the formats above. Data errors first: mistyped URLs, phone numbers in local rather than international format, WiFi names with wrong capitalization — each produces a code that scans perfectly into the wrong or nowhere. Format errors second: unescaped special characters in WiFi passwords, missing protocol in URLs, malformed prefill text — these produce codes that scan into parse failures. Density errors third: payloads so long the code's modules crowd past what small prints resolve, failing not from data but from physics.

The prevention discipline is mechanical and cheap. Verify every input by copy-paste rather than retyping — data entry is where codes die. Generate with tools that apply format rules and escaping automatically. Print at size, then test from the real distance with two devices — the screen preview proves nothing about the poster. And keep an inventory of where codes live and what they encode, because codes outlive memories: the person who printed the window code may not be the person answering why it scans dead next year. Every dead code shares an origin in a skipped check; the checklist exists because the failures are boringly consistent.

The complete creation workflow

The sequence that produces reliable codes of any type. One: choose the payload type for the goal — link, WiFi join, chat open, mail compose — because the type determines everything downstream. Two: assemble the data with copy-paste precision and format-appropriate rules: international phone numbers, exact network names, complete URLs. Three: generate through a tool that handles structure and escaping rather than hand-building strings. Four: test on-device before anything prints — scan, verify the result is the intended action, not merely a scan success.

Five: size and place for the real context — distance, lighting, surface, and a label that states the payoff. Six: decide longevity — stable destination, redirect for moving targets, and a record of what the code encodes and where it lives. The workflow is minutes per code, and it front-loads every failure mode into a cheap test phase rather than discovering them through public dead ends. Codes are small commitments with long lives: a printed square is a promise that a scan will work, months after printing, for people you will never meet. The workflow is how that promise gets kept.

Frequently asked questions