How QR codes work (and how to make one that scans reliably)

A QR code looks like noise, but every pixel is deliberate. It is a two-dimensional barcode designed in 1994 by Denso Wave for tracking car parts, and the design goals — fast scanning from any angle, tolerance of dirt and damage — explain almost every visual feature. Understanding a handful of those features is the difference between a code that scans instantly from across a room and one that fails on the printed poster you just paid for.

Modules, versions and capacity

The small squares that make up a QR code are called modules. Each module is one bit: dark for 1, light for 0 (after masking, but the principle holds). The grid comes in fixed sizes called versions, from version 1 (21×21 modules) to version 40 (177×177), growing by 4 modules per side each step. Your generator picks the smallest version that fits your data — you do not choose it directly.

Capacity depends on the version, the error-correction level, and the kind of data. QR has four encoding modes, and the efficient ones are easy to miss:

• Numeric (digits only): most compact — version 1 at the lowest correction level holds 41 digits.
• Alphanumeric (digits, capitals A–Z, and nine symbols): 25 characters at version 1.
• Byte (anything, including lowercase and UTF-8 text): 17 characters at version 1.
• Kanji: a dedicated compact mode for Japanese text.

The practical consequence: shorter data means a lower version, which means bigger modules at the same print size, which means easier scanning. A 300-character URL forces a dense high-version grid; a short one produces a coarse, robust code. This is the single best argument for shortening a long URL before encoding it. Note also that lowercase letters force byte mode — HTTPS://EXAMPLE.COM can encode more compactly than its lowercase twin, though in practice keeping URLs short matters far more than gaming the mode.

The three large squares in the corners are finder patterns: they let a scanner locate the code and determine its orientation from any angle, which is why a QR code scans upside down. Smaller alignment patterns (from version 2 up) correct for perspective distortion, and the alternating timing lines between finders establish the grid spacing.

Reed–Solomon error correction — and the logo trade-off

QR codes deliberately store redundant data using Reed–Solomon codes, the same family of error correction used on CDs and in deep-space communication. There are four levels, chosen when the code is generated:

Level	Codewords recoverable
L (Low)	~7%
M (Medium)	~15%
Q (Quartile)	~25%
H (High)	~30%

Higher levels tolerate more damage — scratches, smudges, glare, a torn corner — at the cost of capacity: the redundancy takes space, so the same data needs a higher version (denser grid) at level H than at level L.

This is exactly the mechanism behind logos in QR codes. A logo placed over the centre is, to the scanner, damage: those modules are simply unreadable, and Reed–Solomon reconstructs the lost data. There is no special "logo support" in the standard. The practical rules follow directly: use level H, keep the logo well under 30% of the area (under ~10–15% is comfortable, because real-world scanning adds its own errors on top and you must leave margin for them), and keep it away from the three finder patterns and the format-information strips beside them — error correction protects the data region, but a scanner that cannot find the code never gets that far.

The quiet zone

The specification requires a border of empty background around the code — the quiet zone — at least 4 modules wide on every side. Scanners use the light-to-dark transition to find the code's edges; crowd the code with text, borders or a busy background and many scanners will fail even though the code itself is perfect. This is the most common self-inflicted QR failure in graphic design: a decorative frame placed tight against the modules. Leave the margin. If your layout puts the code on a coloured or photographic background, put it on a white tile with the full quiet zone inside the tile.

Contrast: dark on light, and why inverted codes fail

Scanners expect dark modules on a light background. The standard defines it that way, and while many modern phone cameras will also read an inverted (light-on-dark) code, plenty of scanners — especially older phones and dedicated hardware — will not. If the design demands a dark background, the safe pattern is a light tile containing a conventional dark-on-light code.

Colour is fine as long as contrast is high: dark navy on white scans; yellow on white does not; red on black is marginal because some sensors see red as dark. Aim for the strongest luminance contrast you can, avoid gradients across the code, and avoid glossy laminates that throw specular glare across the modules.

Print size versus scan distance

The rule of thumb: a QR code should be printed at about one tenth of the intended scanning distance. Scanning from 30 cm (a leaflet in the hand)? 3 cm across is enough. A poster read from 3 metres needs a code roughly 30 cm wide. A motorway billboard QR code is, for this reason, mostly a joke.

The deeper variable is module size: the camera must resolve individual modules. A dense version-20 code at 2 cm has modules a fraction of a millimetre wide and will frustrate any camera. Combine the rules: keep the data short (low version, coarse modules), print at a tenth of the viewing distance, and test with a mid-range phone in imperfect light — not just the newest flagship in the office.

Static versus 'dynamic' QR codes — honestly

A static QR code encodes your actual content — the URL, the Wi-Fi credentials, the vCard — directly in the modules. It works forever, needs no service, and costs nothing. Its only limitation is that the content is fixed at print time.

A 'dynamic' QR code is not a different kind of QR code at all. It is a static code that encodes a short redirect URL owned by a service provider; the provider forwards scanners to a destination you can change later, and logs each scan along the way. That is genuinely useful — editable destinations, scan counts — but be clear-eyed about the trade: every scan now depends on that provider being up, in business, and paid. If the subscription lapses or the company folds, every printed code dies at once, and some providers deliberately break codes on free plans to convert you. Scan analytics also mean user tracking, which may matter for your audience.

If you control your own domain, you can have both benefits with neither risk: encode a short URL on your domain and manage the redirect yourself. The printed code then depends only on infrastructure you already rely on.

A pre-print checklist

• Encode the shortest data you can; shorten long URLs first.
• Error correction M for clean digital use; H if overlaying a logo or printing somewhere that will get worn.
• Logo small, centred, clear of the finder patterns.
• Quiet zone: at least 4 modules of clear background, always.
• Dark modules on a light background, strong contrast, no gradients.
• Size at roughly a tenth of scanning distance.
• Test the final printed artwork — not the on-screen preview — with more than one phone.

None of this requires understanding Galois-field arithmetic. The engineering inside a QR code is deep, but the rules for using one well are short, and every failed scan in the wild traces back to breaking one of them.