Static vs dynamic QR codes, what is actually different and which to pick

What each type actually does

Both static and dynamic codes use the same ISO/IEC 18004 symbology. The difference is the byte payload printed inside the symbol.

Static QR code

The destination is encoded literally. A QR code for https://example.com/product/abc-123 contains exactly that string. The scanner decodes it, hands the URL to the OS, and the browser opens it. No third party sits between the scan and the destination. Once printed, the destination cannot change.

Dynamic QR code

The encoded payload is a short URL on a redirect service, e.g. https://qr.example/abc. The scanner hands that URL to the OS, the browser hits the service, the service returns an HTTP 301 or 302 to the real destination, and the browser follows. The printed symbol stays the same; the redirect target can be edited in the service's dashboard.

What dynamic codes actually buy you

Three things, in priority order.

Editability after print

The marquee feature. A poster printed last quarter can be repointed to a new landing page next week without reprinting. For seasonal campaigns, vehicle wraps and packaging that ships before the campaign URL exists, this is the one feature that justifies the subscription.

Scan analytics

Dynamic services log each scan: timestamp, often city-level location from IP, sometimes device family. This is useful for measuring which placements work (a sticker at the cafe versus a flyer at the campus) and for funnel attribution. The data is no more granular than a normal short-link click tracker; do not expect per-user identity.

Short, dense symbols

A short redirect URL fits in a low QR version with small module count, so the printed symbol can be smaller without sacrificing the minimum print size. If your real destination is a 200-character URL with UTM parameters, a static QR will be visibly denser than a dynamic one carrying a 20-character redirect.

What dynamic codes cost you

Vendor dependency and link rot

A dynamic QR only works while the redirect service keeps the record alive. If the vendor shuts down, raises prices past your budget, deletes inactive records, or simply changes its short-link domain, every printed code stops resolving. Industry-wide, this pattern is known as link rot, and short-link services in particular have a long history of being shut down or sold. A poster with a static URL has none of this risk.

Privacy and consent

A static QR sends nothing to a third party; the scanner goes straight to the destination. A dynamic QR routes every scan through the redirect service, which logs at least the IP, user agent and timestamp. In jurisdictions covered by the GDPR or comparable laws (UK GDPR, India's DPDP Act), that logging is a controller/processor relationship you need to disclose. Many tools default to handing scan logs to ad networks; review the vendor's data policy before deploying at scale.

Cost over time

Static QR codes are free in perpetuity. Dynamic codes are usually a subscription per code per month, or a flat tier with a code quota. For a single campaign with three codes, the cost is trivial. For thousands of codes on packaging, the bill compounds, and a contract change can lock you in for years.

Failure modes scanners cannot recover from

A static QR can still decode if a smudge eats one module; the error correction level bails it out. A dynamic QR can decode perfectly, get a clean HTTP 301 from the service, and still fail because the service returns a 404, a 503, or a captive redirect to an unrelated page. Code-level redundancy does not help here; service availability does.

When to pick static

• The destination URL is short and unlikely to change (a homepage, a Play Store listing, a fixed UPI ID).
• The payload is not a URL at all: Wi-Fi credentials, a vCard, an SMS or tel link, an event ICS, a geo URI.
• You need to ship the code without depending on a third-party uptime or pricing decision.
• You care about not routing every scan through an external analytics service.
• You are printing on packaging or signage with a multi-year life and no plan to repoint mid-life.

Almost every non-URL payload type is naturally static. A Wi-Fi QR carries the SSID and password directly; a vCard QR carries contact fields; a UPI QR carries the payment URI. Wrapping any of these in a redirect adds risk for no real benefit, since you can re-print the sticker if you change Wi-Fi password or contact details.

When to pick dynamic

• Print or production runs that ship before the campaign URL is finalised (packaging, event swag, vehicle wraps).
• Multi-stage campaigns where the same printed code points at different pages over time (pre-launch, launch, post-launch).
• Codes where scan analytics genuinely drive a decision (A/B placements, multi-location attribution).
• Very long destination URLs you cannot shorten, where the minimum print size forces the symbol into a high QR version.
• Programmatic campaigns where the same template generates thousands of unique codes pointing at per-asset landing pages.

Even in dynamic-friendly cases, pick a vendor with a clear data-portability and shutdown policy, and budget for the recurring fee for the lifetime of the printed material. A QR code on a billboard that runs for two years is a two-year subscription, not a one-off cost.

Attribution and tracking, demystified

You do not need a dynamic QR service to track scans. A static QR pointing at a URL with UTM parameters shows up in your existing analytics platform exactly the same way a normal click does. The only thing UTM cannot tell you is the scan event itself before the user opens the destination; if the user scans and never lands, the static path sees nothing while the dynamic service still logs the scan.

For most marketing use cases, UTM-tagged static codes plus your own analytics give you 80% of the insight at 0% of the recurring cost. The 20% gap (scan-but-no-land, scan timing, vendor-supplied geo) is what you pay a dynamic service for.

Choosing in practice

1. Write down the destination as a URL or a non-URL payload type. If non-URL, default to static.
2. Ask: will this destination change after the symbol is printed? If no, default to static.
3. Ask: do I need scan counts that survive past UTM-level attribution? If no, default to static.
4. If you answered yes to either, evaluate two or three dynamic vendors on uptime, data policy, redirect domain, and exit cost (what happens to your codes if you cancel).
5. Either way, generate the QR at a print-suitable size with a vector export, and field-test scans before printing the run.