Guides

The generators on this site build; these guides explain. A QR code has two independent layers. The payload is the text encoded inside — a URL, a WIFI: string, a vCard. The symbol is the matrix of dark and light modules drawn from it to ISO/IEC 18004 by a vendored copy of the reference encoder. Most "my code doesn't work" problems are payload problems, so most of the guides are about payloads: what each convention contains, where it is specified, and where the builder stops.

One rule holds everywhere: every payload, version, module count, contrast ratio and print size in the text is computed when the site is built, by the same engine that runs in your browser, on obviously fictional inputs — so the documentation cannot silently disagree with the tool. The link https://example.com/menu is encoded exactly as entered and produces a version 2 symbol of 25×25 modules at error correction M; the renderer then adds 4 modules of quiet zone on every side, so the download is 33 modules across.

A third thread runs through all eight: the engine validates format, not truth. It cannot know whether a WiFi password is correct, a phone number reachable or a URL safe; a wrong password encodes exactly as well as the right one. Each guide says where that line falls, and treats a freshly generated code as untested until a real device has scanned it.

How a QR code encodes data

The foundation for the rest: the payload layer and the symbol layer, the version and module count the encoder chooses — a symbol is 17 + 4 × version modules on a side, two constants derived here from the encoder's own results rather than typed, which is why the version 2 example above is 25 modules wide — and the four error-correction levels, L, M, Q and H. Engine-built payloads show how length drives version, and why a well-formed payload with the wrong contents is the one failure the symbol facts cannot reveal.

Error correction and logos

A centre logo destroys modules that error correction must rebuild, so the engine forces level H whenever one is present and caps the knockout at 16% of the symbol area, with a default of 12%. The cap is decode-tested — the round-trip suite verifies that a worst-case logo at that size still scans — not derived from the theoretical ~30% EC-H recovery ceiling. The guide works the knockout geometry at fixed sizes.

The quiet zone and print size

The 4-module white border the standard requires is rendered into every download and cannot be disabled, because cropping it is the most common self-inflicted scan failure. Then the print-size readout: a PNG download is a square of 512, 1024, 2048 pixels, and the readout divides the width by 300 to give inches and converts to millimetres — 512 px is 1.71 in × 1.71 in (43.3 mm × 43.3 mm) at 300 DPI, and 2048 px is 6.83 in × 6.83 in (173.4 mm × 173.4 mm) at 300 DPI. The readout is arithmetic, not a scanning guarantee.

Contrast and inverted codes

The style panel evaluates a colour pair with the WCAG relative-luminance contrast formula and warns below 4.5:1; black on white assesses at 21.00:1 with no warnings. It warns separately for light-on-dark (inverted) codes, which many scanners reject, however high the ratio. The guide runs the formula on several pairs and prints the engine's own warning text; contrast is necessary, not sufficient.

The WiFi QR payload format

The de-facto WIFI:T:<auth>;S:<ssid>;P:<password>;; convention, documented on the ZXing "Barcode Contents" wiki. A fictional network GuideExample with the password sample-pass-123 becomes WIFI:T:WPA;S:GuideExample;P:sample-pass-123;;. The guide demonstrates the escaping rule — \ ; , : " are backslash-escaped so punctuation in a password cannot corrupt the code — the quoting of all-hex names and passwords, and the mapping of the builder's five security values — and the form's four menu options — onto the convention's three tokens.

vCard contact QR codes

Why the contact generator writes vCard 3.0 (RFC 2426) rather than MECARD — broader field support and better scanner coverage — and what each line of the card contains. Every line ends with CRLF; backslashes, semicolons, commas and line breaks in a name or a company are escaped, shown on invented firms. Cards built on the guide's one fictional contact show how a longer payload drives the version up: a name-and-number card encodes at version 7 and the fully filled card at version 11, both at level M, and the same full card re-rendered at level H climbs to version 15. The encoder picks the smallest version whose capacity holds the payload, so the version rises with length in steps, not with every added field.

URI schemes: mailto, tel, sms and WhatsApp

The single-action codes are URIs in published schemes. mailto: follows RFC 6068, with subject and body percent-encoded; tel: follows RFC 3966 with the number normalised to E.164, so a fictional number typed as +44 20 7946 0100 encodes as tel:+442079460100; sms: follows RFC 5724 in its ?body= form. The guide quotes the engine's own note on pre-filled SMS bodies verbatim and states the WhatsApp Help Center's click-to-chat rule for wa.me links.

Static versus dynamic QR codes

Every code this site produces is static: the data lives in the image itself, with no redirect through our servers. Static codes never expire and cannot be held hostage — but they cannot be edited after printing, and scans cannot be counted. The guide sets out that trade-off plainly, and why this site makes only static codes rather than selling the alternative.

Back to the generators

The main generator covers all 10 content types, and the dedicated pages — WiFi, URL, vCard, email, SMS, phone, WhatsApp, plain text and Google review — each state their convention and carry a worked example from the same engine. How that engine is built and tested is on the methodology page; who publishes the site, and why nothing it produces is hosted, is on the about page.

Everything the guides describe runs in your browser: the payload is built and the symbol drawn on your own device, and nothing you type is transmitted to us unless you choose to save a code to an account. How the encoding is built and verified is on the methodology page.