What you are seeing
This fix makes the code scan from the real viewing distance. You will measure the distance your audience stands at, then resize the code and simplify the payload until it locks on from there. Test from the furthest point, not the nearest, because the furthest reader is the one you are currently losing.
Likely causes
1.
Code too small for the viewing distance — Quick test: step closer until it scans and note the distance where it first locks on.
2.
Payload too dense — Quick test: compare a short-payload version at the same size and distance.
3.
Weak contrast over distance — Quick test: compare a black-on-white proof at the same distance.
4.
Glare or reflections at the viewing angle — Quick test: view the code from the audience position and check for reflections.
5.
Code placed too high, low, or behind an obstruction — Quick test: stand where the audience stands and check the angle and obstructions.
Step-by-step fix
Step 1: Stand where the furthest reader will stand and test the code on two phones. Write down the distance.
Step 2: Shorten the payload as far as you can, then regenerate the code.
Step 3: Print a larger proof and test it from the same furthest point.
Step 4: Increase the contrast and remove any reflections visible from the audience position.
Step 5: Reposition the code to a clear, straight-on spot at a comfortable height if the angle or an obstruction is hurting the scan.
Step 6: Retest the proof from the furthest point on two phones, and also from a mid-range point.
Step 7: Approve the run only when the furthest-point test passes, and record the distance and size in the job file.
Putting this into practice
In practice, record the viewing distance and the final size together in the job file. When the same design is reused at a different distance, those two numbers tell you immediately whether the code needs to grow. Record the before-and-after behaviour with the job file, so the fix is provable rather than anecdotal. When the same failure appears again, that record tells you whether the old fix held or a new cause appeared.
Common mistakes to avoid
- Sizing a poster code by how it looks on a desk, then discovering visitors cannot scan it from the queue.
- Reprinting the full run before a single proof passes, which turns one failure into many.
- Testing on one phone in ideal conditions instead of two phones in the real conditions where a code that scans up close but not from a distance will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that scans up close but not from a distance.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The code locks on from the furthest reader position
- The payload is as short as the destination allows
- The code sits at a clear, straight-on, well-lit position
- The corrected proof passes on two phones in the real conditions
- The fix is recorded in the job file so the next reprint starts from a proven setup
- Every printed copy is checked against the approved proof
- The proof is retested after any later change to the link, design, or placement
Related tools and guides
- [QR minimum size checker](/qr-minimum-size-checker)
- [QR contrast checker](/qr-contrast-checker)
- [QR print proof checklist](/qr-print-proof-checklist)
- [QR DPI calculator](/qr-dpi-calculator)
- [QR quiet zone calculator](/qr-quiet-zone-calculator)
- [printed QR tester](/printed-qr-tester)
- [QR size calculator](/qr-size-calculator)
