QR code guides
Longer answers to the questions behind the generators: each guide shows the numbers, where they come from and how to check them with the tools on this site.
- Smallest QR code size: printer, decoder and phone limitsHow small can a QR code be? 2 cm for phones, 8.4 mm at 400 dpi, Micro QR and rMQR for tiny spaces, and a decoder test of how few pixels per module work.
- Maximum QR code size: version 40, 2,953 bytes, and how big to print itThe largest QR code is version 40: 177 × 177 modules, 2,953 bytes at level L. Capacity by level, print sizes, and how large versions fared in a decoder test.
- The QR code quiet zone: why four modules, and what happens with lessQR codes need a 4-module quiet zone. What that is in millimetres, where designs lose it, and phone and decoder tests of 0 to 4 modules on busy backgrounds.
- QR code sticker size: square, round and pre-cut labelsHow big a QR code sticker should be: code width and scan range for 1 to 4 inch square and round stickers, and how to fit codes on pre-cut labels.
- QR code size on a business card: what fits, what scansA QR code on a business card: the rules of thumb, card safe zones, and a phone test where a full vCard read at 10 mm from 20 cm.
- QR code size in pixels: exports, screens and the scaling trapHow many pixels a QR code needs: a 1024 px PNG gives a short link 31 px per module. Print resolution maths, screens, and why scaling by odd factors hurts.
- How to print QR code stickers and labels in bulkTurn a CSV into up to 500 labelled QR code stickers: styles that still scan, a label sheet or pre-cut labels, and print settings that keep the size right.
- Do QR codes expire? Static vs dynamic codes, and what the providers’ own rules sayStatic QR codes never expire; dynamic ones can stop. What five providers say happens at trial end, downgrade, cancellation or expiry, and how to choose.
How the decoder tests work
Several guides quote results from one set of tests. They answer a narrow question: what does a QR decoder need from a clean image? They do not measure what a particular phone camera manages in a particular light.
- Codes. Made with this site’s own encoder: a short link (version 2, 25 modules), a Wi-Fi network (version 3), a contact card and a long tracking link (both version 11, 61 modules), and full codes of versions 10, 20 and 40. Error correction M, except L for version 40.
- Images. Black modules on white, drawn at 8 pixels per module and averaged down to the target number of pixels per module, the way a downscaled photo or a resized image is. Some runs add a 3 × 3 box blur once or twice, to soften edges as an out-of-focus camera would.
- Repeats. Whether module edges fall on pixel edges changes the result, so every resolution step is tried at 10 random sub-pixel offsets. A step counts as reliable when at least 9 of the 10 decode, and a code is “reliable from” the lowest step after which every larger step, up to 6 pixels per module, is reliable. Steps are 0.25 pixels apart, so differences of one step are within the test’s resolution.
- Decoder. jsQR 1.4.0, the open-source library behind QR Meadow’s scan check. Phone camera apps use other decoders and do their own image processing, so they can do better or worse.
The script is build/guide-experiments.mjs in the site’s source and writes its results to build/guide-experiments.json; the numbers in the guides are checked against that file automatically. Results recorded on 28 October 2026.
The phone test
The same kinds of codes were then scanned with real phones: 31 codes made with this site’s generator, in four sets.
| Set | Codes |
|---|---|
| Size | A short link (version 2), a short contact card (version 8) and a full contact card (version 11), each 10, 15, 20, 25 and 30 mm wide |
| Quiet zone | A 25 mm version 2 code with 0, 1, 2 and 4 modules of white margin, surrounded by random dark modules |
| Styles | The eight preset styles, 15 mm wide |
| Large versions | Version 20 and version 40 (the largest), 50 and 80 mm wide |
Each code held a test label padded to the byte count of the real content, so its version matched, and nothing that opens a web page. They were scanned with an iPhone and an Android phone, each with its built-in camera app, scanning a computer screen from about 20 cm. All 31 codes were read by both phones, including the hardest three: the code with no quiet zone, the 10 mm full contact card and the 50 mm version 40 code.
Limits of this test: one session at one distance; a backlit screen, which is sharper and higher in contrast than most prints; sizes as set on the page, with the screen’s calibration not recorded; phone models not recorded. It shows what current phone cameras can do in good conditions, not what every print in every light will do. Printed tests at other distances will be added here when they are run.
Simulated print and camera projection: two decoders
A separate experiment on 28 October 2026 rebuilt 31 samples in the four groups above. They use padded test text, not working links or contact cards. These are new samples, not the exact 31 files in the phone session. A vector PDF was rasterised at 300 dpi, converted to greyscale and projected through a model camera. Apple Vision (macOS, barcode request revision 4) and ZXing-C++ 3.1.1 each decoded the same 1,116 images: 31 samples × 3 model distances × 4 image conditions × 3 repeats, or 2,232 decoder runs. A pass requires the entire decoded text to equal the expected text; no incorrect text was returned.
What the centimetres mean
The assumed camera has a 1920 × 1080 frame and a 60° horizontal field of view, giving a focal length of about 1,663 pixels. For a front-facing symbol, projected width = focal length in pixels × symbol width in millimetres ÷ camera-to-symbol distance in millimetres. The 15, 20 and 30 cm settings are inputs to this model, not measurements from a real phone. They must not be quoted as safe scanning distances.
The input to each decoder is a known crop around the projected code, with about 12 pixels of surrounding space, rather than a full camera frame. This can make localisation easier. Each repeat changes the sub-pixel alignment and, where enabled, the noise; it is not another phone or print.
Inputs and results
Clean projection adds no ink expansion, blur, noise or tilt. The three stress levels combine a 3 × 3 dark-pixel expansion filter, greyscale noise, Gaussian blur, perspective tilt and uneven light. Mild / medium / strong use X–Y tilts of 8°–12° / 15°–20° / 25°–30°, capture blur of 0.45 / 0.8 / 1.2 pixels, and sensor-noise standard deviations of 2 / 4 / 8 on a 0–255 scale. These are declared artificial stress settings, not calibrated printer or lens properties. All parameters and software versions.
| Input condition and model distance | Apple Vision | ZXing-C++ |
|---|---|---|
| Clean projection, 15 cm (assumed) | 91/93 | 88/93 |
| Clean projection, 20 cm (assumed) | 88/93 | 85/93 |
| Clean projection, 30 cm (assumed) | 83/93 | 80/93 |
| Mild stress, 15 cm (assumed) | 87/93 | 86/93 |
| Mild stress, 20 cm (assumed) | 83/93 | 83/93 |
| Mild stress, 30 cm (assumed) | 79/93 | 78/93 |
| Medium stress, 15 cm (assumed) | 78/93 | 81/93 |
| Medium stress, 20 cm (assumed) | 74/93 | 75/93 |
| Medium stress, 30 cm (assumed) | 65/93 | 63/93 |
| Strong stress, 15 cm (assumed) | 68/93 | 57/93 |
| Strong stress, 20 cm (assumed) | 59/93 | 40/93 |
| Strong stress, 30 cm (assumed) | 27/93 | 20/93 |
The whole-sample counts describe this batch only; they are not estimates of real users’ success rates. As a clean-source control before projection, Vision read 31/31 of the 300 dpi images and ZXing-C++ 30/31; neither found a code in the blank negative control. The no-margin sample was one of the disagreements, not proof that either decoder is universally stronger.
What this experiment cannot establish
It contains no real paper, camera, autofocus, lens distortion, exposure or multi-frame processing. Greyscale inputs do not validate colour-print performance. Several stress factors change together, so the test does not isolate the cause of a failure. Three seeded repeats per setting are too few to claim general reliability. Vision on macOS is not a test of the iPhone Camera app; ZXing-C++ is not every Android camera. Actual paper scans at 15 and 30 cm remain untested.
Keep these findings separate from both the jsQR image experiment and the owner-reported screen scans. Use them to identify designs worth proofing, while retaining the four-module quiet zone and testing the final physical print.
Download all 2,232 decoder results (CSV) · Summary counts (JSON) · Rebuilt sample PDF (Chinese instructions) · Apple Vision API · ZXing-C++ Python bindings