What you are seeing
The printed code is a mirror image of the design: left and right are swapped, and no phone can scan it. A mirrored code looks almost identical to a correct one at a glance, which is why it survives a casual proof check. The cause is usually a print or transfer step that flips the image: an iron-on transfer, a stamp, an engraving, a print-on-the-reverse process, or a flipped image in the layout. The fix is to catch the flip at the proof stage and to correct the file or the process so the finished print reads correctly.
Likely causes
1.
Transfer or reverse print process flips the image — Iron-on transfers, some stamps, and reverse printing deliberately flip the image, so the finished print is mirrored unless the file is pre-flipped. Test: compare the finished print with the digital file.
2.
Image flipped in the layout — A designer can accidentally flip the code image while arranging the layout. Test: compare the layout file with the original export.
3.
Plate or engraving reversed — A plate, screen, or engraving made from a flipped image produces a mirrored print. Test: compare the plate or screen with the digital file.
4.
Viewing the print from the reverse side — A code printed on a transparent material can look mirrored when viewed from the back. Test: view the print from the intended side.
5.
Proof checked without scanning — A mirrored code looks plausible to the eye, so a visual proof check misses it. Test: scan the proof instead of only looking at it.
Step-by-step fix
1. Compare the proof with the digital file, checking the position of the three finder patterns.
2. Scan the proof. A mirrored code will not scan, which confirms the flip.
3. Find the step that flips the image: the layout, the plate, or the transfer process.
4. Correct that step: unflip the layout image, or pre-flip the file for a transfer process.
5. Print one corrected proof and scan it on two phones.
6. Approve the run only when the proof scans and the finder patterns match the file.
Putting this into practice
In practice, the finder patterns are the giveaway: a correct code has them in three corners, and a mirrored code has them in the mirrored corners. Check the corner positions on every proof, and scan the proof instead of only looking at it. A scan test catches a mirror flip that the eye misses. 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
- Proofing a mirrored code by eye only, without scanning it, and approving a run that no phone can read.
- 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 mirrored will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that prints mirrored.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The proof finder patterns match the digital file
- The proof scans on two phones
- The transfer or plate orientation is correct for the process
- 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)
