Design & Best Practices
How to Test a QR Code Before Printing
A QR code is one of the few design elements that can be completely, unrecoverably wrong after it's printed. Everything else on a flyer can be a bit off and still do its job; a code that doesn't scan does nothing at all, and you find out from customers. The good news is that the failure modes are well understood and testing takes about twenty minutes. This is the checklist.
The short version
- Test the destination before the code. A perfectly scannable code pointing at a 404 is still a failure.
- Test on at least three real devices, including one older phone and both platforms.
- Test a physical proof on the actual stock — screen tests miss ink spread and glare entirely.
- Test at the real distance, not at arm's length on your desk.
- Intermittent success is a failure. If it scans four times out of five, it isn't ready.
- Use a dynamic code if there's any chance the destination changes — it's the only fix that survives a print run.
Before you test the code, test the destination
The most expensive QR code failures aren't scanning failures. They're codes that scan perfectly and take thousands of people somewhere wrong. Check these first, because they're the ones no amount of scan testing catches:
- Open the destination URL directly in a browser and confirm it loads. Check it in a private window too, so you're not seeing a cached or logged-in version that a stranger won't get.
- Check it on a phone. The destination will be reached almost exclusively from mobile. A desktop-only layout is a wasted scan.
- Verify redirects resolve. If the URL redirects, follow the whole chain — an intermediate hop that requires a login or drops query parameters is a common silent failure.
- Confirm the page will still exist. A campaign landing page that gets cleaned up in six months turns every printed code into a dead end.
- Check for typos in the encoded text, not just the visible copy. This is worth doing character by character for phone numbers, Wi-Fi passwords and email addresses, where a scanned result looks plausible while being wrong.
Use a dynamic QR code for anything printed in volume. It's the only mechanism that lets you fix a wrong or dead destination after the material exists. The cost of not having it is a reprint; the cost of having it and not needing it is nothing.
Device testing
The goal isn't to prove the code can scan — it's to find the conditions under which it can't. Test on:
- At least one iPhone and one Android device. They use different decoding implementations with genuinely different tolerances.
- At least one older phone. Whatever is three or four years old and has a worse camera. This is where marginal codes reveal themselves, and it's what a meaningful share of your audience is holding.
- The native camera app, not a scanner app. That's what people actually use. Dedicated scanner apps are often more tolerant, which makes them the wrong test.
- A phone that isn't yours. You know where to hold yours. Hand it to someone with no context and watch what happens — it's the closest thing to a real user test you'll get in five minutes.
| Condition | What it catches |
|---|---|
| Dim indoor light | Low contrast, undersized modules |
| Bright overhead light on glossy stock | Glare — the code disappears at certain angles |
| 30–45° angle, not square on | Distortion tolerance, weak alignment recovery |
| At the real scanning distance | Code sized to the layout rather than the distance |
| Moving slightly / handheld, not braced | Marginal codes that need a perfectly still shot |
| Partially shadowed | Threshold sensitivity across the code |
Every scan should be effectively instant. That's the bar. If a code takes a second or two of hunting, or needs you to reposition, it's marginal — it will fail outright for someone whose conditions are slightly worse than yours. Treat "it works if you hold it right" as a failure.
Test a physical proof, not a screen
This is the step people skip, and it's the one that catches the failures unique to print. A screen shows you a perfect, backlit, high-contrast rendering that no printed piece will match.
- Print on the actual stock, at the actual size, with the actual process. An office laser proof of a piece destined for uncoated card tells you very little about ink spread.
- Check module edges under good light. They should be crisp. Fuzzy or merged module boundaries mean the modules are too small — see the sizing guide for the 0.4 mm floor.
- Test the finished surface. If the piece will be laminated, varnished or shrink-wrapped, test it that way. Gloss lamination adds glare that plain stock doesn't have.
- Test it where it'll live. A table tent under restaurant lighting behaves differently from the same tent on your desk.
- Fold and handle it. If the piece folds, make sure the fold doesn't cross the code — and especially not a corner finder pattern.
If your code isn't black on white, verify the contrast of the CMYK-converted colour rather than what's on your monitor. Vivid RGB colours routinely convert duller and lighter, which can push a pair that passed on screen below the threshold on paper. Our colour guide covers the targets.
The pre-press checklist
Run through this before the file goes out:
| Check | Pass condition |
|---|---|
| Destination loads on mobile, logged out | Yes, and it's the right page |
| Dynamic code used for volume print | Yes, or a deliberate decision not to |
| Quiet zone | ≥4 modules clear on all four sides |
| Contrast ratio | ≥7:1, dark modules on light background |
| Not inverted (light on dark) | Correct, or tested on 5+ devices |
| Logo coverage | ≤15% of area, level H, clear of all corners |
| Printed size vs. scan distance | ≥ distance ÷ 10 |
| Module size in print | ≥0.4 mm |
| Export format | Vector (SVG/PDF/EPS), or ≥300 DPI raster |
| Code not scaled after export | Placed at native size or scaled as vector |
| Devices tested | ≥3, both platforms, one older phone |
| Physical proof on real stock | Scans instantly, every attempt |
| Tested at real distance and angle | Yes |
| Fold/trim lines clear of the code | Yes, especially the corners |
Two entries there are worth expanding. Export format: use vector wherever the process allows, since a raster code scaled up in a layout program picks up soft edges that read as blur to a camera. Code not scaled after export catches a common workflow bug — a 300 DPI PNG enlarged 200% in InDesign is a 150 DPI code, and nobody notices until it's printed.
After it's printed
- Scan a piece from the actual run, not just the proof. Presses drift, and the run is what customers get.
- Scan several pieces from different parts of the run if it's large.
- If it's a dynamic code, watch the scan analytics early. Scans arriving means it works in the field. Silence in the first days after distribution is worth investigating immediately, while you can still act.
- Keep a record of which code went on which piece. When something needs repointing in a year, you'll want to know which of your codes is on the poster in the lobby.
Frequently asked questions
How do I test a QR code before printing it?
Check the destination first — open it on a phone, logged out, and follow any redirects. Then scan the code with the native camera app on at least three devices including one older phone and both platforms, in dim light, at an angle, and from the real scanning distance. Finally, print a physical proof on the actual stock at the actual size and scan that. Every scan should be effectively instant; anything slower is marginal.
Why should I test on an old phone?
Because a marginal code passes on a good camera and fails on a worse one, and a meaningful share of any audience is carrying a phone several years old. A recent flagship has better optics, autofocus and low-light performance than the median device that will encounter your code. Testing only on your own current phone is testing under the best conditions your audience will ever have.
Is scanning from my screen a good enough test?
It's a useful first check and nowhere near sufficient. A screen is backlit, perfectly uniform, and has no ink spread — so it hides exactly the failure modes print introduces: modules blurring together, contrast dropping in CMYK conversion, and glare from coated stock. A code that scans on screen and fails in print is completely normal, which is why a physical proof is a separate, non-optional step.
My code scans most of the time. Is that OK?
No. Intermittent scanning means the code is sitting at the edge of its tolerance, and every real-world condition that's worse than your test — dimmer light, an older camera, a steeper angle, a less patient person — pushes it over. In the field that reads as "the code doesn't work." Find the margin you're short on (usually size, contrast, or logo coverage) and fix it rather than accepting a pass rate.
What if I find a problem after printing?
If it's a dynamic code, repoint it — that's exactly what it's for, and the fix takes seconds with no reprint. If it's a static code and the destination is wrong, you can sometimes rescue it at the destination end by making the wrong URL redirect to the right one, assuming you control that domain. If the code physically doesn't scan, there's no fix short of reprinting, which is the argument for dynamic codes and a physical proof in the first place.