QR codes that don't expire: static vs dynamic, and who owns the redirect

A QR code on a screen is disposable. A QR code on a menu, a poster, a business card, a product label or an equipment tag is infrastructure. You're committing to a link staying alive for as long as the printed thing exists.

Which makes the static-versus-dynamic choice the only decision that really matters, and it's the one most generators are least honest about.

What a QR code physically contains

A string. That's it. There's no server, no lookup, no account, the black squares are the data, encoded with error correction. Nothing about the code itself can expire.

So when a QR code "expires," something else expired: the URL it contains, or the redirect service sitting behind that URL.

Static: the code holds your actual URL

Scan it and the phone goes straight to yoursite.com/menu.

Good: it works forever, with no account, no subscription and no third party. Nobody can turn it off. Nobody can retarget it. There's no company that has to still exist in 2031.

Bad: the destination is baked in. Change the URL and every printed copy is dead. And you get no scan analytics, because nothing is in the middle to count.

Dynamic: the code holds a vendor's short link

Scan it and the phone goes to qr-vendor.io/a9f, which looks up a destination and forwards.

Good: you can change where it points after printing, and you get scan counts, locations and times.

Bad, and stated plainly: you are now renting your printed material. Three things follow from that.

1. It can be switched off. Free tiers routinely become paid tiers. The common pattern is a generous free trial, then an email saying your codes stop resolving in 14 days. Anyone who printed 5,000 flyers now has a pricing problem, not a marketing problem.
2. The company has to survive. Your poster's lifespan is now capped by a startup's runway.
3. Whoever controls the account controls the destination. That's fine while it's you. It's less fine when it's an ex-agency, a former employee, or an acquirer.

None of this makes dynamic codes wrong. It makes them a dependency, and dependencies should be chosen deliberately.

The third option most people miss

Own the redirect yourself.

Put a short path on a domain you control, yoursite.com/r/menu, and have your own server forward it to wherever the destination currently is. Encode that short URL in a static code.

You get:

• Editability, because you can change the redirect target whenever you like
• Analytics, because the request passes through your own logs
• Permanence, because the only thing that has to survive is your domain

This is the correct answer for anything printed at volume, and it costs a redirect rule. It's also exactly how our QR generator handles dynamic codes, they resolve through this site's own /r/ endpoint, with deliberately coarse logging: a country and a device class, no IP stored, no cookie set, nothing that identifies a person.

Static codes from the same tool contain your URL directly and involve us not at all, which is what you want for most things.

Choosing, in one line each

• Screen, email, slide, temporary sign → static. It costs nothing and there's nothing to maintain.
• Print run you can reprint cheaply (a table tent, an A4 sign) → static.
• Print run you cannot reprint (packaging, engraved plaques, 10,000 flyers, equipment labels) → dynamic, through a redirect you own.
• You genuinely need per-campaign scan analytics → dynamic, and read the pricing page before you print.

Five things that make a printed code actually scan

Getting the strategy right doesn't help if the code doesn't read.

Keep the quiet zone. Four modules of clear space on every side. Designers crop this constantly and it's the most common reason a code fails on a busy layout.

Size it against the scan distance. The working rule of thumb is roughly 1:10, a code read from 1 metre away wants to be about 10 cm across. Under about 2 cm, phone cameras start to struggle regardless of distance.

Shorten the URL before you encode it. More characters means more modules means a denser, harder-to-scan code. yoursite.com/r/menu produces a visibly cleaner code than a 90-character URL with UTM parameters. Put the tracking in the redirect, not in the printed code.

Raise error correction if you're adding a logo. Level H tolerates about 30% damage, which is what makes a centre logo survivable. If you're not covering anything, a lower level keeps the code sparser and easier to read.

Don't invert it. Scanners expect dark modules on a light background. Light-on-dark works on some phones and fails on others, and you won't find out until it's printed.

Test the final artwork (the exported file, at final size) on at least an iPhone and an Android phone before it goes to print. That two-minute check has saved more reprints than any other item on this list.