What you are seeing
The printed code comes out in colours that differ from the design: washed-out modules, a shifted hue, a background that darkened, or a pair that looked high-contrast on screen and prints weakly. Colour problems matter because scanning depends on contrast, not on how attractive the colours look. A printer, a stock, or a colour profile can each shift the result, and the screen preview hides all three. The fix is to print a proof, compare it with the design, and correct the stage that shifted the colour.
Likely causes
1.
Screen colours do not match print colours — A monitor and a printer reproduce colour differently, so a pair that looks bold on screen can print weakly. Test: compare a printed proof with the screen design under good light.
2.
Wrong colour profile or mode — A file prepared for screen can print unexpectedly when the printer expects a different colour mode. Test: check the file colour settings and the printer profile.
3.
Stock changes the colour — Coloured, recycled, or coated stock can shift the printed colour, and a dark stock can darken the background. Test: print the same file on plain white stock and compare.
4.
Low ink or toner — A printer low on one colour can drop or weaken that colour across the whole job. Test: print a test page and check for missing or faint colours.
5.
Colour pair too close in lightness — Two colours that differ in hue but not in lightness can look distinct to the eye while the camera sees them as similar greys. Test: view a photo of the code in greyscale.
Step-by-step fix
1. Print one proof on the real stock and compare it with the screen design.
2. View a photo of the proof in greyscale to judge the contrast the camera sees.
3. Check the file colour settings and the printer profile.
4. Test the same file on plain white stock to separate a stock problem from a printer problem.
5. Strengthen the pair: darker modules, lighter background, and more lightness difference.
6. Fall back to black on white if the colour pair will not print reliably, and retest.
Putting this into practice
In practice, judge QR colours by their greyscale contrast, not by how they look in colour. The camera reads lightness differences, so a pair that differs only in hue can fail even when it looks striking. Test every colour pair as a printed proof in greyscale before you approve it. 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
- Approving a colour pair from a screen preview without ever printing a proof on the real stock.
- 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 wrong colours 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 wrong colours.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The printed colours match the design on the real stock
- Greyscale contrast is strong on the printed proof
- The proof scans on two phones
- 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)
