What you are seeing
The printed code shows visible square pixels and jagged edges instead of crisp modules. Pixelation comes from a raster file with too few pixels for the printed size, so each module is built from coarse blocks that the scanner reads unreliably. The screen version can look acceptable at a small display size, which hides the problem until the print is enlarged. The fix is to export a file with enough resolution for the printed size, or to use a vector file that has no pixels at all.
Likely causes
1.
Raster file too small for the print size — A small image enlarged for print spreads each pixel across several dots, which shows as visible blocks. Test: check the exported pixel size against the printed size.
2.
Screenshot used as the print file — A screenshot of a code carries screen resolution, which is far too low for print. Test: check whether the file came from a screenshot.
3.
Layout enlarged the image — An image placed small and enlarged in the layout inherits the same pixel shortage. Test: check the placed size against the exported size.
4.
Compression degraded the image — A heavily compressed file can blur and block the module edges. Test: check the file format and compression.
5.
Printer set to low resolution — A printer set to a low resolution can render even a good file coarsely. Test: check the printer resolution setting.
Step-by-step fix
1. Check the exported file: format, pixel size, and source.
2. Re-export the code at the exact printed size with plenty of pixels, or as a vector file.
3. Place the image at its native size in the layout, without enlarging it.
4. Set the printer to its normal or high resolution.
5. Print one proof and compare the module edges with the digital file.
6. Approve the run only when the proof is crisp and scans on two phones.
Putting this into practice
In practice, the file is the fix. A vector export removes pixelation entirely, because the printer renders the modules at its own resolution. Whenever a print file is available as a vector, use it, and keep screenshots for screen mock-ups, never for print. 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
- Using a screenshot of a QR code as the print file and discovering the pixelation only on the finished run.
- 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 pixelated will be used.
- Changing the artwork and the placement at the same time, so you cannot tell which change fixed a code that prints pixelated.- Skipping the proof test because the change looked small, when small changes cause most repeat failures.
Quick checklist
- The print file is vector or high-resolution at the printed size
- The proof shows crisp module edges
- 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)
