How to Change a QR Code's Destination After Printing

You can change a QR code's destination after printing only if it is a dynamic code. A dynamic code stores a short link you control, so you edit the destination in your dashboard and every printed copy updates within seconds. A static code has the destination encoded in the pattern itself and cannot be changed — though there is one workaround below.

At a glance

Dynamic codes can be changed. Static codes cannot. That is the entire answer.
Changing a dynamic destination takes seconds and updates every printed copy at once — posters, packaging, business cards, everything already in the wild.
If your static code points at a URL you own, you can still rescue it with a server redirect. Details below.
If it points at a URL you do not control, the only fix is a reprint.
Check what kind of redirect your provider uses. A 301 is cached by default and can leave earlier scanners stuck on the old destination. A 302 is not cached by default, which is what you want.

First, work out which type you have

You do not need any tools. Scan the code with your phone's camera and look at the URL it offers before you tap it.

Shows your actual destination, like yourcompany.com/menu.pdf → almost certainly static
Shows a short link, like pxqr.io/a1b2c → something is redirecting, but that alone does not prove the code is dynamic

Two cases break the quick version of this test. A static code can have a shortener baked into the pattern permanently, and a dynamic code can sit on a custom domain that looks like yours. The reliable test is control, not the URL: can you change where it leads without reprinting it? If yes, it is dynamic. See Static vs Dynamic QR Codes for the full explanation.

If it is dynamic, find out whose account owns it. Whoever controls that account controls where your printed codes lead. If an agency or a previous supplier generated it, get access transferred before you need it urgently.

Three steps: the code is already printed, you edit one field, every printed copy updates

How to change a dynamic QR code's destination

The pattern on paper never changes. You are only editing the record it points to.

Open the QR code in your dashboard.
Edit the destination URL field.
Save.

That is genuinely it. The short link stays identical, so every printed copy keeps working and simply starts leading somewhere new.

Editing a dynamic QR code's destination in the PixlQR dashboard

Test before you rely on it. Scan the physical code — not a copy on your screen — and confirm it lands where you expect. Screen scans can hide print quality problems that only show up on the real thing.

How long does the change take to apply?

Effectively immediately. There is no propagation delay like DNS, because nothing about the printed code changes and nothing has to reach a third party. The next person to scan gets the new destination.

Two caveats worth knowing:

Your provider may cache the lookup. Well-built services invalidate that cache the moment you save. If yours does not document this, test it yourself: change the destination, wait a minute, scan again.
The old page may still be open on someone's phone. Anyone mid-visit stays where they are. This only affects people who scanned before the change, not new scans.

The workaround that can rescue a static code

Most guides stop at "static codes cannot be changed." That is true of the code, but not always of the outcome.

If the static code points at a URL on a domain you control, you can redirect that URL. The code still resolves to the same address, but your server sends visitors onward.

Say you printed 5,000 menus encoding yourcompany.com/menu-spring.pdf. The spring menu is gone. You cannot change the pattern, but you can:

Keep the old URL alive — do not delete the page.
Add a server redirect from /menu-spring.pdf to the current menu.
Every printed code now works again.

You can set this up in your web server config, your CMS, or your host's redirect rules.

When this does not work:

The code points at a domain you do not own (a file host, a third-party page, a shortener that someone else controls)
The code encodes plain text, WiFi credentials, or a phone number rather than a URL — there is no server to redirect
You let the domain expire, in which case nothing can be recovered

This trick is genuinely useful, and it is also an argument for a habit: when printing a static code, always encode a URL on your own domain, even if it just redirects somewhere else. That single decision preserves your ability to change your mind later.

Why 301 versus 302 matters more than you think

This is technical but it decides whether "editable" actually works.

When a dynamic QR code forwards a visitor, the server sends an HTTP redirect. Two kinds matter here:

301 — permanent. Tells the browser this will never change. 301s are cacheable by default, and browsers cache them aggressively, sometimes for a very long time.
302 — temporary. Tells the browser this may change. 302s are not cacheable by default — a cache is only supposed to store one if the response explicitly says it may.

If a QR provider uses 301, anyone who scanned before your change can keep landing on the old destination, because their browser may never ask the server again. The code looks broken to exactly the people who engaged with it earliest, and fixing it for them means asking them to clear their browser cache — which no customer will do.

Two lanes comparing a 301 redirect, which the browser caches and never re-checks, with a 302 redirect, which the browser asks about every time

A dynamic QR code should therefore use 302. PixlQR does, and sends no headers that would permit caching of that redirect.

Being precise about the guarantee: 302 makes caching the exception rather than the default. It is not an absolute promise. A 302 can be cached when a response explicitly allows it, and intermediate proxies and corporate networks have historically not always behaved to spec. What 302 buys you is that a correctly behaving browser asks the server every time — which is the difference between a change that works and one that reaches only new visitors.

Two practical takeaways:

Ask any provider you evaluate which status code they use. It is a fair question and the answer is revealing.
Test it yourself after your first change. Scan the code on a phone that scanned the old destination before. If it lands on the new one, caching is not a problem for you in practice.

Mistakes that cost people a reprint

Printing a static code for anything seasonal. Menus, price lists, campaign landing pages. If it can change, it will.
Not checking who owns the account behind an agency-generated dynamic code.
Deleting the QR code record instead of editing it. Deleting usually breaks the short link permanently. Edit, never delete and recreate.
Changing the destination without testing the printed code. Scan the physical object.
Letting a dynamic subscription lapse before the printed run is retired. Check what your provider does to codes on an expired plan.

Frequently asked questions

Can I change a static QR code into a dynamic one? Not the printed one — the destination is in the pattern, so it would need reprinting. If there is any chance you will want to change it, start dynamic.

Will the QR code image itself change when I edit the destination? No. That is the entire point. The pattern stays identical; only the record behind the short link changes.

How many times can I change it? As many times as you like. Nothing about the printed code degrades with each edit.

Does changing the destination reset my scan analytics? It should not. Scans belong to the QR code, not the destination. If a provider resets your history when you edit, that is worth knowing before you commit to it.

Try it yourself

If your code is going on anything printed, being able to change it later is worth more than the subscription costs. You can create one free and edit it as often as you like.

Create an editable QR code — free plan, no card required.