What you are seeing
The printed code comes out smaller than you designed: a tiny square on a label, a card, or a receipt that no phone can read comfortably. Small codes fail because the modules shrink below the size the camera can resolve, especially in dim light or at arm's length. The usual cause is a layout squeeze: the code was shrunk to fit a crowded design, a label template, or a receipt width. The fix is to give the code the size the scan distance requires, even if that means redesigning the layout around it.
Likely causes
1.
Layout squeezed the code to fit — A crowded label, card, or receipt leaves little room, so the code is shrunk until it fits. Test: measure the printed code and compare it with the designed size.
2.
Label or receipt template fixed the size — A template with a fixed image box can scale the code down without warning. Test: check the template image box size against the code size.
3.
Payload too dense for the available space — A long payload needs a larger code to keep its modules readable, so the same space that fits a short code starves a dense one. Test: compare a short-payload version at the same printed size.
4.
Printer scaled the job to fit the page — A fit-to-page setting can shrink the whole job, including the code, without any visible warning. Test: check the print settings and measure the printed output.
5.
Code placed where people stand far away — A small code that works at arm's length fails at the distance people actually stand. Test: scan the code from the real audience distance.
Step-by-step fix
1. Measure the printed code and write down its actual size.
2. Test it at the real viewing distance on two phones.
3. Shorten the payload so the modules get larger at the same size.
4. Enlarge the code to the size that passes at the real distance.
5. Redesign the layout if the code needs more room than the layout allows.
6. Reprint one proof at the corrected size and confirm it scans before approving the run.
Putting this into practice
In practice, the code size is a requirement, not a decoration. Decide the size from the scan distance first, then design the layout around it. A layout that leaves no room for a readable code is a layout that needs redesigning, not a code that needs shrinking. Keep a short note of what you tested, what failed, and what you changed, so the next person starts from evidence rather than guesswork. A fix that is written down survives staff changes and reprints; a fix that lives only in memory gets repeated.
Common mistakes to avoid
- Shrinking the code to fit a crowded layout instead of redesigning the layout to fit a readable code.
- 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 prints too small will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that prints too small.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The printed size matches the designed size
- The code scans at the real viewing distance on two phones
- No fit-to-page scaling shrinks the job
- 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)
