Generate a QR code in your own foreground and background colors, then find out whether that palette actually decodes
The ratio between the brightness of two colors. Identical colors give 1; black against white gives the maximum of 21. A scanner splits the image into light and dark pixels before it reads the grid, so what matters is the brightness gap, not the hue. Red on green looks obviously different to a human, yet the two are close in brightness and the thresholding step loses the module edges. This tool flags anything under 4.5 as thin and anything under 3.0 as unsafe.
The generated image is passed to a QR reader as is. A sufficient contrast ratio does not guarantee a decode. The usual cause is inversion: the standard assumes dark modules on a light background, so light modules on a dark background split devices into those that scan it and those that do not. This tool turns automatic inversion off on purpose, so you see the strict answer rather than the optimistic one.
No. Error correction helps when each module was still classified as dark or light and some of those values are wrong because of dirt or damage. If the palette makes that classification impossible in the first place, nothing knows which modules are broken and correction cannot run. Fix color problems with brightness, not with error correction. Raising the level also adds data, which pushes the version up and makes the modules smaller, so scanning gets harder rather than easier.
A scanner first converts the captured image into light and dark pixels, then reads the module grid from that. If the foreground and background have similar brightness, that thresholding step cannot find the module edges and the scan fails. What matters is the brightness difference, not the hue, so a red-on-green code becomes unreliable even though the two colors look obviously different. A clean image on screen may still decode, but printing and photographing it will often break it.
Inverted codes scan on some apps and not others. The standard assumes dark modules on a light background, so for print you cannot rely on inversion. This tool deliberately disables automatic inversion, so an inverted palette is reported as unreadable and you can see the strict result.
No. Generating the code, computing the contrast ratio and running the decode all happen in your browser with JavaScript. Nothing is sent to a server.