The Surprising Engineering Behind QR Codes

QR codes look simple. Black and white squares encoding a URL. But building QR Cheetah revealed layers of engineering complexity hiding behind that grid of pixels.

Error Correction: The Hidden Superpower

Every QR code contains redundant data specifically so it can survive damage. The QR specification defines four error correction levels: L (7% recovery), M (15%), Q (25%), and H (30%). At level H, nearly a third of the code can be destroyed or obscured and a scanner will still read it correctly.

This is not just for damaged codes. Error correction is what makes branded QR codes possible. When you overlay a logo on a QR code, you are deliberately destroying part of the data. The logo covers modules (the individual squares) that contain encoded information. The code remains scannable only because the error correction algorithm can reconstruct the missing data from the redundancy. A logo that covers more than the error correction percentage will produce a code that some scanners cannot read -- which is why QR Cheetah defaults to level H when logo overlays are enabled.

Why Contrast Matters More Than Color

QR codes do not have to be black and white. They can be any two colors -- as long as there is enough contrast between them. Scanners work by distinguishing "dark" modules from "light" modules, and they need a minimum contrast ratio to do this reliably. QR Cheetah enforces WCAG AA contrast ratios (4.5:1 minimum) between the foreground and background colors before generating a code.

This catches the common mistake of choosing brand colors that look distinct to the human eye but confuse a camera. A dark blue on medium gray might look fine on screen, but a phone camera in poor lighting may not see enough difference to decode the pattern. The contrast check prevents users from creating beautiful codes that nobody can scan.

The iOS Safari Rendering Quirk

Apple's iOS has a built-in QR scanner in the Camera app and Safari. When a user scans a QR code with their iPhone camera, the resulting web request behaves differently from a normal browser visit. There is no referrer header, the fetch metadata indicates the request did not originate from a website, and the user agent string identifies Safari on iOS -- but with none of the typical navigation signals.

This combination is unique enough to identify iOS camera scans with high confidence. It matters for analytics because these scans represent physical-world engagement -- someone pointed their phone at a printed code -- which is a qualitatively different signal from someone clicking a link on a website.

Bot Traffic: The 40% Problem

When a QR code URL is shared in a messaging app or posted on social media, the platform generates a link preview by fetching the URL. WhatsApp, Facebook, Twitter, LinkedIn, and Slack all do this. Each preview fetch looks like a scan in the analytics unless you filter it out.

In practice, bot traffic can account for 40% or more of apparent scans. QR Cheetah identifies bot requests by matching known crawler user agent strings and excludes them from scan counts. Without this filtering, scan analytics would be meaningless -- a single share in a group chat could register as dozens of "scans" from the preview bots of every member's messaging app.