Static vs dynamic QR codes: which one to print

The mechanical difference

A static QR code encodes the destination directly. The URL is the data in the pattern. Scanning it involves no server other than the destination itself.

A dynamic QR code encodes a short address owned by a QR platform. Scanning it asks that platform where to go, and the platform redirects.

Everything else follows from that one difference.

The density point is underrated

A long URL makes a denser, more fragile code. A tracking URL with UTM parameters can run past 120 characters and produce a pattern with so many small modules that it needs to be printed large to scan reliably.

A dynamic code's address is short by construction — ours is about 30 characters — so the pattern stays sparse and robust regardless of how long the real destination is. If you need to encode something long onto something small, dynamic wins on physics before any feature comparison.

The decision rule

Ask one question: will I ever want to change where this points?

If the honest answer is "no, never", use static. You get permanence for free.

If the answer is "probably", "maybe" or "I don't know", use dynamic — but choose the platform on what happens when you stop paying, not on its feature list.

Clearly static

• Wi-Fi credentials on a guest card — the network name and password are not a URL and cannot be tracked anyway.
• Contact details on a business card, as a vCard.
• Your own homepage, where you control redirects on your own domain.
• Anything engraved, etched, embroidered or cast — if the medium outlives any plausible subscription, do not make it depend on one.

Clearly dynamic

• Restaurant menus, which change seasonally.
• Campaign material where scan counts are the point.
• Product packaging already shipped, where the support page may move.
• Event signage that should point at a schedule before, and a feedback form after.
• Anything long that would otherwise produce a dense pattern.

The middle path most people miss

You can get most of the benefit of both by using a static code pointing at a URL on your own domain, and handling the redirect yourself.

yourdomain.com/menu is static as far as the code is concerned — it can never expire, and no third party can switch it off. But because you control the web server, you can change what /menu serves whenever you like. You get editability without the dependency.

What you do not get is per-scan analytics, unless you add your own. For a small business with a website, this is frequently the right answer and almost nobody suggests it, including most of our competitors, for reasons that are not hard to work out.

If you go dynamic, reduce the dependency

• Export static fallbacks if the platform offers them, and keep them with your print files.
• Keep your own record of every code address and destination.
• Prefer a platform whose terms — not marketing copy — say what happens when you stop paying.
• Check whether scan recording is capped, separately from whether redirects are.

We built our answer around exactly these four points, including the static-fallback export on the free plan.