Anyone who has printed QR codes on 500 flyers and watched them die a month later has met the difference between static and dynamic codes — usually the expensive way. The distinction isn’t about the pattern; both are ordinary QR symbols built to the same ISO/IEC 18004 spec. It’s about what the pattern contains.

What a static QR code is

A static code encodes the payload directly. If the content is https://your-site.example/menu, those exact characters — and nothing else — are woven into the modules. Point a scanner at it and it hands the scanner that string, end of story.

Consequences, all good:

• It cannot expire. There is no server in the loop to shut down, no account to lapse, no trial to end. Paper permitting, it works in twenty years.
• It works offline. A Wi-Fi credential or contact card resolves without either device touching a network.
• It is private. Nobody sits between the scan and the destination logging who scanned, when, and from where.
• The content is auditable. Decode the image and you see literally what was embedded — you can do that on this site’s scanner page in seconds.

The one real limitation: the destination is frozen at print time. A static code pointing at a URL that later moves will faithfully send people to the moved-from address. (For that failure mode the honest fix is keeping the URL stable or redirecting the old one on your own domain.)

What a dynamic QR code is

A “dynamic” code does not contain your link. It contains the generator company’s link — something like https://scan.example.com/abc123 — which redirects onward to your real destination. The selling point is that the redirect target can be edited later and every hop can be logged for analytics.

The catch is structural: the printed code is now a pointer to someone else’s server. If the vendor raises prices, sunsets the free tier, gets acquired or goes offline, the redirect dies — and the code on your menu becomes a decoration. This is the mechanism behind the widespread complaint “my free QR codes stopped working”: the codes were never really yours, they were the vendor’s, leased until you stopped paying.

Some vendors also treat the redirect as a data business: because every scan passes through their domain, they can aggregate when, where and on what device each scan happened. For a restaurant menu that may be harmless; for anything else, it’s worth knowing the surveillance is built into the product’s architecture, not an accident.

Side by side

	Static (this site)	Dynamic (redirect services)
Payload	Your content, embedded	Vendor URL that redirects
Expires?	Never — no server involved	When the vendor’s account/plan ends
Editable destination	No — the print is the data	Yes, via the vendor’s dashboard
Scan analytics	None by design	Built-in (that’s the point)
Works offline	Yes, for non-URL types	No — every scan needs the redirect
Privacy	Scan goes straight to the destination	Vendor sees every scan’s metadata
Lock-in	None	Total — printed stock dies with the service

When dynamic is actually the right choice

To be fair, the redirect layer does buy two things static can’t offer: retargetable destinations (reprint nothing when the menu PDF moves — though a stable URL on your own domain achieves the same) and scan counting (marketing teams genuinely need “how many people scanned the poster” numbers). If you need those, use a dynamic service knowingly — and prefer pointing the redirect at infrastructure you control, like a go.yourdomain short path you host yourself, which gives the same editability without the landlord.

How to tell which kind you’re holding

Scan it and read the payload before opening it. A static code reveals its true content immediately — https://restaurant.example/menu, WIFI:T:WPA;S:…, BEGIN:VCARD. A dynamic code reveals a short opaque URL on the vendor’s domain, sometimes with tracking parameters. The built-in scanner here shows the literal string so you can check in one drop — a code that hides its own destination is telling you something about who owns it.

If you discover the codes you already printed are dynamic and the subscription is ending, the migration path is simple: decode each code once to capture the redirect URL, confirm where it currently lands, then generate a static code with that real destination and reprint. Painful once; permanent after.

Every code made on this site is static — the pattern is the payload, generated in your browser with no redirect and nothing stored. Make one →

Sources: the ISO/IEC 18004 spec summary, error-correction levels and format details are documented on the sources page, which links the primary references.