QR Code Colors That Actually Scan

The two rules

Every color question about QR codes reduces to two rules. Follow both and you can use nearly any color you like. Break either one and your code will fail for some meaningful slice of the people who point a phone at it.

Rule one: dark pattern, light background. Never the reverse. The squares that carry the data should be the dark color, and the space behind them should be the light color. A white pattern on a navy background looks sharp in a mockup and fails on a depressing number of real phones. More on that below.

Rule two: keep the contrast strong. It is not enough for the two colors to be different. They have to be different in brightness. A scanner does not see hue the way you do.

Both rules exist because of one step in how scanning works. Before a phone decodes anything, it binarizes the image: it converts every pixel to pure black or pure white based on brightness. Hue gets thrown away entirely. If your two colors end up on the same side of that black-or-white cut, the pattern disappears and there is nothing left to decode. Dark-on-light with strong contrast survives binarization. Everything else is a gamble.

Combos that work, combos that fail

Here is the honest list. The left column is safe to print. The right column is where codes go to die quietly, because they often scan fine on the newest phone in the office and fail on everyone else's.

Notice the theme. The working column is always a genuinely dark color on a genuinely light one. The failing column is either inverted, low contrast, uneven, or shiny. If a combo you are considering fits any of those four words, pick again.

Why inverted codes fail

The QR spec was built around dark modules on a light background, and scanners were built to expect that. Plenty of modern decoders will try flipping the image and reading it inverted. Plenty of others will not, especially older phones, budget phones, and the embedded scanners built into payment terminals, ticket gates, and warehouse guns.

That gap is the whole problem. An inverted code is not broken everywhere. It is broken somewhere, and you do not get to choose where. When you print a code, you are printing for every phone that will ever meet it, not just yours. A code that only some phones can read is a broken code in print. There is no partial credit.

This one is sneaky because your own test will probably pass. You design the white-on-navy code, scan it with your recent iPhone, it works, you send it to the printer. The failures show up later, one confused customer at a time, and nobody tells you.

This is why the tool checks for it specifically. If you set a light pattern on a dark background, it warns you before you download, separately from the contrast check, because an inverted code can have perfect contrast and still fail. Use the swap-colors button and the problem is gone in one click.

Branding without breaking it

You do not have to settle for black. Here is the approach I recommend for putting your brand on a code without gambling with it.

Use your darkest brand color for the pattern. Most brand palettes have a deep primary: a navy, a forest, an aubergine, a near-black. That is your pattern color. Paste the hex straight into the tool's custom color field.

Use white or a near-white tint for the background. Pure white is safest. A very pale tint of your brand color also works and looks more designed. Keep it pale enough that you would call it "basically white" from across the room.

Put the accent around the code, not in it. If your brand color is bright orange or teal, it does not belong in the pattern. Use it in the frame, the call-to-action text, or the material the code sits on. The code itself stays dark-on-light, and the design around it does the branding.

A logo in the middle is fine. When you add one in the tool, error correction rises to the highest level automatically, so the code can afford the covered area. I wrote up the size limits in the logo size guide.

Transparent backgrounds work with one condition. The tool can export the code with no background at all, which is handy for dropping it onto a designed layout. But whatever surface ends up behind the pattern becomes the background, so that surface has to be solid and light. The tool flags this case too, since it cannot see your final layout for you.

Print changes the math

Everything above gets harder on paper. A screen is backlit, so it hands the scanner more contrast than the colors deserve. Paper only reflects whatever light happens to be in the room, and then the printing itself takes a cut.

Ink spreads slightly as it soaks in, which fattens the dark modules and shrinks the light gaps. Laminate and glossy stock add glare, which reads as bright noise across the pattern. And the room takes the biggest cut of all: a restaurant at dinner is running warm, dim light that flattens every color toward brown. A combo that barely clears the contrast bar on your monitor can fail completely on a table tent under that light.

So give print a margin of safety. If your combo squeaks past on screen, darken the pattern or lighten the background before you send it out. Then do the only test that actually settles it: scan the printed proof, in the room where it will live, with the oldest phone you can borrow. Not the design file. The physical object, in its real light. If something still refuses to scan, the troubleshooting guide walks through the usual suspects, and the print size guide covers the other half of print reliability.

FAQ