Change a QR Code's Destination Without a Dynamic QR Subscription

People who go looking for a dynamic QR code almost always want one specific thing: the ability to change where a printed code points after it has been printed. That is worth paying for in some situations and completely free in others, and the difference is worth understanding before a subscription starts.

What does a dynamic QR code actually do?

It encodes a short link on the provider's domain and redirects that link to wherever you tell it to. That is the entire mechanism. When somebody scans the code, their phone opens https://provider.example/aB3xK9, the provider's server looks up your current destination, sends back a redirect, and the phone follows it. Change the destination in the dashboard and the next scan follows the new one, because the printed pattern never held your destination in the first place — it held the provider's short link.

So a dynamic QR code is not a different kind of QR code. The pattern is an ordinary static QR code. What makes it "dynamic" is that the address inside it belongs to somebody who will redirect it for you, for as long as you keep paying them.

That also explains the failure everybody has heard about. When the subscription lapses or the provider shuts the service down, the pattern is intact, the printing is fine, and the scan goes nowhere.

Can I run that redirect myself?

Yes, if you have a domain. Point a static QR code at a short address on a domain you control, and redirect from there to wherever the code should go today. You get the part people actually want — an editable destination behind a printed code — and the dependency moves from a company you do not control to a domain you already pay for.

The printed code encodes something like https://yoursite.com/go/menu. That address never changes. What it redirects to is yours to edit whenever you like.

How do I set up my own redirect?

Pick a short path on a domain you own, configure a redirect at it, and encode that address into the code instead of the destination. Only the middle step varies by host.

1. Pick a short, stable path on a domain you own: /go/menu, /r/spring, /qr/table-4. Keep it short, because every character is encoded into the pattern and a shorter address makes a sparser, easier-to-scan code. Pick a path you will not want to reuse for something else later.
2. Configure the redirect. Where depends on how the site is hosted:
   • Netlify: a line in the _redirects file at the root of your published site.
   • Vercel: a redirects entry in vercel.json. This site's own apex-to-www redirect is configured exactly that way.
   • Cloudflare: Redirect Rules, or Bulk Redirects if you have a lot of them, which accepts a CSV of source and target addresses.
   • Apache or nginx: a Redirect line in .htaccess, or a return in the server block.
   • A hosted CMS: most have a redirects feature or a plugin for one. Look for "redirects", "URL redirects" or "link management" in the admin.
3. Encode the short address, not the destination. Generate the code from https://yoursite.com/go/menu. Scan it yourself and confirm it lands where you expect before any of it goes to a printer.

Should the redirect be a 301 or a 302?

A 302. This is the one place where the usual advice is exactly wrong for this job.

Most guides tell you to use 301, because a permanent redirect passes ranking signals and is what search engines want for a page that has genuinely moved. But browsers are allowed to cache a 301 with no expiry, and several do. The first time somebody's phone follows your 301 it may remember it indefinitely and never ask your server again. Change the destination next month and that person still lands on the old one, because the redirect now lives in their browser where you cannot reach it.

A 302 says "temporarily somewhere else, keep asking me", which is precisely the contract you want from a link whose whole purpose is to change. Use 302 for a QR redirect you intend to edit. Save 301 for a page that has genuinely and permanently moved.

If your platform offers a "permanent redirect" toggle, that is a 301 (or a 308) and you want it switched off.

Will I still get scan counts?

Yes, with one caveat. Every scan becomes a request to your own server, so your existing analytics counts them like any other page view — but it cannot tell a scan apart from somebody tapping the same link in a message.

Every scan becomes a request to your own server for /go/menu, so your server logs and your analytics see it: how many, when, roughly where from, and what kind of device. For most people asking "did the poster work", that is the question answered.

What you do not get is a dashboard built for this, and you cannot tell a scan apart from a click. If somebody shares the short link in a message and a hundred people tap it, those hundred look identical to a hundred scans. A dedicated provider has the same problem in principle and papers over it with heuristics; the difference is that they tell you a number and you would have to look.

What does a paid provider give me that this does not?

A dashboard, bulk management, and the option of not owning a domain at all. Those are real things and worth paying for if you need them:

• A dashboard per code, with scan counts over time, device breakdown and rough location, without you touching analytics tooling.
• Bulk management: hundreds of codes, each editable individually, without hundreds of redirect rules to maintain by hand.
• No infrastructure. If you do not own a domain, do not want to, or cannot edit hosting configuration, a provider is not a luxury. It is the only option.
• Features beyond redirecting, such as scheduling a destination change, routing by device or country, or pausing a code.

If you need any of those, pay for them. The point of this article is not that dynamic QR providers are a con — it is that a lot of people pay one for a redirect they could run in three lines of configuration, and they should know that before they decide.

What breaks a self-hosted redirect?

Losing the domain. If it lapses or you move off it, every printed code that points at it dies at once, exactly the way a lapsed subscription kills a provider's codes. The dependency does not disappear; it moves somewhere you control and already maintain.

Two smaller things worth guarding against. Do not reuse a redirect path for a different campaign later, because the old printed codes are still out there pointing at it. And keep the redirect rules in version control with the rest of the site, so a redeploy cannot quietly drop them.

When should the code not be a redirect at all?

When the destination will never change, a redirect only adds something that can break. A business card, a WiFi network sign, a warranty label, a plaque — encode the real thing directly and there is no server in the path at all. That is the case for a plain static code, and it is covered in do QR codes expire and QR codes that never expire.

A redirect earns its place when the destination is genuinely expected to move, and only then.

Does Quick QR Maker make dynamic QR codes?

No. This site generates static codes in your browser, with nothing calling home and no account. That is a deliberate choice rather than a missing feature, which is why this guide tells you to run the redirect yourself rather than to sign up for something here.

If you want an editable destination, set up the redirect first and then generate a static code pointing at your own short address. The code this site makes you will keep working for as long as your domain does, which is the same guarantee as the rest of your website.