QR Code Generator

What is actually in the pattern

A QR code is a grid of modules with a fixed structure. The three large squares in the corners are finder patterns, which let a scanner locate the code and work out its orientation at any angle. Smaller alignment patterns appear in larger versions to correct for the distortion of a code photographed on a curved or tilted surface. The dotted lines between the finders are timing patterns, giving the scanner the module grid. Around the finders sits format information describing the error correction level and the mask.

Everything else is data plus error correction, interleaved. There are 40 versions, from 21 by 21 modules up to 177 by 177, and the smallest one that fits your content is chosen automatically - which is why the code visibly densifies as you type.

The encoding mode matters more than people expect. Numeric content packs at about 3.3 bits per digit, alphanumeric at 5.5 - but the alphanumeric set is uppercase only, with a handful of symbols. Anything else falls back to byte mode at 8 bits per character. This is why HTTPS://EXAMPLE.COM/PATH produces a noticeably simpler code than the same URL in lowercase: the scheme and host are case-insensitive, so uppercasing them is free, and the difference can be a version or two.

Making one that scans reliably

Keep the quiet zone. The specification requires four modules of clear space on all sides, and removing it to fit a layout is the single most common reason a printed code fails. Scanners use it to find the code at all.

Keep the polarity. Dark modules on a light background is what every scanner expects; inverted codes are read by some and not others. Keep the contrast high, avoid gradients and photographic backgrounds behind the modules, and if you are colouring it, change the dark colour rather than lightening it.

Size it for the distance. The working rule of thumb is that the code should be about a tenth of the scanning distance across - so roughly 3cm for a phone held at 30cm, and much larger than people expect on a poster read from across a room. On print, keep modules from falling below about 0.4mm, and check the actual printed piece rather than the screen proof.

If you are placing a logo in the middle, raise the error correction to H first. That reserves around 30% redundancy, which is what covers the obscured area - but the logo still needs to stay away from the finder patterns, and it is worth scanning the result with two or three different phones before printing a thousand of them.

Payload formats

A QR code carries text, and what a scanner does with that text depends on conventions. A URL opens. Anything else is usually shown as plain text unless it matches a known form.

Wi-Fi uses WIFI:T:WPA;S:networkname;P:password;; with T set to WPA, WEP or nopass. Note the semicolons are required and that special characters in the name or password need escaping with a backslash. A phone number is tel:, an email is mailto: with the usual query syntax for subject and body, and a location is geo: with latitude and longitude. Contact details use vCard, which is verbose but very widely supported.

Anything relying on an app-specific scheme will only work where that app is installed, which is why a plain https URL that redirects is usually more robust than a clever custom one.

Static and dynamic codes

The code generated here is static: your content is encoded directly into the modules. It works forever, works offline, depends on no service, and reports nothing to anyone. It also cannot be changed - if the URL it points at moves, every printed copy is dead.

A dynamic code solves that by encoding a short redirect URL owned by a provider, who forwards it wherever you currently point it and counts the scans on the way through. That is genuinely useful for a campaign whose destination will change, and it is worth being clear about what it costs: the provider sees every scan, the code stops working if the account lapses or the service shuts down, and many free generators quietly produce dynamic codes without saying so.

If you want the flexibility, the honest way to get it is a static code pointing at a short URL on a domain you control, redirecting server-side. You keep the ability to change the destination and nobody else is in the path.

How error correction lets a damaged code still scan

QR codes use Reed-Solomon coding, the same family of error-correcting codes that protected data on CDs and is used in deep-space communication. The idea is to treat the data as coefficients of a polynomial and transmit extra points on that curve, so that as long as enough points survive, the original can be reconstructed exactly.

Four levels are available. L recovers about 7% of the codewords, M about 15%, Q about 25% and H about 30%, and the redundancy is spread across the symbol rather than concentrated, which is why damage in one corner rarely matters. Higher levels do not make a code more readable in good conditions; they make it survive worse ones, at the cost of a denser pattern for the same content.

M is the sensible default for a screen or a clean print. H is for codes that will be printed on curved surfaces, exposed to weather, or partly covered by a logo. Raising the level raises the module count, so an H-level code of a long URL can be noticeably finer-grained than the M-level equivalent, which works against you if the printed size is fixed.

Capacity, and why shortening the content helps

Capacity depends on version, error correction level and encoding mode together. At version 10 - a 57 by 57 grid - with M-level correction, a code holds roughly 271 alphanumeric characters or 213 bytes. At the maximum version 40 the numbers run into the thousands, but a symbol that large is impractical to print and slow to scan.

The encoding mode is the lever most people miss. Numeric content packs at about 3.3 bits per digit, alphanumeric at 5.5, and everything else falls back to 8 bits per character. The alphanumeric set is uppercase letters, digits and nine symbols, so HTTPS://EXAMPLE.COM/PATH encodes far more efficiently than the lowercase form, and the scheme and host are case-insensitive so uppercasing them costs nothing.

Shortening a URL is the other lever, and it applies before any of this: fewer characters means a lower version, larger modules at the same printed size, and a code that scans from further away and in worse light.

Quishing, and what a scanner should show

A QR code is opaque to the person scanning it. That is the whole basis of what is now called quishing: stickers placed over legitimate codes on parking meters and restaurant tables, codes in emails that bypass link scanners because they are images, and codes on posters leading to convincing payment pages.

The defences are mundane. A scanner that previews the URL before opening it is worth choosing, and every current phone camera does this. Look at the domain rather than the page, since a payment page is trivially cloned. Be suspicious of a physical code that looks applied on top of something else, which is what a sticker over a printed code looks like at close range.

For anyone publishing codes, the useful counterpart is to point them at a domain people recognise as yours rather than a shortener, so the preview means something. A code that resolves to a random short domain is indistinguishable from an attacker's.

Tracking scans without handing over the code

Dynamic codes from a provider are the usual way to count scans and change a destination, and the cost is real: the provider sees every scan, the code stops working if the account lapses, and some free generators produce dynamic codes without saying so - meaning the code you printed depends on a service you never chose to depend on.

The version you control is a static code pointing at a short path on your own domain, with the redirect on your own server. Changing the destination is a configuration change, the analytics land in your own logs, and nobody else is in the path. A separate path per campaign gives you the per-placement counts that dynamic codes are usually bought for.

Either way, the code itself never reports anything. Scans are counted when the destination is requested, which means a code printed on a poster and photographed but never opened is invisible, and anyone who copies the URL by hand is counted the same as a scanner.

A checklist before something goes to print

Test the actual artefact, not the artwork. Print the code at final size, on the intended material, and scan it with at least three phones including an older Android one. Test in the lighting the code will live in - a code on a dark wall in a dim bar is a different problem from the same code on a desk.

Check the quiet zone survives the layout. Four modules of clear space on every side is a specification requirement, and the most common reason a printed code fails is a designer pushing text or a border into that margin to make the composition work.

Confirm the destination before the run, and keep it working afterwards. A code outlives the campaign that created it: the URL it points at should redirect rather than 404 when the landing page is retired, because a printed code cannot be edited and copies of it circulate for years.