Why Logo QR Codes Fail to Scan: 5 Things We Found

We built a QR generator that takes its colours from an uploaded logo. The first version produced codes that looked excellent and would not scan. Not "scanned slowly on a bad phone" but would not decode at all, on any device we tried.

Fixing it meant testing each setting on its own and reading the codes back with a decoder rather than trusting our eyes. Most of what we found is not in the design guides, because the design guides talk about branding and this is a question about image processing. Here is what actually decides whether a styled QR code works.

1. The three corner squares must stay solid, whatever the rest of the code does

This was the single biggest cause of failure, and it is the one most styled generators get wrong.

The three large squares in the corners are called finder patterns. A scanner uses them to work out where the code is, how big it is, and how it is rotated. It does that by scanning a line across the image and looking for a specific run of dark and light: one part dark, one light, three dark, one light, one dark. That 1:1:3:1:1 ratio holds true no matter what angle you hold the code at, which is exactly why the format uses it.

The moment you style those corners, you break the ratio. Round them into dots and the dark runs measure short. Let them take colour from a logo and one part of the run comes out lighter than another. The scanner stops finding the pattern, and if it cannot find the pattern it never gets as far as reading your data. The code is not damaged. It is invisible.

What made this hard to diagnose is that partial styling of the corners does not fail cleanly. It fails intermittently, which is worse, because you test it once on your own phone in good light, it works, and you send it to print.

Our generator now treats the corner cells as a special case. They always render in one solid colour, even in the mode where every other dark square is sampled from your uploaded image.

2. Colour is not the problem. Brightness is.

People assume a scanner sees colours. It does not. It converts the image to brightness and then decides which cells are dark and which are light. Hue is thrown away before the decoding starts.

That single fact explains most colour QR failures. A rich orange and a mid grey can look completely different to you and land at nearly the same brightness. To the scanner they are the same cell.

It also explains why sampling colours from a logo goes wrong. A logo contains light areas. Any dark cell that happens to sit under a pale part of the image comes out too light to register as dark.

The fix that worked was a brightness ceiling. Every colour taken from the image gets pushed down until its brightness sits under a set limit, while its hue is left alone. You still see the logo colours running through the code. The scanner still sees cells that are unambiguously dark. Our tool exposes this as a slider from 0.15 to 0.80 and starts at 0.45, which held up across every image we tested.

Raise it and the code looks brighter and more like the original logo, right up until it stops decoding. Lower it and everything trends towards black, which always scans and always looks duller.

If you are picking colours by hand rather than sampling them from an image, our guide on whether QR codes can be coloured covers the contrast rules in more detail.

3. A light code on a dark background fails even when the contrast maths says it is fine

Inverted codes, light modules on a dark field, are popular in design work. They are also unreliable, and the reason is not contrast.

We ran inverted pairs through a standard contrast check. A white code on a near black background scores about 18.9 to 1, which is far beyond anything a readability guideline asks for. It still fails on a good number of phones, because many decoders assume dark modules on a light background and never try the inverse.

Some readers handle inversion. Enough do not that you should treat it as broken for anything printed. The background checker built into our transparent QR code generator now rejects an inverted pair outright rather than passing it on the contrast number, because a high ratio in the wrong direction is still a code that half your audience cannot scan.

4. Error correction is a repair budget, and a logo spends it

QR codes carry redundant data so they still read when part of the symbol is damaged. The standard sets four levels: roughly 7 percent recoverable at L, 15 at M, 25 at Q and 30 at H. That is defined in ISO/IEC 18004, not something we measured.

What gets misread is the conclusion people draw from it. "Level H allows 30 percent damage" becomes "I can cover 30 percent with my logo", and that is not the same statement. The budget is shared. A scuff on the print, a fold, glare, a slightly out of focus camera and your logo all draw from the same 30 percent. Spend it all on the logo and there is nothing left for the real world.

In practice we found the usable ceiling sits around 25 percent of the code area at level H, and our tool caps the logo slider at 30 percent with a warning above 25. Below roughly 22 percent, codes survived being resized, printed small and photographed at an angle. Above it, failures started appearing in exactly the conditions a printed code meets.

Worth knowing: raising the error correction level makes the symbol denser, because the redundancy has to go somewhere. A denser symbol needs to be printed larger to stay readable. Level H is not free.

5. Test by decoding, not by looking

The mistake that cost us the most time was checking our work by scanning with one phone. Modern phone cameras are very good, they correct for a lot, and they will happily read a code that a cheap handheld scanner or an older Android will refuse.

Reading each generated code back with a decoder, on the actual image file rather than a photograph of a screen, turned an unreliable opinion into a yes or no. Several settings that looked fine on a phone failed that check immediately.

If you are making styled codes at any volume, decode your own output before it goes anywhere near a printer.

If you have a code that already will not read and it is not a styling problem, our list of fixes for a QR code that is not scanning covers the print and camera side.

What to do if you are making one

• Leave the three corner squares solid and dark. Style everything else if you want to.
• Judge your colours by brightness, not by how different they look. Dark code, light background, every time.
• Do not invert. A light code on a dark field fails on too many readers regardless of contrast.
• Keep the logo under about a quarter of the code. Leave repair budget for print and camera problems.
• Keep the quiet zone. The standard asks for four modules of clear space around the symbol, and designers crop it constantly.
• Decode the file, then test the printed piece. One phone in good light proves nothing.

How we tested, and what this does not cover

These findings come from building and debugging our own logo QR generator, changing one setting at a time and decoding the resulting image files programmatically rather than judging them by eye. Where a number comes from the specification rather than our own testing, we have said so.

Two honest limits. We tested image files and printed samples, not every scanner app on every handset, so "fails on a good number of phones" is a description of what we saw and not a measured percentage. And decoder behaviour changes: a build that rejects inverted codes today may accept them next year. The parts that will not change are the ones set by the format itself, which is the finder patterns, the quiet zone and the error correction budget.

Related: all QR code tools