QR Format Selector

Choose the payload before choosing the picture

A QR symbol is only a transport. A web address, a Wi-Fi join record, a vCard and a calendar event can all look like the same black square while asking the scanner to do different work. Start with the receiving application: a browser can use a URL, an address book can import a vCard, and a calendar needs a VEVENT. A camera that merely displays text has not proved that the intended action occurs.

A decision table makes the trade-off visible

Use URL when one stable destination is enough; it is compact and works in every scanner. Use text for a short instruction that must remain visible without an app. Use Wi-Fi only when the recipient is meant to receive the network name and password. Use vCard for a person or organisation with several fields, and use an event for a timed appointment. The selector puts these choices in a table rather than pretending that one format is universally best.

Work through a real counter-card example

A café wants visitors to open `https://north.example/menu`. That is a 26-character URL and needs no structure beyond a browser action. Replacing it with a vCard containing name, phone, address and URL creates a denser code and asks the user to save a contact before seeing the menu. The useful comparison is not which code has more features; it is whether the first scan reaches the intended task with the fewest unexpected steps.

Structured formats have punctuation rules

A Wi-Fi payload uses fields such as `WIFI:T:WPA;S:Guest;P:tea2026;;`; semicolons and backslashes in a real network name must be escaped. vCard commonly uses CRLF line endings and escaping for commas, semicolons and backslashes. An event needs a start and end time, not a prose date. A QR image can decode perfectly while the receiving app rejects malformed structure, which is why this page distinguishes data grammar from optical readability.

Density is a physical cost

Suppose a short URL fits a 29 by 29 matrix and a full contact record fits 49 by 49. On a 40 mm square, the first has roughly 1.08 mm per matrix cell before the outer margin, while the second has about 0.70 mm. Small cells are more vulnerable to ink spread, glare and camera focus. Shortening a field or using a landing page can be a safer choice than increasing error correction after the label is already too small.

Static and editable are different promises

A normal QR code contains its destination directly. Once printed, an incorrect URL or password requires a replacement print; no browser-only generator can silently alter it later. A redirect URL may be administratively editable, but it also introduces a service and a trust decision. The selector therefore describes a direct URL as a stable payload, not as a guarantee that a future destination remains correct.

What commonly breaks in use

Wi-Fi codes fail when a hidden network flag, security type or escaping is wrong. Contact cards fail when a scanner treats the result as plain text. Event codes fail when a local time is interpreted in an unexpected time zone. URLs fail when the path was mistyped or the printed sign is too small to frame. These are separate failure classes: changing colours cannot repair a bad record, and rewriting a record cannot restore a cropped quiet zone.

A format choice is not an optical test

Choosing URL, Wi-Fi, vCard or VEVENT only establishes the data contract. It does not show whether a printed matrix has enough margin, contrast or physical size for the intended camera. Treat successful import on a test device and successful scanning of the production proof as separate acceptance conditions; a correct record can still be carried by an unreadable symbol.

Make the decision testable

Write the intended result beside the proposed payload before drawing anything. For the café example, the criterion is that a normal phone opens the menu URL and that the printed sign remains readable at the counter distance. For Wi-Fi, the criterion is that an authorised test phone receives the intended network name and joins without editing a field. For a vCard, it is that the contact application imports the expected name and number. This makes format selection an observable decision instead of an argument about which square looks more modern. Keep the source text, generated file and result of that test together. If the purpose changes from opening a menu to collecting a booking, choose a new payload deliberately rather than silently overloading an old code.

Compare the receiving application before comparing payload length

For five table tents pointing to a menu, `https://north.example/menu` is a URL task: the desired first result is a browser page. A Wi-Fi record would disclose a credential, a vCard would ask for a contact save, and a calendar event would create an unrelated appointment. The same distinction applies in reverse: a staff Wi-Fi join needs a `WIFI:` record, not a URL that makes a visitor type a password. QR Code versions run from 21 by 21 modules at Version 1 to 177 by 177 at Version 40, and capacity changes with mode and error-correction level, according to DENSO WAVE: https://www.qrcode.com/en/about/version.html . Density is therefore a consequence to measure after selecting the correct contract, not the reason to misuse a shorter format.

Use a format-specific acceptance test

Write one observable result beside the proposed symbol. For URL, a normal phone must open the named page and the readable address below the code must match. For text, the exact instruction must display offline. For Wi-Fi, a device that has forgotten the network must see the intended SSID and join only with the approved guest credential. For vCard, the contact preview must show the intended fields without importing a private note. For an event, the calendar application must show the intended local date and time. These tests distinguish a good QR image from a good QR workflow. Do not choose a contact card just because it carries more fields, or a direct URL merely because it looks familiar: each sends the scanner to a different receiving application. Where no target application is controlled, a labelled HTTPS page is normally the clearest fallback because it can explain the next step without making the QR itself promise a device-specific action.

One printed square should have one next step

Avoid asking a single code to open a menu, collect a review, join Wi-Fi, and save a contact. Those jobs need different data, different trust signals, and different test conditions. A counter can show two clearly labelled codes when both are genuinely useful; it should not hide multiple actions behind an ambiguous generic landing page. Record the chosen format, payload, human-readable label, output file, and acceptance result together. This makes a later change visible: moving from a static text instruction to a maintained URL is a change of contract, not a cosmetic rewrite. The selector helps choose that contract before artwork is produced.