QR code generator

Static and dynamic codes are not two features. They are two products

Search for a QR generator and most of the first page will hand you a dynamic code. It looks the same and it behaves differently in one crucial way: the square does not contain your link. It contains a short address on the generator's domain, and when somebody scans it their phone goes there first and is forwarded on. That indirection is what makes the marketed features possible — editing the destination after printing, counting scans, targeting by country — and it is also what makes the code a rented asset. The moment the account lapses, the trial ends or the company is acquired and the old domain quietly stops resolving, every printed copy of that code becomes a dead link. There are a great many dead menus and dead estate agent boards in the world for exactly this reason.

A static code has none of those features and none of that risk. Everything you typed is encoded in the pattern itself, so scanning it never touches anyone's server, and the code keeps working with no account, no subscription and no company behind it. If the destination needs to change later, the answer is to point the URL you encoded at something you control — a short path on your own domain — and change where that goes. That is the same benefit without handing anyone else the keys to your printed material.

Every content type has a real format behind it

A QR code is a way to carry a string of text, and what a phone does with that string depends entirely on the string being in a shape the phone recognises. This is the part most generators get approximately right and some get plainly wrong.

Wifi credentials use WIFI:T:WPA;S:network;P:password;;. The separators are significant, which means a network name containing a semicolon, a colon, a comma or a backslash has to be escaped or the parts run together and the phone reads nonsense. A contact card is vCard 3.0 with carriage-return line endings, because that is what address books parse. An email is a mailto: address with the subject and body percent-encoded as query parameters. A phone number is tel:, and a message is SMSTO: — not sms:, which is handled inconsistently across phones. Get any of these wrong and the code still scans perfectly; it just shows a line of text instead of doing the thing, which is a failure nobody notices until it is printed on five hundred flyers.

Why the square grows, and the three ways to shrink it

QR codes come in forty fixed sizes, called versions, from 21 modules across up to 177. The encoder picks the smallest one your content fits into, so adding a few characters can push you over a boundary and suddenly the pattern has noticeably more, smaller squares. Three things pull it back.

The first is shorter content — a link of forty characters instead of a hundred and forty. The second is a lower error correction level, which is a genuine trade rather than free space, and is covered below. The third is the least known: the format has three ways of packing data, and it chooses automatically based on what you typed. Digits alone are stored at about three and a third bits each. Capital letters, digits and a handful of punctuation marks — the setA–Z 0–9 space $ % * + - . / : — are stored at five and a half bits each. Anything else, including any lower-case letter, falls back to eight bits per byte, and accented or non-Latin characters take several bytes apiece. That is why a phone number produces a much simpler pattern than a web address of the same length, and why an all-capitals link is denser than a mixed-case one.

This tool will not capitalise a link to reach that denser mode, and it is worth saying why, because some generators do. The domain part of a URL is case-insensitive but the path is not:example.com/Menu and example.com/menu are different pages on most servers. Silently upper-casing to save a few modules would produce a smaller code that goes somewhere else, and a code that scans to the wrong page is a worse failure than a large one, because nothing about it looks wrong.

Error correction is insurance, and it is priced in capacity

Part of every QR code is redundant data that lets a scanner rebuild sections it cannot read. There are four levels: L recovers roughly 7% of the code, M about 15%, Q about 25%, and H about 30%. That redundancy occupies room that would otherwise hold your content, so raising the level either reduces what fits or grows the grid — the panel above tells you which, for what you have actually typed, rather than making you guess.

For a code on a screen, in a slide or in an email, M is right; nothing is going to damage it. For anything printed on a surface that will be handled, weathered or partly covered — a table sticker, a delivery van, a piece of packaging, a poster at a bus stop — Q or H is worth the extra modules. The one place people overestimate what error correction buys them is logos. Covering the centre of a code works because the redundancy rebuilds what the logo hides, but that redundancy was the margin for a fingerprint, a crease or a scuff, and once it has been spent on branding it is not there for anything else.

Printing one so it actually scans

The rule of thumb worth remembering is that a code should be about one tenth of the distance it will be scanned from. Something read at arm's length, like a menu or a leaflet, wants around 3cm across. A poster read from three metres wants around 30cm. Below roughly 2cm, phone cameras begin to struggle regardless of distance, and a dense code — a long contact card at level H, say — needs more room than a short link because its individual squares are smaller.

Two details cause most printed failures. The first is the quiet zone: the blank margin around the pattern is part of the specification, four modules wide, and scanners use it to find the edges. Cropping it off or running artwork up to the pattern is a common way to break a code that worked on screen. The second is contrast and polarity. Dark pattern on a light background is what scanners expect; inverting it, or printing dark on dark, will fail on many phones even when a preview looks fine. If you take one precaution, it is to scan the printed proof with more than one phone before the run.