Static vs dynamic QR codes, and which one you actually need

A restaurant prints four thousand menus with a QR code pointing at example.com/menu-autumn-2026. In January the page is replaced and every one of those codes is a 404. This is the situation dynamic codes are sold to solve, and it is worth understanding what you are actually buying.

The difference is ownership, not technology

Both are ordinary QR codes. The symbol, the modules, the error correction, the standard — identical. What differs is what the code contains:

• A static code contains your destination as literal text. Scan it offline and you can read the URL out of it. Nothing has to keep running for it to work.
• A dynamic code contains a short link on somebody else’s domain, like qr-vendor.example/x7Kq2. Their server receives the scan, logs it, and issues an HTTP redirect to wherever you have currently pointed that link.

The generator on this site makes static codes only. There is no shortener and no redirect in the middle, which is why nothing here expires.

The honest comparison

What dynamic genuinely buys

Two things, and they are real.

An editable destination. Print now, decide later; retire a landing page without retiring the print run; point a seasonal campaign somewhere new. For anything printed at scale on a long-lived surface — packaging, signage, equipment labels, vehicle livery — this is worth money.

Per-scan analytics without touching your website. Scan counts, timestamps, approximate location and device type, broken out per code, with no tagging discipline required from whoever made the artwork. If you are running two hundred codes across a retail estate, a dashboard that already knows which code is which is a genuine operational saving.

What dynamic costs

Rent, forever. The redirect must keep resolving for as long as the printed material exists, which for packaging and signage is often years past the point where anyone remembers the subscription. Miss a renewal and the codes stop.

A third party in the middle of every scan. Every person who scans your code makes a request to a company you have a commercial relationship with and they do not. That company logs the scan, and its retention and sharing policy is now part of your privacy posture.

Vendor mortality. URL shorteners have a poor survival record — Google retired its own and the links stopped resolving. A QR vendor that folds, pivots or is acquired takes your print run with it.

A reputation dependency. Shortener domains get blocklisted by corporate security filters and flagged by phishing heuristics, because attackers use them too. Your code inherits whatever reputation that domain accumulates, and users who have learned to distrust shortened links in QR codes are, as QR code scams and how to check a code explains, being sensible.

The one technical advantage worth naming

Short URLs make smaller codes, and this is not a small effect. A dynamic shortener link of about 21 characters encodes as a version 2 symbol — 25 modules per side at level M. A long destination with four UTM parameters, say 110 characters, needs version 7: 45 modules per side, nearly double, for the same physical square.

At 25 mm printed that is 1.0 mm per module against 0.56 mm, which is the difference between scanning across a room and scanning at arm’s length in good light. The print size guide has the module-size floors this runs into.

The important part: this advantage comes from the shortness of the URL, not from the code being dynamic. You can have it without renting it.

The middle path: a static code pointing at your own redirect

Encode yourdomain.com/m — a short path on a domain you already own — and put a redirect behind it. You get:

• Editability. Change the redirect target and every printed code follows.
• Short URL, low module count. All the size advantage above.
• No subscription and no third party. The hop is your own server.
• Full analytics. The redirect is a request in your own access logs, with timestamp, referrer, user agent and any parameters you attach.
• A destination people trust. The domain in the URL preview is yours, which is exactly what a cautious scanner is looking for.

Practically, this is one line in a Netlify _redirects file, a Cloudflare rule, an nginx location block or a WordPress redirect plugin. Two details matter:

1. Use a 302, not a 301. A 301 is a permanent redirect and browsers cache it aggressively, so people who scanned the code once may keep landing on the old destination after you change it. A 302 keeps it editable.
2. Keep the path genuinely short. /m, /menu, /p1 — not /campaigns/2026/autumn/menu-redirect. The whole point was module count.

Reserve one path per physical placement — /m1 for the table tents, /m2 for the window, /m3 for the flyers — and you get per-placement analytics too, which was the other thing dynamic was selling you.

Attribution on a static code, for free

If you would rather not run a redirect, tag the destination URL with UTM parameters before you generate the code. utm_medium=qr with a utm_source naming the physical placement lets your existing analytics separate scans from a poster and scans from a menu, in the reports you already read. The tagged URL is what gets encoded, so this has to happen before the artwork is made — the UTM tracking guide covers the conventions and the mistakes.

The cost is module count: four UTM parameters can add a version or two. If size is tight, the redirect approach is better, because you can attach the UTM tags on the server side at redirect time and keep the encoded URL to a dozen characters.

Choosing

• Screen, email, slide, one-off, internal — static, plain URL. Nothing else is justified.
• Print, and you own a domain — static code pointing at a short redirect on your own domain. This is the right answer for most businesses.
• Print, no technical resource, hundreds of codes to manage — a dynamic vendor is a reasonable purchase, provided you accept the dependency and set a calendar reminder for the renewal.
• Anything that must work in ten years without maintenance — static, literal URL, on a domain you intend to keep.

The generator encodes whatever you paste, with a UTM builder next to the input, and the image API does the same from a URL if you want codes generated inside your own pages. Whichever route you take, the destination should be an address you control — that single decision is what makes a printed code repairable later.