Static vs dynamic QR codes — when to use which

You can split every QR code in the world into two camps. One encodes its destination directly into the black-and-white grid — print it, photograph it, decode it, you get the URL. The other encodes a short link that redirects somewhere else; the QR code itself never changes, but where it points to can.

Both look identical. Neither is "better." The choice hides a real trade-off that matters more after the print job ships than before.

This post covers how each one actually works, why dynamic isn't always the right answer, and the four questions to ask before you generate either kind.

What a static QR code is#

A static QR code encodes its data directly. The black and white modules in the grid spell out the destination — typically a URL, but it can also be a vCard, a WiFi network, an email address, or arbitrary text. When a phone decodes it, the URL comes out the other side. There's no server in the loop.

That makes static QR codes:

• Free, forever. No account, no recurring cost. Generate once, print, done.
• Permanent. The destination is baked into the print. To change it, you reprint everything.
• Untraceable. The decoder goes straight to the destination — there's no middle hop where you could log "someone scanned this code at 14:32."
• Heavier visually. A long URL means more modules, which means a denser code. Print a static QR code for a 90-character UTM-decorated URL and you'll get a small, hard-to-scan grid.

Static codes are what most "free QR generator" sites give you by default. They're perfect for things that genuinely never change: your home WiFi password, a vCard with your phone number, a "scan to email me" code on a sign at your studio.

What a dynamic QR code is#

A dynamic QR code encodes a short link. Something like lnks.work/k/menu — that's the QR's actual payload. When you scan it, the phone visits the short link, the platform looks up where it should go, and 302-redirects you there.

The key word is redirect. The QR code itself is fixed (you printed it last Tuesday), but the destination it points to lives on a server, and that server can be told to send people somewhere different tomorrow. A restaurant menu QR code printed on 200 takeaway flyers can be retargeted from "summer menu" to "winter menu" in a single dashboard click.

That makes dynamic QR codes:

• Editable after print. Change where the code points without changing the print.
• Trackable. Every scan generates a hit on the redirect — timestamp, country, device type, referrer. You can answer "did the campaign work?"
• Smaller and prettier. A short link is short. Encoding lnks.work/k/menu produces a sparse, low-density code that's easy to round, brand, and print at small sizes.
• Dependent on the redirect host. If the platform serving the short link goes away, every QR code that points to it breaks. Pick a host that's worth depending on.

Dynamic codes are what most marketing-grade QR codes are. The whole point is being able to change the answer to "where does this go" after you've already shipped the print run.

The size difference, visualised#

Encode a 90-character URL with UTM parameters and you get the left grid. Encode lnks.work/k/menu and you get the right one. The right one rounds beautifully, prints sharply at 1cm, and survives compression for screen displays. The left one tries.

This is the practical reason dynamic QR codes are the default for almost any marketing surface — even setting aside tracking and editability, the short link gives you a dramatically less ugly code.

When static actually wins#

Three cases where static is the right call:

1. The destination really never changes#

A vCard QR code on the back of your business card encodes your contact details directly. There's no destination to repoint — the vCard is the data. Same with WiFi codes. Same with a "scan to send me an email" code. Static is correct here because there's no value in routing through a server you'd have to maintain.

2. Long-life print on cheap surfaces#

A QR code stamped onto a stainless steel plaque outside a building for the next 20 years should not depend on a SaaS that might be gone in three. Burn the URL into the print and accept that you can't change it.

3. Privacy-sensitive contexts#

Static codes have no scan log. There's no server that knows someone photographed the code. For some uses (medical info, instructions in a private space, codes printed inside a product manual) the simplicity is the feature.

For everything else — flyers, posters, packaging, restaurant tables, business cards that link to a website rather than a vCard, anywhere you might want to know if it worked — dynamic is the choice.

The hidden cost of dynamic#

The thing the comparison rarely mentions: dynamic QR codes only work for as long as the redirect host stays up. If the platform you used to generate the code shuts down or sells to someone who turns the redirect off, every print of that code becomes garbage paper.

This is why the cheap-or-free dynamic-QR services that pop up every quarter are a bad bet for anything you've printed thousands of. You're not paying for QR generation — that's free. You're paying for "this URL still resolves five years from now."

Three things to look at when picking a dynamic QR host:

• Who runs it? Established platforms with a paying customer base survive longer than free freemium plays.
• What domain does the short link live on? A code pointing at lnks.work/k/menu is robust as long as lnks.work resolves. A code pointing at qr.somecompanyname.io survives only as long as somecompanyname.io does.
• Can you point it at your own domain later? The escape hatch matters. If you've printed a million codes pointing at someservice.com/abc and you want to migrate, you need either DNS-level redirect support on the destination, or a way to point the codes at your domain in the first place.

Linked.Codes lets you put dynamic codes behind your own domain so the print stays valid even if you switch platforms — re-route the domain at DNS, the codes carry on. It's the kind of detail that doesn't matter until it does.

Decision matrix#

The pattern: anything that's a marketing or content surface = dynamic. Anything that's a fact about the world that won't change = static. Anything in between, default to dynamic — the "I'd like to repoint this" desire shows up more often than people expect.

How to migrate from static to dynamic#

If you've already printed a static QR code with a URL on it and you want to start tracking or editing it, you can't change the print. But you can change what's at the URL.

The trick: replace the page at the original URL with a redirect. That redirect can now go anywhere you want — and you can change it as often as you like. You've turned a static QR code into a pseudo-dynamic one, at the cost of one DNS-level or server-level redirect rule.

Two caveats. First, you've lost the size advantage — the printed code still encodes the long original URL. Second, you can only do this if you control the destination URL. If your static code points at someoneelses.com/..., you don't have this option.

For codes you haven't printed yet, generate them as dynamic from the start. The 30 seconds it takes to set up a short link is worth it for every code you might want to repoint or measure later.

Static QR codes encode the answer; dynamic QR codes encode the question.

The shorthand that helps#

A useful frame: static QR codes encode the answer; dynamic QR codes encode the question. "What URL does this point to?" is a question with an answer that lives on a server and can change. "What's the WiFi password for this house?" is an answer that's permanent, and the QR code is just a faster way to read it.

If your QR code is encoding a fact about the world — your phone number, a network name, an email address, an instruction — go static. If it's pointing at content you control and might want to update, measure, or replace, go dynamic. That covers 95% of cases without needing to think harder than that.