Design that still scans

On this page: The one principle · Colour · Gradients and transparency · Module and corner shapes · Logos · What to avoid

The one principle behind every rule

A scanner does not see your design. It reduces the image to a grid and asks one question about each cell: is this square darker or lighter than its neighbours?

Every design rule below exists to keep that one judgment easy. Anything that makes a module's lightness ambiguous, or that destroys the three corner targets a scanner uses to find the code, creates a failure. Anything that does not do those two things is safe, and there is more freedom inside that boundary than most people expect.

Colour

What works

The scanner compares luminance — brightness — not hue. That means almost any hue pairing is fine as long as one is clearly darker than the other:

• Deep navy code on white — excellent, and looks far more considered than pure black.
• Dark green code on a warm off-white — excellent contrast, and softer than pure black on paper.
• Dark purple code on a pale lilac tint — works well, because the luminance gap is large even though both are "purple".
• Any dark, saturated colour on white or a very light tint — safe.

What fails

• Two mid-tones together. Blue on teal, orange on red, purple on magenta — these look bold and have almost no luminance gap. A camera cannot separate them.
• Light code on white. A pale yellow or pastel pink code is the most common "pretty" mistake. It is nearly invisible to a scanner and often to people too.
• Light code on a dark background. This actually has excellent contrast and very often works on modern phones — but many older scanners and industrial readers cannot process an inverted symbol at all. Use it knowingly, and give the code a light border so there is a clear quiet zone if you invert.
• Busy photographic backgrounds. A code over a photo has unpredictable local contrast and unpredictable quiet zones. If you must, put the code on a solid panel rather than directly on the image.

Gradients and transparency

Gradients are safe if every point along the gradient stays clearly darker than the background. The catch is where the lightest point lands.

On a diagonal gradient the light end sits at one corner of the code. Two of the three corner finder patterns are at the corners. So a gradient that fades toward a mid-tone can put your locator targets at the weakest contrast in the whole symbol — the modules there are still correct, but the camera struggles to find them. This is a real and under-appreciated failure mode, and it typically produces intermittent scanning: fine on a good screen, unreliable in print.

QRMint handles this by measuring the gradient at both ends and at its midpoint, and quietly deepening a stop that would put the corners at risk. You keep the colour you chose, and the drawn output is nudged only as far as it needs to be.

Transparency

A transparent background is useful for placing a code over a coloured panel or a branded container — but transparency is about the background, not the code. Note two things:

• Whatever shows through becomes your real background, so check the contrast against that, not against white.
• The quiet zone must also be transparent, and must end up on a uniform surface. A transparent margin over a patterned backdrop gives you no quiet zone at all.

If you are printing, do not use transparency at all. Composite it onto the intended background colour first so what you see is what prints.

Module and corner shapes

Modules are the small squares. Changing their shape is the most common way people try to make a code look modern, and it is where good intentions most often cause damage.

The governing rule is simple: keep every module's ink inside its own cell. The scanner samples the centre of each cell. As long as the ink is centred and clearly covers the middle, it reads correctly.

Safe

• Square modules. The baseline. Maximum ink, maximum reliability, and it scans fastest from the greatest distance.
• Rounded modules. Squares with rounded corners, inset so each module still fills its cell. Softer and more designed than squares, with reliability that is effectively identical. Use a moderate corner radius — a very large radius on a dense code starts removing ink from the cell centre.
• Custom corner frames and centres. The three large squares can be rounded, squared or circular without harming anything, provided the ring stays a full module thick and the centre stays a solid 3×3 block of ink.

Unsafe

• Circular "dot" modules. Attractive, popular, and the most damaging common choice. A circle inscribed in a square covers only about 78% of the cell area, and it tapers to nothing exactly at the cell edges, which is the region the scanner needs in order to judge light against dark. In testing, dotted codes failed to decode at every export size, including 2048 px with modules 55 px wide — so this is geometry, not resolution.
• Very small modules within their cells. Shrinking every module to 60% of its cell leaves large light gaps and weakens the signal, even without changing the shape. Keep the module size at 70% or above.
• Joined or connected blobs. Styling that merges neighbouring modules into continuous shapes changes which cells read as dark, which corrupts the data.

QRMint deliberately offers only square and rounded modules, and leaves dots out entirely. If a design tool offers dotted modules, treat them as decoration rather than a working code.

Logos

Embedding a logo is the most valuable design move available, because it turns a generic pattern into something recognisable. It is also the move with the strictest limits.

• Use error correction level H. It recovers about 30% of the symbol. At level M (15%), a logo of any useful size overruns the budget.
• Keep the logo under about a quarter of the code's area — roughly 22% of its width, since area grows with the square of width. Beyond that you are relying on luck.
• Never let the logo reach the corner squares. Finder patterns carry no error correction. Damage them and the code fails outright, whatever your level.
• Give the logo a solid plate. A transparent logo lets the modules behind it show through as noise, which is harder to read than a clean occlusion. QRMint adds a plate by default.
• Test the actual print. A logo at 20% of a version-8 code on a clean screen will usually scan. The same code laminated, printed at 25 mm, in a dim cafe, may not.

What to avoid

A design process that works

1. Start from a dark-on-light preset so the baseline is reliable.
2. Pick a hue that suits your brand, then darken it until the contrast reading is comfortable. A deep version of your brand colour usually looks more premium than the brighter one anyway.
3. Choose square or rounded modules to match your typography — rounded for soft or friendly brands, square for technical or editorial ones.
4. Customise the corners to echo your logo's geometry. This is high impact and zero risk.
5. Add the logo last, keep it under a quarter of the area, and use the plate.
6. Check the scan report before downloading, then print one proof and test it on two phones.

That sequence gives you a code that looks designed and scans reliably, without needing to understand the standard. The report catches the moments where a choice crosses the line, which is far more useful than a general warning to "keep it simple".

Related reading

• Why QR codes fail to scan — the four causes, diagnosed.
• How big should a QR code be? — sizes, modules and export formats.
• Security and privacy — what a code reveals about the people who scan it.