Static vs Dynamic QR Codes: Expiry, Tracking and When Each Makes Sense

A static QR code contains your actual content, such as the full web address, the Wi-Fi password or the text, written directly into its pattern of squares. It works for as long as that content is valid and nobody can switch it off. A dynamic QR code contains only a short link to a redirect service run by whoever made it. That service forwards each scan to your real destination, which lets it count scans and change the destination later, but also means the code stops working the day the service stops forwarding.

Neither is better in general. The right choice depends on whether you need to edit or measure the code after printing, and on how much you trust the company in the middle.

How each type works, scan by scan

Static

1. The camera decodes the pattern and gets, for example, https://example.com/menu.
2. The phone offers to open that address.
3. The browser goes straight to your site. Nobody else is involved.

Dynamic

1. The camera decodes something like https://qr-provider.example/x7Kp2.
2. The phone opens the provider's server, which logs the request: time, IP address (and so an approximate location), and the device and browser type.
3. The server looks up where x7Kp2 currently points and sends the phone on to your page.

The extra step is invisible when it works. It becomes very visible when it does not, because a printed code can only ever point at that one short link.

Why "free" dynamic codes expire

Running a redirect server costs money, so providers that hand out dynamic codes need a way to be paid. The common patterns are a free trial after which the redirect is paused until you subscribe, a scan cap per month, or a code that keeps working only while an account stays on a paid plan. Some redirect lapsed codes to an advertising or sign-up page instead of showing an error, which is worse: the people scanning your flyer land on someone else's sales page.

Because the code on paper cannot change, the provider has leverage. Once a few thousand menus, labels or business cards have been printed, paying to keep them alive is usually cheaper than reprinting. Read the plan terms before you print a dynamic code, and look for what happens on cancellation, not just what the trial includes.

Static codes have no such dependency. The code generator that drew the pattern plays no part when someone scans it, so it does not matter if that site changes its pricing or closes. As long as your own website, Wi-Fi network or phone number still exists, the code works.

The tracking question

Scan statistics are the main selling point of dynamic codes, and they are genuinely useful for comparing, say, two poster locations. But the data is collected by the provider, on its servers, about your customers. Each scan reveals a visitor's IP address and device details to a company they have never heard of, and the provider's privacy policy, not yours, decides what happens to it.

You can get most of the same insight with a static code and your own site's analytics. Add a campaign parameter to the address before generating the code, for example https://example.com/menu?source=table-card, and your analytics will show how many visits came from that card. Use a different value for each placement. The visit goes straight from the scanner's phone to your website, with nobody in between.

Side-by-side comparison

When a dynamic code makes sense

• Large print runs whose destination may change, such as packaging that will be on shelves for years while product pages move.
• Campaigns where scan counts are the deliverable and the team is comfortable with a third party holding that data.
• Very long destination addresses that would make a static code too dense to print small; the short redirect link keeps the pattern simple.

Even then, prefer a provider that lets you use your own domain for the short link, or one that lets you export your codes and destinations. Either way you keep an exit if prices change.

The middle path: a static code that points at your own link

If you have a website, you can get editability without a middleman. Create an address you control, for example example.com/go/spring, and set it up to redirect to wherever you want today. Put that address in a static QR code. Later you can change the redirect on your own site and every printed code follows, your own analytics count the visits, and nothing expires unless you let your domain lapse.

The same idea keeps codes small: a short path on your own domain encodes into far fewer modules than a long address with several parameters. Our guide to QR code print size shows how much content length changes the pattern.

Content that only works as a static code

Several QR code types are read directly by the phone's operating system rather than opened as a web page. A Wi-Fi code carries a string such as WIFI:T:WPA;S:NetworkName;P:password;; and the phone offers to join the network. A contact card code carries the vCard text and the phone offers to save the contact. Codes for phone numbers, text messages and email addresses work the same way. A dynamic code can only hold a link, so for these types it has to send people to a web page that then offers a download or instructions. That adds a step, needs a data connection, and in the Wi-Fi case defeats the point, since the guest is scanning because they are not yet online.

Before you print either kind

1. Scan the final file with at least two different phones, including an older one.
2. Open the destination on mobile data, not just office Wi-Fi, to make sure it is public.
3. For dynamic codes, write down the provider, the account owner and the renewal date somewhere your team will find it.
4. For codes in public places, check them now and then: stickers with a different code pasted on top are a known way to send people to fake payment or login pages.
5. Print a short human-readable address next to the code, so people who cannot scan still have a way in.