Skip to main content
QRSenBuilt for business
How-To & Troubleshooting

How to Test a QR Code Before Printing

Print a single physical proof at the exact final size and on the actual material you'll use, then test-scan it with at least two different phones — ideally one iPhone and one Android — under the real lighting conditions it'll be used in, not just a bright desk. Also confirm the content it opens is exactly correct, not just that it scans. This is the cheapest insurance in the entire process.

The single most important step is printing an actual proof rather than trusting an on-screen preview. Screens are backlit and forgiving; paper under real-world lighting is not. Print the code at the exact size and on the exact material planned for the final run — a code that scans fine at four inches on glossy cardstock can behave completely differently at one inch on matte paper. Testing a resized or substituted version of the file doesn't tell you anything reliable about the real thing.

Test with more than one phone, and ideally more than one operating system. iPhone and Android cameras handle focus, contrast, and low light differently, and default scanning behavior varies between them too. A code that scans instantly on one phone might need a second try on another, and if it fails outright on either, that's a real problem worth catching now rather than after a thousand copies are printed.

Test under the actual lighting the code will live in, not the lighting of wherever the testing happens to take place. A code destined for a dim restaurant table, a bright outdoor sign, or a fluorescent-lit office lobby should be tested in conditions that resemble that environment as closely as possible. A well-lit desk is the worst place to validate a code meant for a dark bar or direct sunlight, because it hides exactly the contrast and glare problems that show up in the field.

Finally, don't just confirm that the code scans — confirm it opens the right thing. Tap through and check the actual URL, phone number, WiFi network, or contact card that loads, since a code can scan successfully while still pointing at a typo'd link, a draft page, or outdated information. Catching a wrong destination before printing costs nothing; catching it after a print run is out the door costs the whole run.

For any print run above a small handful of copies, it's worth testing the proof at more than one point in the production process too — once from the final design file before it goes to the printer, and again from an actual printed sample once it comes back, since something can shift between the two steps (a color profile conversion, a scaling error, a substrate that behaves differently than expected) that a pre-press digital check alone won't catch.

Keep a simple record of what was tested, on which devices, and when — for a large or recurring print job, this small bit of documentation makes it much faster to isolate what changed if a batch printed months later suddenly starts failing scans, since it rules out the code's own design as the cause and points toward something that changed in the printing or material instead.

Frequently asked questions

At least two, covering both iPhone and Android, since their cameras and scanning behavior differ enough that a code can pass on one and struggle on the other. More is better if multiple models are easily available.
A printed proof is necessary. Screens are backlit and far more forgiving of low contrast than paper under real ambient light, so an on-screen pass doesn't guarantee a print pass.
Testing under ideal desk lighting instead of the actual environment the code will be used in. A code that scans easily in a bright office can fail in a dim venue or direct sun.