What the text inside a QR code actually looks like

Nothing in the QR specification says what kind of thing a code contains. The symbol carries text, and the reader decides what to offer based on how that text starts. A string beginning "https://" is treated as a link; one beginning "WIFI:" as network credentials; one beginning "BEGIN:VCARD" as a contact.

This is why behavior varies between readers. The conventions below are widely implemented, but they are conventions, and a reader that does not recognize one falls back to showing you the raw text. That fallback is the reason a malformed contact code displays as a wall of characters rather than failing outright.

Most of these are ordinary URI schemes with their own specifications behind them: tel: is RFC 3966, geo: is RFC 5870, vCard is RFC 6350 and iCalendar is RFC 5545. The two odd ones out, WIFI: and MECARD:, are conventions from the QR world rather than registered schemes, which is precisely why their support is less uniform.

The Wi-Fi payload is a set of semicolon-separated fields, terminated by two semicolons rather than one.

• T is the security type: WPA covers the whole WPA family including WPA2 and WPA3, WEP is the obsolete one, and nopass means an open network.
• S is the network name, exactly as broadcast, character for character.
• P is the password, omitted or left empty for an open network.
• H is true only for a hidden network that does not broadcast its name.

The rule people miss: if the network name or password contains a semicolon, comma, colon, backslash or double quote, that character must be escaped with a backslash. An unescaped semicolon in a password terminates the field early, and the resulting code is well-formed, scannable, and joins the network with the wrong credentials. It fails in the least helpful possible way.

MECARD is compact and was designed for exactly this, which makes it attractive when the code has to stay small. vCard is the general-purpose standard, understood by every address book and every email client, and it is what a downloaded .vcf file contains.

The trade is size against fidelity. vCard is verbose: field names, line breaks and a wrapper, so a contact with a few fields can run to several hundred characters and push the symbol to a version that needs a noticeably larger print. MECARD says the same thing in a fraction of the space but carries fewer fields and is less widely understood outside phone cameras.

• vCard has version dialects. Most phones are happiest with 3.0; 4.0 is the current standard and support for it is less even.
• Phone numbers should be written in full international form, starting with a plus and the country code. A local-format number saved from a scan is unusable the moment either party travels.
• Photos can be embedded, and usually should not be. A base64 image adds thousands of characters, and a QR code has a hard ceiling of a few kilobytes. A link to a page is the practical route to a picture.

These are the differences worth testing for rather than reasoning about, because they change between operating system releases.

• Message payloads. SMSTO: is the most widely honored form. The sms: scheme also exists but platforms have historically disagreed about how a prefilled body is attached, so a code that fills in the message on one phone may open an empty one on another.
• Calendar entries. A bare VEVENT is not universally accepted, and support for saving an event straight from the camera is patchier than for contacts. Test both platforms before committing it to print.
• Email bodies. Anything after the question mark is a query string and must be percent-encoded. A raw space or ampersand truncates the message.
• Plain text. The one format nothing gets wrong, and a reasonable fallback when an action-based payload proves unreliable.

Every character you add makes the grid denser, and past a threshold it steps up a version and each module gets smaller at the same printed size. Structured payloads are where this bites, because a full contact card can be twenty times the length of the link that would do the same job.

So the practical question for anything larger than a short URL is whether the code should carry the data or carry a link to the data. Carrying it means the code works with no network and no server, and can never be changed. Carrying a link means the opposite on both counts.