What you are seeing
This fix restores the standard dark-on-light polarity to the printed code. You will find the step that inverted the image, correct it, and reprint a single proof. If an inverted design is genuinely required, you will prove it with a scan test on two phones before approving it.
Likely causes
1.
Design uses inverted colours — Quick test: compare the proof with the standard dark-on-light version.
2.
Print setting inverts the image — Quick test: check the print and layout settings for an invert option.
3.
Material reverses the appearance — Quick test: compare the finished print with the design file.
4.
Background panel darkened in print — Quick test: compare the printed background with the design.
5.
Proof never scanned — Quick test: scan the proof.
Step-by-step fix
Step 1: Compare the proof with the design file and confirm the polarity is inverted.
Step 2: Scan the proof on two phones to confirm whether the inverted version fails.
Step 3: Check the design, the layout, and the print settings for an invert, negative, or reverse option.
Step 4: Restore dark modules on a light background in the file or the settings.
Step 5: If the material causes the inversion, switch to a light stock with dark ink, or reverse the artwork for that material.
Step 6: Print one corrected proof and scan it on two phones.
Step 7: Approve the run only when the proof scans. Keep an inverted design only if it passes on two phones.
Putting this into practice
In practice, add a polarity check to the proof routine: confirm the modules are dark and the background is light before you scan. A proof that is inverted is a proof that fails, however attractive it looks. 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
- Shipping an inverted code because it looked stylish, without ever scanning the proof.
- 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 inverted will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that prints inverted.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The modules are dark on a light background
- No invert setting is active in the layout or printer
- 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)
