QR Codes, Properly Explained

Most people now treat a QR code as "a URL turned into a grid." That's a useful surface model, but it explains none of why they actually work — or why the one printed on the back of your last conference badge didn't.

What's inside

Strip away the mystique and a QR code is bytes. The black-and-white modules encode a sequence of bits, the scanner extracts them, and the OS or app decides what to do with the result. The QR standard defines four input modes — numeric, alphanumeric, byte, kanji — but says nothing about meaning. A URL, a Wi-Fi credential, a vCard, a payment intent are all conventions layered on top by whatever code decodes the bytes.

This is why the same image opens a browser when scanned through your camera and joins a network when scanned through your phone's Wi-Fi settings. The QR itself has no opinion either way.

Why it scans so reliably

Three pieces do almost all of the work:

• Finder patterns. The three concentric squares in three corners. Decoders look for their 1:1:3:1:1 stripe ratio across any line through them. That ratio is preserved under rotation and most perspective distortion, which is why you can scan one taped to a curved coffee cup.
• Quiet zone. The blank margin around the code. The spec calls for four modules; many decoders cope with two or three, but failure rates climb fast. People underestimate this.
• Reed-Solomon error correction. Built in. Even at the lowest level you can lose 7% of the modules and still recover the data.

Note the order. When a code scans poorly, the instinct is to crank up error correction. In practice, quiet zone, contrast, and physical size matter more — and fixing those is usually free.

The four error correction levels

L, M, Q, and H — recovery rates of roughly 7%, 15%, 25%, and 30% of the modules.

Higher levels add redundancy, which means more modules to draw, which at a fixed physical size means each module gets smaller. The folk wisdom — "use H so you can put a logo in the middle" — is half right. H tolerates ~30% obscuration, but the resulting code is also denser than the M-level equivalent, so each module is physically smaller in print. Below some threshold size for the medium and reader, an H-level code with a centered logo scans worse than the M-level version without one.

There's no clean rule of thumb. If you must pick one: default to M, only move up when you have a specific reason, and test on the real medium.

Static vs. dynamic

A static QR encodes the final payload directly. Whatever you put in is what scanners see, forever.

A dynamic QR encodes a redirect URL on a service you control. That service decides what to return — different destinations by region, A/B variants, an off-switch when a campaign ends, scan analytics. The price is a permanent dependency: if the redirect domain lapses or the vendor goes under, every printed copy is suddenly a dead end.

A pragmatic split:

• Long-lived, offline, content won't change → static.
• Anything tied to a campaign, anything you might want to measure or change → dynamic.

The interesting failure modes happen at the seams. A static QR pointing at a domain you may not renew in five years is a time bomb. A dynamic QR molded into a museum exhibit means a vendor outage takes the exhibit offline.

Why codes fail in the real world

Almost every "this QR doesn't work" report traces back to one of these:

• The payload is too long. The code has too many modules, and at the printed size a phone camera can't resolve them at normal scanning distance.
• Insufficient contrast. A brand-tinted code on a tinted background looks fine on a monitor and disappears under bad lighting.
• No quiet zone. Designers love butting the code against a border or another graphic.
• Logo too large. H gives you ~30% of modules to spend; a centered square at 25% area is usually fine, at 35% it's a coin flip.
• The code scans correctly but the destination is slow or 404s, and users blame the code.

The single most useful pre-flight check: scan the proof at the actual final size, with a phone you didn't design on, under worse-than-ideal lighting. Anything else is theater.

When a QR is the wrong answer

QR codes shine at the physical/digital boundary — posters, packaging, device pairing, table-side menus, ticketing. They earn their place by saving the user from typing.

They earn nothing on a desktop screen showing a short URL the user could type in five seconds. They're worse than nothing when the destination is a five-tap form that could have been a single tap from wherever the user already was.

Generating one well

• Shorten the payload first. Long URLs are the single biggest cause of unreadable codes; a redirect or shortener pays for itself.
• Pick the lowest error correction level that fits your design constraints. M is a good default.
• Keep the four-module quiet zone. Not three. Not "it looks fine."
• Test on at least two phones, ideally one that isn't yours.
• For print, test on the real stock at the real size. Glossy paper under store lighting behaves nothing like a monitor.