What you are seeing
The printed code looks pale: the dark modules are grey rather than black, and the scanner struggles or fails. Faded modules lose contrast, which is the property the scanner depends on most. The cause is usually ink, toner, or a print setting, though a file problem can also leave the modules pale. The screen version looks bold, which hides the problem until the proof appears. The fix is to find the stage that weakens the ink and to restore solid, dark modules.
Likely causes
1.
Low ink or toner — A cartridge running low lays down pale, uneven modules. Test: check the ink or toner level and print a test page.
2.
Economy or toner-save mode — A toner-save or economy setting deliberately reduces the ink, which fades the modules. Test: switch the setting off and reprint.
3.
File with pale module colour — A design that uses grey or a pale colour for the modules prints pale even on a healthy printer. Test: check the module colour in the file.
4.
Stock that absorbs or resists ink — A stock that soaks up ink or resists it can leave pale modules. Test: print the same file on plain white stock and compare.
5.
Wrong media setting — A printer set for the wrong stock can lay down too little ink for that surface. Test: confirm the media setting matches the stock.
Step-by-step fix
1. Check the module colour in the file and set it to a solid dark colour.
2. Switch off any economy or toner-save mode.
3. Check the ink or toner level and replace a low cartridge.
4. Confirm the media setting matches the stock.
5. Print one proof on the real stock and compare it with the digital file.
6. Reprint the proof until the modules are dark, then approve the run.
Putting this into practice
In practice, faded modules are easy to miss on a quick glance, because the code still looks like a code. Judge the proof by contrast, not by shape: hold it next to the digital file and check that the dark modules are truly dark. A greyscale photo of the proof makes fading obvious. 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
- Leaving toner-save mode on for a QR print run and wondering why the codes look pale.
- 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 with faded modules will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that prints with faded modules.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The modules are a solid dark colour in the file
- Economy and toner-save modes are off
- The proof modules are dark with strong contrast
- 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)
