Change a QR code's destination without reprinting

A printed QR code is permanent. The page behind it does not have to be. That gap, the fixed thing on paper and the flexible thing online, is the most useful trick a dynamic QR code has. Knowing exactly when and how to use it is what turns a one-shot print run into an asset you reuse for years.

The one-minute version

A dynamic code does not carry your landing page address. It carries a short link to a redirect you own (a /r/ URL in ScanKit), and the redirect decides where each scan goes. Change the destination in your dashboard and the next scan of a code you printed months ago lands on the new page. The square of dots never changes. What it means changes in seconds. Only dynamic codes work this way: a static code has the destination baked into the pattern, so it can never be edited. That distinction is covered in full in dynamic versus static QR codes.

How to change it, step by step

The actual edit takes well under a minute.

1. Open your QR dashboard and find the code. This is where naming pays off: spring-flyer-instore is easy to find, "Code 47" is not.
2. Edit the destination URL. Paste the new address. If you track campaigns in Google Analytics, carry your UTM parameters over to the new URL too, since they live in the destination, not in the code.
3. Save. The change is live immediately on the provider's side, and every future scan now resolves to the new page.
4. Test it on a fresh device. Scan with a phone that has not scanned the code before, or in a different browser, to confirm the new destination. The next section explains why that detail matters.

How fast does the change take effect?

On the provider's side, instantly. The moment you save, the redirect record is updated and every new scan follows the new link. There is nothing to wait for.

The one wrinkle is browser caching, and it is worth understanding because it explains the only "it didn't work" you are likely to hit. A well-built dynamic code uses a temporary redirect (an HTTP 302), precisely so browsers do not cache the destination. A permanent redirect (a 301) gets hard-cached: a phone that already followed it once may keep going to the old page from memory, and you cannot clear someone else's cache. Good providers use 302 for exactly this reason, so a repoint reaches returning scanners, not just new ones. ScanKit's /r/ redirect is built this way.

The practical upshot: the change is instant for new scanners. If you scan from the same phone you tested the old destination on and still land on the old page, that is your browser's cache, not the code. Scan from a different device and you will see the change. This is also why the camera app itself is never the problem: phone scanners read the code fresh every time and hand the URL to the browser, so they never remember an old destination.

When you will actually reach for it

The uses fall into a few clear buckets, and most campaigns hit several over a code's life.

The page moved or died

Landing pages get retired, rebuilt, and replaced. On a static code that orphans every printed piece. On a dynamic one you point the code at the new URL and the print carries on like nothing happened.

The offer changed

The everyday case, and the one clients feel most. A code on a restaurant table runs the summer menu, then the autumn menu, then a holiday booking page, all off one sticker. A code in a shop window runs this month's promo, then next month's. A yard sign outside a house links to the live listing, then flips to "sold, see similar" the day it goes under contract. A code on packaging starts as a how-to video and later becomes a reorder link. The print stays put; the content behind it follows the campaign.

You want to test something

Since you own the target, you can change it on purpose to see what works. Run one destination for a fortnight, switch, and compare the scan response. The printed code becomes a small reusable test surface instead of a one-shot bet.

Something went wrong

A typo in a URL. A page that 404s. A link pointing somewhere it really should not. On a static code those are reprint-and-reissue emergencies. On a dynamic one it is a thirty-second fix, and every code already out in the world corrects itself at once.

What doesn't change

Worth being clear about what stays put when you repoint. The printed code never needs reprinting, because the pattern is tied to the short link, not the destination. The short link keeps resolving, so anything already printed or shared still works. And repointing does not wipe your analytics: a good provider keeps the code's full scan history across destination changes, so you see the before and after on one continuous timeline.

Repoint on purpose, not on a whim

The power to repoint is also a responsibility. A scan is a small act of trust: someone expected the code to deliver whatever its surroundings promised. A few habits keep that trust intact:

• Keep the new destination true to the printed promise. Sending a menu code to the current menu is good service. Sending it somewhere unrelated, or swapping it constantly to bait people, just teaches them to stop scanning.
• Make sure the new page exists and works before you switch. Repointing to a broken or half-built page is worse than leaving the old one up.
• Keep the destination mobile-friendly and fast. Every scan is on a phone, in the moment.
• Repoint, do not delete. Deleting a distributed code breaks every copy already printed; repointing fixes them all at once.

Frequently asked questions

Can you change a QR code after it is printed?

Yes, if it is a dynamic code. The printed pattern points at a redirect you control, so you change where it goes from your dashboard and the printed code stays exactly as it is.

Can you change the destination of a static QR code?

No. A static code has the destination encoded directly in the pattern, so the only way to change it is to generate and print a new code. This is the main reason to choose dynamic for anything that goes to print.

Does changing the destination reset the scan statistics?

No, with a good provider. The scan history belongs to the code, not the destination, so it carries across changes and you keep one continuous record.

How long does a destination change take to go live?

It is live the instant you save, and new scans follow the new link immediately. The only delay you might see is on a device that already scanned the old destination, where the browser's cache can hold the old page. Scan from another device to confirm.

How many times can you change a dynamic code's destination?

As often as you like. A single printed code can run a dozen campaigns over its life, one destination at a time.

The short version

That is the real value of a dynamic code: it splits what you print from what you can change. Fix mistakes, rotate offers, test pages, ride out a moved URL, all without reprinting a thing and without losing the scan history that ties it together. Print once, redirect as often as the campaign needs, and keep it honest.