Static vs dynamic QR codes

One of these is a QR code. The other is a QR code pointing at a subscription. Knowing which you are buying changes what you print.

Every QR code generator sorts its codes into two buckets, usually with the interesting features locked behind the second one. The labels sound like a technical distinction. They are not — the QR specification has no notion of a "dynamic" code. Both produce exactly the same kind of pattern. The difference is entirely in what that pattern says.

What a static QR code is

A static code encodes your content directly. Type example.com/menu and the pattern contains those characters. A scanner reads them and opens them. Nothing else is involved — no server, no account, no network request beyond the one to your own page.

Consequences worth stating plainly:

• It cannot expire, because there is no service holding it up.
• It works offline at generation time and needs nothing from the generator afterwards.
• Nobody — including whoever made the code — can see who scanned it.
• You cannot change where it points. The address is in the ink.

What a dynamic QR code is

A dynamic code encodes a short URL on the generator's domain — something like qr.example/a1b2c3. When someone scans it, their phone opens that address, the generator's server records the scan and answers with a redirect to your real destination.

That extra hop is what buys the features:

• You can change the destination after printing, because you are editing a redirect rule rather than the code.
• You get scan counts, times, rough locations and device types.
• The encoded string is short, so the pattern is sparse and easy to scan even at small sizes.

And what it costs:

• The printed code belongs to your generator's uptime, domain and pricing. If any of those change, every copy you printed breaks at once — this is the single most common way a QR campaign dies. See why QR codes stop working.
• It is almost always a subscription. The code stops working when you stop paying.
• Every scan is logged by a third party, along with whatever their privacy policy allows them to do with it.
• Visitors see an unfamiliar domain flash past, which some phones now surface as a warning.

The comparison, briefly

How to get editability without renting your link

The genuinely useful part of a dynamic code — changing the destination later — does not require anyone else's service. It requires a URL you control.

Encode a permanent path on your own domain, for example example.com/go/menu, and make that path a redirect you can edit. Your web host, your CMS, or a two-line rule in your server config will all do it. Now:

• The printed code points at a domain you own, and nobody can switch it off.
• You change the destination whenever you like, by editing your own redirect.
• Your own analytics see the traffic, under your own privacy policy.
• There is no subscription attached to the print run.

So which should you use?

Use a plain static code when the destination is stable — your homepage, a Wi-Fi network, a contact card, a product page that will still be there next year. This covers most of what people actually print.

Use your own redirect when the destination has to move but the printed artwork cannot. Seasonal menus, event pages, campaign landing pages.

A hosted dynamic code is worth the dependency only when the analytics are the point — a marketing team measuring channel performance across many placements, accepting that the codes are rented for as long as the data matters. Even then, know that the print run is only as permanent as the invoice.

Sharen generates static codes, on your device, encoding exactly what you type. That is a deliberate limit, not a missing feature: it is the only way to promise the code will still work when nothing is left to renew.

Questions people ask before printing