What you are seeing
This fix makes the on-screen code scan as reliably as the printed one. You will check the display size, the scaling, the brightness, and the background, then prepare a screen-specific version of the code if needed. Test on the actual screen and device your audience will use, because a laptop monitor and a projector behave very differently.
Likely causes
1.
Browser or app scaling blurs the modules — Quick test: view the code at its native size and compare scanning with the scaled display.
2.
Moire interference on the display — Quick test: zoom the display slightly and see whether scanning improves.
3.
Low brightness or glare on the screen — Quick test: raise screen brightness and shade the screen, then retest.
4.
Code displayed too small — Quick test: enlarge the on-screen code and see whether it starts scanning.
5.
Low-contrast colours on the display — Quick test: show a plain black-on-white version on the same screen.
Step-by-step fix
Step 1: Display the code at its native size on the real screen and test it from the audience distance.
Step 2: If it fails, enlarge the on-screen code and retest. Note the size where it starts scanning.
Step 3: Raise the screen brightness, shade the screen, and remove reflections.
Step 4: Replace the colour version with plain black on white and retest on the same screen.
Step 5: If moire shimmer appears, change the display size slightly or move the scanning phone until the pattern clears.
Step 6: Export a screen-specific version at the size that passed, and test it on two phones.
Step 7: Save the screen version separately from the print version so future edits do not mix them up.
Putting this into practice
In practice, keep two exports for every code that appears in both media: a print export and a screen export. They have different size and contrast needs, and a single file that compromises between them often fails on the screen while passing on paper. 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
- Assuming a code that passes on paper will automatically pass on a projector or a dim monitor.
- 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 works in print but not on screen will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that works in print but not on screen.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The on-screen code is shown large enough to resolve cleanly
- Brightness is up and reflections are controlled
- The screen version passes on two phones at audience distance
- 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)
