← Blog
Guides & Basics

10 Rules for QR Codes That Always Scan

Contrast, size, quiet zone, error correction and the practical rules that make the difference between a code that scans instantly and one that frustrates everyone.

8 min read

A QR code that does not scan is worse than no code at all — it advertises that you did not test your own marketing. The good news is that scannability is not luck. It follows a short list of physical rules about contrast, size and margins. Follow these ten and your codes will read on the first try, on cheap phones, in bad lighting.

Anatomy of a QR codeFinder patternsData modulesQuiet zone (margin)
10 Rules for QR Codes That Always Scan — at a glance

1–3: Contrast, color and inversion

Scanners read brightness difference, not color. The safest combination is dark modules on a light background — ideally near-black on white. You can use brand colors, but keep a strong luminance gap between foreground and background. A navy code on cream works; a light-blue code on white does not.

Never invert without testing: light modules on a dark background can work, but many older scanners assume dark-on-light and fail. And never use a busy photo directly behind the modules — if you must place a code on an image, drop a solid or lightly-tinted panel behind it first.

4–5: Size and scanning distance

The rule of thumb is that a code should be at least one-tenth of the distance it will be scanned from. A code read from two metres away should be roughly twenty centimetres wide. A code on a business card held at twenty centimetres can be two centimetres. Print it too small for its context and no amount of good design saves it.

For print, always export vector (SVG or PDF) so the code stays razor-sharp at any size. A pixelated PNG scaled up to poster size develops blurry module edges that confuse scanners.

6: Respect the quiet zone

Every QR code needs a clear margin around it — the “quiet zone” — of at least four modules' width. This blank border is how the scanner separates the code from surrounding clutter. Designers routinely crop it too tight to fit a layout, and it is one of the most common causes of an intermittent scan. Give the code room to breathe.

7–8: Logos and error correction

A center logo is fine — in fact it looks professional — but it covers data, so you must compensate. Keep the logo under about 20% of the code's area and raise the error-correction level to Q or H. Those higher levels build in enough redundancy to reconstruct the covered modules. Add a logo at level L and you are gambling.

The same applies to heavy styling: rounded modules, gradients and custom eyes all nibble at readability. They are great in moderation, but every stylistic flourish is a small withdrawal from the scannability budget — so bank extra error correction.

9–10: Test, then test differently

Before any print run, scan the actual exported file with several phones — at least one iPhone and one Android, ideally an older device. Preview windows lie; only a real camera confirms a code decodes. Then test the printed proof, not just the screen, because paper and ink behave differently from pixels.

Finally, test in the real environment: the dim corner of a restaurant, the glare on a shop window, the curve of a bottle. A code that scans on your desk can fail on a glossy curved surface. Catching that before the run is the entire point.

Build testing into your workflow as a non-negotiable final step, the same way you would proofread copy before printing. Keep a small ‘scan kit’ — an old Android phone, a current iPhone, and a note of the lighting conditions where the code will live — and run every code through it. The few minutes this takes are trivial next to the cost and embarrassment of a print run that does not scan.

Putting the rules together

These ten rules reinforce one another, and the easiest way to apply them is as a quick mental pass before any code goes out. Start with contrast: dark modules, light background, a real brightness gap. Then size it for the scanning distance and protect the quiet-zone margin. If there is a logo, keep it small and raise error correction. Export vector for anything printed. Finally, test the real file on real phones in the real setting.

Most failures trace back to skipping just one of these — a code shrunk to fit a layout, a margin cropped away, a logo added without extra error correction, a destination that was never tested on a phone. None of the mistakes are subtle once you know to look for them, which is exactly why a short checklist prevents almost all of them.

The reward for this small discipline is significant: codes that scan on the first try, on cheap phones, in poor light, every time. A code that works builds trust and gets used; a code that fails quietly undermines the whole piece of marketing it sits on. Treat scannability as a requirement, not a hope, and your codes will earn their place.

Key takeaways
  • Dark on light, with a strong brightness gap — color is secondary to contrast.
  • Size the code to at least 1/10 of the scanning distance.
  • Always leave the 4-module quiet-zone margin.
  • Logo under 20% + error correction Q or H.
  • Test the exported file on multiple real phones before printing.

Ready to put this into practice?

Create a free, branded QR code in seconds — no sign-up, no watermark.

Open the generator Try Animated QR