paintqrHow we test that a QR code scans, and how you can
A code that reads on a laptop screen can fail on a menu. This is the method behind every PaintQR design: two software readers on every code, fourteen simulated camera conditions in the lab, and printed sheets scanned by real phones. The same method, in a shorter form, is how you should test your own print.
Updated 10 November 2026
Three layers, not one
There is no single test that proves a QR code will scan. A decoder on a computer is far more forgiving than a phone camera held at arm's length, and a phone in a bright shop is less forgiving than the same phone at a desk. So PaintQR checks in three layers, each cheaper and more frequent than the next: every design is decoded by software before it can be downloaded; the design rules the software applies were set by phone tests on printed sheets; and the lab harness that compares styles and settings runs a code through the conditions a camera creates.
Each layer catches a different failure. The software readers catch a code that is simply wrong. The phone-derived rules catch designs that decode on a computer yet failed on real devices. The harness tells us, before a rule exists, which choices make a code fragile.
Layer one: two readers on every design
Every design you see in the maker has already been decoded twice over. The first reader is zxing-cpp, the library most Android scanning apps descend from. The second is OpenCV's detector, which binarises an image in blocks and fails in a different way: it is the one that struggles with large solid fills. Each reader gets the colour render and a black-and-white render, and a copy blurred to three pixels per square that stands in for a small or soft print.
If the reference reader cannot decode the clean render, the design is refused outright and the maker says why. That should never happen, and it is the one check with no exceptions. The other readers' results on the blurred copies are recorded and shown in the report; they inform the rules below rather than block on their own, because they are erratic on blur in ways that do not match phones.
Layer two: rules from 140 phone attempts
In September 2026 we printed sheets of designs and scanned them with an iPhone and a Motorola Android phone, using the built-in camera apps, at arm's length under room light, on screen and on paper: about 140 attempts in all. Every design the phones rejected still decoded on a computer. So the rules are built from the design features that predicted the phone failures, not from the software readers.
Three patterns failed. A design where dark squares cover more than half of the data area and most of them sit in solid blocks, at version 15 or above: a hibiscus and a heart were the cases. A dark, coloured library icon at version 15, where 6 of 8 attempts failed, against 5 of 5 that passed at version 10. And a coloured accent design at version 15 that spent more than a fifth of its error-correction capacity on the picture. Everything else, letters, logos and photographs at versions 6 to 15 with the default setting, passed every attempt.
A design that matches one of those patterns is marked fragile. The maker does not sell it as it stands: it lowers the detail or the picture budget, generates again and re-checks, and shows you what it changed. The one exception is version 20, the Max detail: it failed at the size that works for version 15 but scans when printed larger, so it is allowed with a larger minimum print size instead.
Layer three: the lab harness
When we compare a style, a setting or a change to the engine, a decode on a clean image tells us little. The harness takes a rendered code and puts it through fourteen conditions that imitate what a camera does: the code small in the frame, at three and at 2.4 pixels per square; blur; tilt of 25 and 40 degrees and a sideways tilt of 30; uneven lighting; low contrast; sensor noise; JPEG compression; a screen capture; ink spread as on paper; and a combination of tilt, lighting and blur. Each image goes to every reader we can install: zxing-cpp, OpenCV, OpenCV's WeChat detector, zbar, and classic Java ZXing, whose older binariser is the least forgiving of them and the closest to old scanning apps.
The scan score is the share of condition-and-reader pairs that decode to the right text, and the report names the weakest conditions. This is how the print-size rule and the scan-safety settings were tuned, and it is what we run before changing anything that touches the picture.
How the print sizes were measured
Printed plain codes decoded down to about 0.4 mm per square at arm's length. Codes carrying a picture needed about one and a half times that: version 15 worked at 0.66 mm per square and failed at 0.5. Version 20 failed at 0.5 as well; for it and above we show 0.8 mm per square, a margin above the failure, until a print test at 6.5, 8.5 and 10 cm replaces the estimate with a measurement. The size shown under every design is its squares, margin included, multiplied by the right figure and rounded up. The full table by version is in the print-size guide.
Test your own print in five minutes
Our checks make a bad design unlikely. They cannot see your printer, your paper or the light in your shop. Before a run of menus or cards, do this once:
- Print one copy at the intended size and check it against a ruler. A page printed with 'fit to page' comes out smaller than designed, and a code at its minimum size has no room to shrink.
- Use two phones of different makes, with their built-in camera apps, not a scanner app that may be more forgiving than your customers' phones.
- Scan at arm's length under the light the code will live in, then from one and a half times the distance, then with the phone tilted about thirty degrees.
- Do not take a screen test as a print test. A screen is backlit and sharper than paper; a code that scans on your monitor has told you only that the design is valid.
- If the surface is glossy or laminated, scan it under a ceiling light. A reflection across one of the three large corner squares stops the scan.
- If any scan fails, print larger first, then choose the balanced scan setting or a lower detail, then simplify the picture. One of the first two fixes almost always does it.
What we do not claim
Two phones and five readers are not every phone and every app. Older scanning apps built on the classic ZXing binariser read less than modern camera apps do, and we test for that in the lab, not on devices. Your printer, ink and paper change the contrast in ways no model fully predicts. The checks above are a filter that removes the designs we know to fail; the printed test is the proof, and it is yours to run.
One current limit, stated plainly: the option that keeps a logo's shapes exact, with the code's pattern outside them, has passed the software readers and the lab harness at the Max picture setting, and its phone test on printed sheets is still in progress. Until it is done, print such marks large and run the five-minute test before a long run, or choose the balanced scan setting, which adds error correction at the cost of a little room.
Questions
My code scans on my screen but not on paper. Why?
Paper is dimmer, softer and smaller than a screen. The usual causes, in order: the print came out smaller than the minimum size, often because of 'fit to page'; a glossy surface reflecting a light into the camera; or a design near the edge of what the phone tolerates, which the larger print or the balanced setting fixes.
Which phones and apps did you test with?
Printed sheets were scanned with an iPhone and a Motorola Android phone using their built-in camera apps, about 140 attempts in September 2026, with follow-up tests of version 20 in October. The lab harness adds five software readers, including classic Java ZXing, which stands in for older scanning apps.
Does a coloured code scan as well as a black-and-white one?
A phone reads dark against light, not colour. PaintQR keeps every dark square below a brightness threshold and every light one above it, so the colours are for people and the contrast is for the camera. The one coloured pattern that failed on phones, a strong accent at version 15 with a large picture budget, is now caught by the rules.
How much of the error correction does the picture use?
A standard code at the lowest level can repair about 7 % of its squares, at the medium level about 15 %. The scan-safety setting decides how much of that repair budget the picture may spend: Safe about a tenth, Balanced a fifth, Max picture about a third. The rest stays for creases, reflections and shaky hands.