A payment QR looks like random noise. It isn't. Every square has a named job, and the spec that assigns those jobs is the reason a code printed on cardboard still scans after a year of weather. Here is the whole thing, part by part.
The three big squares: finders
The heavy rings in three corners are finder patterns. Your camera's job is geometry: find three squares of the same size at right angles, and it knows the code's rotation, skew and scale instantly. That is why QR works at an angle on a crumpled receipt. The fourth corner has no finder; instead, the code uses smaller alignment squares (more of them as the grid grows) to correct distortion across the middle.
The dotted lines: timing and format
Between the finders run alternating dotted lines. The camera uses them to decide where one module ends and the next begins at any size or zoom. Next to the top-left finder, two small format areas store the code's version of the story: its error-correction level and which mask pattern was applied. Those are read before any data.
The scramble: data and mask
The rest is your payment string, encoded in byte mode, one codeword after another. Before printing, the spec tests eight mask patterns, systematic ways of flipping parts of the grid, and picks the one that avoids clusters of same-color modules. A patch of solid black or solid white is where cameras lose track of module boundaries; the mask exists to keep the density honest. What looks like noise is optimized uniformity.
The insurance: error correction
Each version of QR reserves part of its capacity for Reed-Solomon correction codewords, redundancy derived by math from the data itself. Error levels decide the split: L recovers about 7% of damaged codewords, M about 15%, Q about 25%, H about 30%. H is the level used when a coin badge sits in the middle, because the badge destroys data modules on purpose and the redundancy is spent in advance to pay for it. Recovery means the scanner can rebuild erased modules; it doesn't mean guessing your address. The address checksum, not the QR code, is what guarantees the rebuilt string is still a valid one.
The frame: quiet zone
The blank border around the whole code is the quiet zone, and it is part of the standard. Without it, the camera can mistake anything dark on a busy receipt, a table edge or a printed line, for another finder. A code pasted directly onto a photo often fails to scan, and the quiet zone is why. When you print a sign, give the code a clean white margin at least four modules wide; every generator here already draws it.
Sizing that survives reality
A QR needs enough pixels per module for the camera to resolve: roughly 3 px per module on screen, and in print about 1 mm per module is comfortable for phone cameras at arm's length. A short payment link fits in a small version, so even a 4 cm stamp is plenty. Longer links with message= text grow the grid, and that is the real cost of a message parameter: not fees, physical size.
Reading it back
Next time a scan takes a second instead of a blink, you know what happened: finders solved the geometry, timing lines solved the scale, format bits picked the key, correction rebuilt the coffee stain, and your address checksum said the answer is real.
| Part | Job | If it's damaged |
|---|---|---|
| Finder patterns | Position, rotation, scale | Camera can't find the code |
| Alignment squares | Grid distortion | Scan slows or fails |
| Timing lines | Module counting | Misreads the whole grid |
| Format areas | ECC level + mask | Code unreadable |
| Mask pattern | Keep density uniform | Chosen at print time |
| Data + ECC codewords | Your payment string + its redundancy | Up to 30% rebuildable at level H |
| Quiet zone | Clean edges for detection | Frequent scan failures |
Generate a payment QR with proper quiet zone and error correction. Make a payment QR