Test a QR code properly before you print a thousand of them

Almost every QR code failure that reaches the public was catchable for the cost of one sheet of paper. The proof got skipped, or it got done on a laser print of an A4 page at 80% scale on the wrong stock, which proves nothing.

What follows is a procedure. It takes about twenty minutes and it is the same twenty minutes whether the run is a thousand flyers or a hundred thousand cartons.

Proof at final size, on final stock

Print one copy at exactly the size it will appear in the finished piece, on the material the job will actually run on, through a process as close to the real one as you can get. Not scaled to fit a page. Not on 100 gsm office paper when the job is uncoated 350 gsm board.

This single step is doing three jobs at once. It tests the module size against the resolution of the process — the numbers for that are in what size a printed QR code should be, and the module is the unit that matters, not the code. It tests ink spread on the substrate, which closes up the light modules and is invisible on screen. And it tests the finish: a gloss varnish or a laminate throws a specular highlight straight back at the camera and can blow out a third of the symbol.

If the real process is unavailable, get the closest proxy and then add margin. A code that scans on a digital proof but only just, will not survive flexo.

The three-phone rule

Scan the proof with three devices, chosen for spread rather than quality.

1. A cheap Android handset, two or three generations old. This is the one that matters. Its camera has the least resolution, the worst low-light behaviour and the slowest autofocus of anything in your audience’s pocket. If it reads the code, almost everything else will.
2. An older iPhone. iOS and Android decode with different libraries and different tolerances, and they disagree most on low-contrast and partially-obscured symbols.
3. A dedicated scanner app on either handset. Camera apps are tuned for speed and give up quickly; a scanner app will keep trying. If only the scanner app succeeds, the code is marginal and you should treat that as a failure, not a pass.

A code that reads on a current flagship and nothing else has not passed. That is the most common false positive in this whole process.

Lighting is a variable, not a constant

Test the proof in the light it will live in:

• Bright daylight — the case where gloss and lamination produce glare.
• Ordinary indoor lighting, roughly what a shop floor or an office corridor has.
• Dim — a restaurant at dinner service, a bar, an evening event. This is where phones drop the shutter speed, motion blur creeps in, and small modules merge. It is by far the most common real failure.
• With a flash or torch on, which is what a person does when the first attempt fails, and which produces a hotspot on anything glossy.

If the code has to work in a dim room, size it as if it were being read from further away than it is. That costs nothing.

Angle and distance sweeps

Do not scan the proof once, square on, at a comfortable distance. Sweep it.

• Distance. Start at half the intended reading distance, walk out to twice it, and note where it stops working in both directions. A phone that is too close cannot focus; a code that only reads within a 10 cm window is a code people will fail to scan.
• Angle. Try roughly 30° and 45° off-axis, in both axes. QR codes tolerate perspective well because of the three corner finders, but a marginal symbol loses that tolerance first.
• Rotation. Turn it upside down and 90°. Orientation should not matter and usually does not — if it does, something is wrong with the quiet zone on one side.
• Movement. Scan while walking past, if that is how it will be used on signage.

Write down where the edges are. “It works from 40 cm to 1.2 m, up to about 40°” is a result. “It scanned” is not.

The obstruction test, for codes with a logo

If the code carries a logo, the point of the higher error correction level is that some of the symbol can be lost. Test that the remaining margin is real: cover a small area at the edge of the symbol with your thumb — a few modules, not a quarter of it — and scan again. A logo code that fails the moment anything else is obscured has already spent all of its redundancy, which means a scuff, a crease or a fingerprint in the field will kill it.

The area maths behind that, and why 30% error correction is not permission to cover 30% of the code, is in putting a logo in a QR code without breaking it.

Test the destination, not just the symbol

A code that decodes perfectly to a dead page is still a failed code.

Turn wifi off first. Office wifi hides an unpublished page, a staging host that only resolves internally, a certificate a corporate proxy was tolerating, and a page heavy enough to time out on two bars of signal. Scan on mobile data, on the older phone, and watch it load end to end.

Check what actually renders. Is it readable on a 5-inch screen without pinch-zoom? Does a cookie banner cover the thing the person came for? If the destination is a PDF, reconsider — that mistake is dissected in the QR menu article and applies far beyond menus.

Follow the redirect chain. If the URL passes through a short link, a campaign redirector or a vanity domain, count the hops and confirm every one is HTTPS and under your control. A single hop you do not own is a link someone else can repoint later, which is the mechanism behind most of the attacks in the QR code security article. curl -sIL and reading the Location headers takes ten seconds.

Confirm the tracking survives. If the URL carries UTM parameters, scan it and check the hit lands in analytics with the right source and medium before the plates are cut, because you cannot retag a printed code.

ISO/IEC 15415 grading, and when it is worth paying for

A verifier is a calibrated instrument that scores a printed 2D symbol on contrast, modulation, fixed pattern damage, axial and grid non-uniformity and unused error correction, then reports the worst parameter as a grade from 4.0 (A) down to 0 (F). It is a measurement of print quality against ISO/IEC 15415, not a statement about whether one particular phone decoded it.

It is worth paying for when:

• a customer or a regulator specifies a minimum grade, which is routine in pharmaceutical, medical device and automotive supply chains;
• the code is scanned by fixed industrial readers at speed rather than by people with phones;
• you are running a large volume and need evidence that the process is in control, not that one sample worked.

It is not worth paying for a poster, a flyer, a menu or a business card. For consumer-facing print, three phones in bad light tell you more about the outcome than a grade does — a Grade C symbol that every phone reads instantly is fine, and a Grade A symbol behind gloss lamination in a dark restaurant is not.

The pre-flight checklist

Run this on the physical proof, not the file.

• Printed at final size, on final stock, through the closest available process
• Quiet zone intact on all four sides — four modules, not “looks like enough”
• Not crossing a fold, a seam, a die cut or the trim line
• Dark modules on a light background, with real contrast on paper
• Reads on a cheap Android, an older iPhone and a scanner app
• Reads in daylight, indoor light and dim light
• Reads from half to twice the intended distance, and at 45° off-axis
• Still reads with a few edge modules covered (logo codes only)
• Wifi off: destination loads on mobile data in under a few seconds
• Destination is legible on a phone without zooming
• Redirect chain checked, every hop HTTPS and owned by you
• UTM tags verified as landing in analytics
• The person signing off has personally scanned it

The last line is not filler. Most of the codes that reach print broken were approved by someone who looked at the artwork and never held a phone up to it.

When you need to regenerate a code after a failed test, the generator does it in the browser and the image API does it from a URL, so re-proofing costs another sheet of paper rather than another day.