A small restaurant in our neighbourhood printed 500 menus last spring. Nice paper, clean layout, a QR code in the bottom-right that pointed at the online menu so anyone could pull up allergens or call the bilingual version up on their phone. Two weeks after printing, the owner got an email. The free trial on the QR code was ending. To keep it working, he had eight days to pay €29 a month. Forever.
He didn’t. The menus still sit in a drawer behind the bar, because throwing out 500 printed menus felt worse than leaving them unused. The QR code now resolves to a sign-up page asking his own customers to start their own trial.
That story is the reason QR menus have a bad reputation, and it is the reason this article exists. The menu QR code is not a broken idea. It is a perfectly good idea that a particular kind of vendor has spent three years discrediting — by selling codes that die, codes that serve ads, codes that work for a week and then hold your printed menu hostage. The technology is fine. The failure is almost always commercial, and it happens after you’ve printed, which is the worst possible time.
This is a companion to the longer guide on QR codes that don’t expire, narrowed to one job: a restaurant menu QR code that will still resolve in three years, after a redesign, after a price change, and after whichever vendor you signed up with has changed its plans. Disclosure up front: Heldqr is our product, and there’s a section below where we recommend it. There’s also a section where we tell you not to use it, because for a chunk of restaurants the honest answer is a different kind of tool entirely.
The honest post-mortem: why menu QR codes get a bad name
Search “restaurant menu QR code” and you will get a wall of menu-builder listicles — Adobe, Canva, Wix, plus the restaurant-tech platforms like Square, Toast and MenuTiger. They are not wrong, exactly. They will all make you a QR code that works on the day you create it. The problem is that “works on the day you create it” is not the thing a printed menu needs. A printed menu needs to work on a random Tuesday eighteen months from now, when a customer who has never heard of your QR vendor points a phone at a laminated card.
When a menu QR code fails, it fails for one of a few reasons, and almost none of them are the QR code’s fault.
The trial expired. This is the one in the anecdote above, and it is the single most common cause of a dead menu QR. You sign up for a “free” QR generator, make the code, send the menu to print, and then — usually by email, usually after the print run is already done — you learn that the code is a dynamic trial code that deactivates unless you start paying. The black-and-white pattern on your menu is fine. It scans perfectly. It just points at a redirect that the vendor switched off to make you pay.
The code serves ads. Some “free forever” generators really do keep the code alive — but when a customer scans it, the redirect shows a full-screen advertisement before it forwards them to your actual menu. You printed a clean menu; your customers see a Google Ads interstitial first. The Me-QR documentation describes exactly this behaviour on its free tier. The code never expires. It just becomes an ad surface pointed at your guests.
The destination moved. You changed your menu host, switched website platforms, or the link you used was generated by a builder that has since rotated its URLs. The QR still resolves to the vendor’s server, but the page behind it is gone. This is link rot, and it affects static and dynamic codes alike.
The price went up and you walked. Year one was paid as part of onboarding, often at a launch discount. Year two is where the vendor finds out what you’ll tolerate. The renewal lands at a higher rate — sometimes a much higher rate, sometimes restructured into a new tier so the plan you signed up for no longer exists — and you decide it isn’t worth it. The day you stop paying, the menu code goes dark.
You can watch this happen in real time on the vendors’ own forums. Square’s seller community has threads with titles as blunt as “Restaurant QR code not working. Not showing menu” — operators describing a code that scanned fine yesterday and shows nothing today. The general QR generators have the same genre of thread. QR Code Generator’s own community forum hosts a customer asking whether already-printed, now-expired codes can be reactivated. Substitute “menu” for “business card” and you have the restaurant version of the same story, told thousands of times.
The pattern underneath all of this is the same one we describe in the pillar: dynamic QR codes are marketed as permanent, the terms of service allow the vendor to deactivate them, and the conversion email arrives after you’ve already committed the code to print. Calling the result “expiration” makes it sound like a natural event, like milk going off. It isn’t. It is a cancellation, scheduled for the moment you’re most stuck.
Static or dynamic — and why a menu almost always wants dynamic
There are two kinds of QR code, and the distinction decides everything about durability.
A static QR code encodes the destination URL directly into the black-and-white pattern. No server sits in the middle. Your phone reads the URL straight off the printed code and opens it. A static code works forever, as long as the page it points to stays live — and you cannot change where it points without printing a new code. It is, mechanically, a physical copy of a URL.
A dynamic QR code encodes a short URL that points at a provider’s server, which then redirects to your real menu. The advantage is that you can change the destination without reprinting: point the same printed code at the lunch menu, then the dinner menu, then next season’s menu. The cost is that the provider is now a permanent part of your QR code. If their redirect goes down, gets deactivated, or starts showing ads, your menu code does too.
For a restaurant, dynamic is almost always what you actually want, for a concrete reason: menus change. Prices move. The kosher/halal/vegan annotations get refined. A seasonal menu swaps four times a year. You redesign the whole thing. With a static code, every one of those changes means reprinting and re-stickering every table tent, every card, every window decal. With a dynamic code, you edit the destination once and every printed code in the building now points at the new menu.
So dynamic is correct — and dynamic is also the most fragile configuration, because the thing that makes it work is the vendor you have no particular reason to trust. Who runs the redirect behind your menu matters more than how the QR code looks. That single sentence is the whole game.
What “permanent” actually has to mean for a menu
“Permanent” and “never expires” are on every QR pricing page in the category, and for menus they have to clear a specific bar. A menu code is permanent only if all of the following are true at once:
- The redirect stays alive when you’re not paying full price. Not “alive until your trial ends.” Alive, period — ideally on a free tier that is a genuine product, not a fourteen-day fuse.
- Nobody injects ads. Your guest scans the code and lands on your menu, not on an interstitial.
- You can change the destination without reprinting. A new menu, a new host, a corrected allergen note — all of it should propagate to the printed code without anyone touching a printer.
- There is a plan for the day the vendor goes away. SaaS companies have a median life of something like four to seven years. A printed menu can easily outlast its QR vendor. “Permanent” is only meaningful if the vendor has written down, publicly, what happens to your codes if they shut down.
Most pricing pages clear maybe one of those. The marketing word “lifetime” usually means “the lifetime of your subscription,” which is to say, not the lifetime of anything you’d recognise as a lifetime.
The menu-QR checklist
Before you print, run the vendor you’re considering through these. It takes five minutes and it is the difference between a menu code that lasts and one that becomes the drawer-of-dead-menus story.
- Is the code static or dynamic — and do you know which one you’re getting? If the generator lets you change the destination later, it’s dynamic and there’s a server you depend on. If it doesn’t, it’s static and you depend on your destination URL staying live. Both are fine; not knowing which you have is not.
- Does the free tier deactivate the code, ever? Read this before you print, not after. If “free” is a trial that disables the code at the end, it is not free for a printed menu — it is a deferred bill.
- Does the redirect show ads to your guests? Scan a test code from a vendor’s free tier with your own phone before you commit. If an advertisement loads before your menu does, walk away.
- Can you edit the destination, and how fast does it take effect? You will reprice, reword, and redesign. Make sure one edit updates every printed code, and that the change is live in seconds, not on a nightly batch.
- Does the provider publish a continuity plan? If they shut down, what happens to the code on your laminated menus? The answer you want is written, public, and irrevocable. The answer most vendors give is silence, which means “nothing.”
- Can you point the code at your own domain? If the printed QR resolves through a domain you control, it can keep working even if the vendor disappears. For a menu reprinted often this matters less than for a wine bottle — but it’s the strongest version of “permanent” there is.
- Can you export your codes and their destinations? A vendor who hands you a machine-readable list of every code and where it points isn’t planning to use lock-in as leverage. One who hides it behind a sales call is.
How to do this with Heldqr
Heldqr is a durable redirect layer. It doesn’t build your menu and it doesn’t take orders — it gives you a dynamic QR code whose destination you can change any time, that resolves for as long as we operate, with no trial, no deactivation, and no ads in the redirect. (Disclosure, again: this is our product.) Here’s how it maps onto a restaurant.
For most restaurants, the free tier is the whole answer. One menu, one QR code, €0, no expiration, no scan cap that ever switches the code off, no credit card. Print it on your table tents, your window, your takeaway bags. When you change the menu — new prices, a seasonal swap, a corrected allergen line — you edit the destination URL once and every printed code in the building points at the new menu in under 60 seconds. No reprint, no re-stickering. The free tier carries a small branded caption on the SVG export and a soft 100-scans-per-month nudge per code, but the code is never deactivated and never stops resolving or recording. For a neighbourhood restaurant with one menu, that is genuinely all you need, indefinitely.
Pro, at €9 a month, is the fit for a venue that runs more than one menu or actually uses the analytics. If you A/B-test two menu layouts to see which drives more dessert scans, or you run a seasonal menu that rotates every quarter, or you want to know which entrance and which table tent get scanned most — Pro gives you clean exports with no caption, custom shortcodes (so the printed link reads like heldqr.io/your-bistro instead of a random string), and 30 days of country-and-device analytics that are cookieless: no IPs, no cookies, no tracking your guests. The headline Pro feature is a custom domain — print the QR against your own restaurant domain and the code keeps resolving even past a Heldqr shutdown. Editing the destination still propagates in under 60 seconds, and the printed shortcode never changes, so a seasonal swap is one edit, not a reprint.
Business, at €29 a month, is for a group or a small chain. It’s Pro plus three seats, bulk CSV import for generating and updating menu codes across many locations in one operation, API access, and daily analytics with a year of history. A five-location group that wants per-site menu codes, managed by a couple of people, updated in one pass when the menu changes group-wide, is the buyer here.
The cross-cutting promise is the same on every tier, including free: the code resolves for as long as we operate, you can edit the target any time, and we publish a continuity plan — twelve months’ notice, the resolver source published at month six, per-account exports and an opt-in public dump of the redirect data at month nine, final shutdown at month twelve. If you ever stop paying, your codes don’t deactivate; they drop to the free-tier resolution floor and keep working. The resolver is open source. None of that depends on you trusting our marketing — you can read it.
If that fits, start a free menu code here, or go straight to Pro if you already know you want the custom domain. Full pricing is at heldqr.com/pricing.
What Heldqr is NOT the right answer for
This is where the intellectual honesty earns its keep, because for a real share of restaurants the right tool is not us.
A full online-ordering or POS-integrated menu system. If what you actually want is a QR code that lets a guest order from the table, pay from their phone, split the bill, apply a loyalty discount, fire the order into your kitchen display, and sync the whole thing to your point-of-sale — that is not a redirect layer. That is an ordering platform, and Square, Toast, and the table-ordering products built around them exist precisely for it. Heldqr can point a printed code at your ordering page, but it will not run the ordering, the payments, or the kitchen integration. If “menu QR code” means “order-and-pay at the table,” go buy the platform built for that. We’d rather tell you than sell you something that doesn’t do the job.
A menu builder. If you don’t yet have a digital menu to point at — no menu page, no PDF, no hosted listing — you need something that designs and hosts the menu itself. Canva, Adobe Express, Wix, and the dedicated menu products will build and host the page. Heldqr starts being useful the moment you have a destination URL and want a durable, editable code pointing at it. Build the menu first; make it permanent second.
A purely static use case where you control the URL. If your menu lives at a stable URL on a domain you own and will keep alive — say yourrestaurant.com/menu — and you genuinely never need to point the printed code somewhere else, then a free static QR from QRCode Monkey, Adobe Express, or Canva is correct and costs nothing. You don’t need a redirect layer for a destination that will never move. We say this in the pillar too: don’t pay anyone, us included, for a problem a free static generator already solves.
In closing
A menu QR code is not a fragile idea. It got a bad reputation honestly — by being sold, over and over, by vendors whose business model is to switch it off at the moment you can least afford it. The trial that deactivates after the print run, the “free” code that shows your guests an ad, the renewal that triples in year two: those are the actual failure modes, and not one of them is a limitation of the technology.
The fix is to treat the code’s durability as the thing you’re actually buying. Get a dynamic code so you can change the menu without reprinting. Check, before you print, that the free tier doesn’t deactivate and the redirect doesn’t serve ads. Pick a vendor that publishes what happens if it disappears. Do those three things and the menu QR code becomes what it was always supposed to be: a small black square that quietly points at the right menu, year after year, no matter how many times you reprint the food around it.
This is a companion to our complete guide to QR codes that don’t expire, which has the full provider-evaluation checklist and names specific vendors. Heldqr is our product; you can read our continuity plan and our pricing before you trust either. Questions, corrections, or a dead menu code you want a second opinion on: hello@heldqr.com.