Printing a QR code fixes the URL forever. It doesn't have to fix the content. The difference is entirely in what you point the code at — and it's the one decision to get right before the print run.
There's a specific flavour of dread that arrives about a week after a print run, when someone points out that the menu has the wrong price on it, or the schedule changed, or the one-pager references a person who's left.
Five hundred copies. Each with a QR code on it. Pointing at the old version.
Whether that's a five-minute fix or a reprint was decided long before anyone noticed the error — at the moment you chose what the code pointed at.
Worth being precise, because the misconception underneath most of this is small and load-bearing.
A QR code is a visual encoding of a string of text. That's it. Usually a URL, sometimes a phone number or a wifi credential, but always just text, baked into a pattern of squares.
Two things follow:
So the code is permanent. Which leaves exactly one lever: what you put at the other end.
QR services sell "dynamic" codes as a feature, and it's a real convenience, but it's worth knowing what you're buying.
A dynamic code doesn't encode your destination. It encodes a redirect URL owned by the service, which forwards to whatever you've currently configured. Change the configuration, and every printed code lands somewhere new. You also get scan analytics, because every scan passes through their server.
That's genuinely useful — particularly if you need to repoint codes at entirely different destinations, which is the one thing a plain URL can't do.
The cost is a dependency in the middle of your own link. Every printed code you own now routes through a third party. If the subscription lapses, the company folds, or the service is acquired and sunset, the codes don't degrade gracefully — they die, all at once, everywhere, including the ones printed on things you can't recall.
For a lot of use cases, that's a big permanent dependency bought to solve a problem you don't have.
Most people don't need to repoint codes at different destinations. They need the content at one destination to stay current.
That's achievable without any redirect layer, provided the URL is stable across content updates. Upload the page, get a link, print the code from that link. Then when the menu price changes, replace the file behind the same link. The URL never moved, so every code already printed now serves the corrected version.
No reprint. No redirect service. No dependency you have to keep paying.
The catch is that this only works if your host keeps the URL stable when you upload a new version. Plenty don't — many file-sharing services mint a fresh URL per upload, which is exactly the behaviour that breaks printed codes. Confirm the re-upload behaviour before you commit a code to ink; it's the single most important property and it's rarely advertised.
This one is quieter and catches more people.
Lots of free hosting tiers put links on a timer — a set number of days and the URL stops resolving. Behind a code on a conference slide, that's fine and arguably good. Behind a code on a business card, a package insert, or a permanent sign, it's a bomb with a delay.
So match the link's lifetime to the object's lifetime, deliberately:
The failure is nasty because it's delayed and silent. Nothing breaks on print day. It breaks in month four, to someone you'll never hear from, who concludes your company is defunct.
Step two is the one everyone skips and the only one that determines whether the answer to "can we fix the menu price" is "yes, done" or "how many did we print."
Upload the page, open the ⋯ menu, and generate its QR code. The link keeps its address when you replace the content — so the printed code keeps working.
If a page is distributed only by a printed code, its view count is effectively its scan count. That answers the question most people actually have — whether the poster, the insert, or the table tent did anything at all.
What plain link analytics won't give you is per-code attribution when several codes point at the same page. If you want to compare the code on the poster against the code on the flyer, give each one its own link and read them separately. Same principle as treating any link open as a signal: the data is only as granular as the number of distinct links you handed out.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
A .json Lottie is not a page — hand it to a client and they get a wall of numbers. What it takes to turn one into something that opens in any browser, and why the answer is smaller than the tooling suggests.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.