Reference · 11 min read

QR codes for a printed menu that do not stop working

Why a dynamic QR code can kill 200 printed table tents at once, when it is still the right choice, and how to print one that nobody can switch off.

Here is the failure that catches restaurants, and it catches them the same way every time. Two hundred laminated table tents, printed with a QR code. Fourteen months later the code stops showing the menu and starts showing a page saying the trial has ended, with an upgrade offer on it. Every table. Friday lunch.

Nothing is broken. The website is fine, the menu page is fine, the printing is fine. The code simply never contained the menu address in the first place. Below is why that happens, when the risk is worth taking, and how to print a code that outlives the company that made it.

What is actually inside the code

A QR code is not a link. It is a short block of text, drawn as squares. The camera reads the text back out and the phone decides what to do with it; if it looks like a web address, the phone offers to open it. A static code for your menu contains your address, and only that:

https://example.com/menu

A dynamic code contains somebody else’s address instead:

https://scan-vendor.example/a7Kd2

That second string is what gets printed and laminated. The phone goes to the vendor’s server, which looks up a7Kd2 and replies with a redirect to wherever you last set it in their dashboard. The indirection is the whole feature. It is also the whole problem.

StaticDynamic
Printed code containsYour addressThe vendor’s short address
Must stay alive for it to workYour siteYour site, the vendor, the vendor’s domain, and your subscription
Change the destination laterOnly if you control the destinationYes, from a dashboard
Scan analyticsNone from the code itselfYes, per scan
Ongoing costNoneMonthly or annual, forever
Who can see your customers scanningOnly you, in your own logsThe vendor

The failure mode, costed honestly

When a dynamic code dies, every printed copy dies at the same moment. That is the part people underestimate. It is not one code, it is the table tents, the window sticker, the A-board, the takeaway flyers and the business cards, all pointing at the same dead short link.

Cost it out for those 200 table tents: artwork reset, a reprint on the same laminated stock, and an afternoon of two staff swapping them out during service. A few hundred pounds and a bad Friday. The subscription that would have prevented it was cheaper. That is exactly why the model works.

There is a second, quieter risk that matters more than expiry. The printed code contains the vendor’s domain name. If that company folds and lets the domain lapse, anyone can buy it, and every code you ever printed now points wherever the new owner likes. You cannot revoke it. You can only reprint.

When a dynamic code is genuinely the right answer

It often is, and pretending otherwise is how people end up with the wrong code for the wrong reason.

  • A campaign you must retarget mid-flight. Ten thousand flyers already in the wild and the landing page has to change next week. If you cannot reprint, you need a redirect.
  • Analytics you will act on. Not “interesting to see”. Genuine per-placement comparison: does the window sticker beat the A-board, is page four of that magazine worth buying again. Static codes cannot tell those apart unless each carries a different address.
  • No website and no domain. If the vendor hosts the menu page too, that is a real service, not a tax on your own content. Just understand that you are renting the address on your tables.
  • Short-lived print. Event badges, a one-week promotion, a conference handout. Nothing printed for a fortnight needs to survive a decade.

A menu is the opposite of all of it. Long-lived, one destination, and nobody needs to know which table scanned.

The professional answer: a static code at an address you own

You can have both properties — a code that never expires and a destination you can change — by putting the redirect on your own domain instead of somebody else’s.

  1. Own a domain. Two coffees a year, on auto-renew.
  2. Pick one short path and treat it as permanent: example.com/m or example.com/menu.
  3. Generate a static code containing it. Print that.
  4. When the menu moves — new platform, new page, new season — leave the code alone and change what the path serves, with a 301 or just new content.

You control the redirect, so the code is editable. Your server logs count the hits, so you have analytics. Nothing expires, because nothing is rented.

Two honest caveats. The domain is now your single point of failure: set auto-renew, keep the card on file current, and do not leave it in an ex-employee’s personal account. And it only works on a domain you own — a free subdomain from a hosting plan, or a public link shortener, is the same trap wearing a different hat, because the printed code carries their name and not yours.

This is why QR Studio makes static codes only, and shows you the exact text that will be encoded before you download. If the code contains your address, there is nothing left for us to switch off.

Getting the print right

A dead redirect kills every code at once. Bad printing kills them one scan at a time, which is harder to notice and more annoying.

Where it goes on the table

Put it where a seated hand already is: a table tent angled towards the chairs, or the bottom outer corner of the menu card. Three places to avoid, all of them popular with whoever designed the table:

  • The centre of the table. That is where the condiments, the flowers and the food go. The code spends service under a plate.
  • Flat under a glass top. Reflections, plus a camera angle that means leaning over the table.
  • The back of the menu. People do not turn it over.

If the table seats people facing each other, one double-sided tent beats a code on every menu card. Fewer things to swap when something changes.

Size it for the distance

The working rule of thumb: a code needs to be about one tenth of the distance it will be scanned from. Round up. Nobody has ever complained that a code was too easy to scan.

PlacementScanned fromPrint at least
On the menu card, in the hand250–300 mm25–30 mm
Table tent, seated350–450 mm40 mm
Wall or till poster1 m100 mm
Window, from the pavement2 m200 mm

Keep the address short, because every extra character adds modules to the grid and shrinks each one at a fixed physical size. At the usual error-correction level a 29×29 grid holds about 42 characters of a typical URL. example.com/m fits with room to spare; a URL dragging a string of tracking parameters does not, and prints as a dense mess that needs a better camera.

Quiet zone, contrast, and the laminate problem

  • Leave the margin. A QR code needs four modules of blank space on all four sides. On a 40 mm code that is roughly 5 mm of nothing. Designers crop it constantly and it is the most common cause of a code that scans on screen and not on card.
  • Dark on light, high contrast. Not pale grey on cream, not over a photograph, not reversed out of dark wood-effect stock. Some scanners cope with inverted codes; enough do not.
  • Matt laminate, never gloss. This is the number one real-world scan failure in restaurants. Gloss under a ceiling spot throws the light straight back and the phone sees a white rectangle. Matt or silk fixes it completely.
  • Print from vector. SVG, PDF or EPS, so module edges land crisp at any size. A small PNG scaled up gives soft edges and a decoder that hesitates at an angle.
  • Go easy on the logo. A logo covers real data. Keep it small, raise the error correction, and re-test after every change.

Test the printed thing, in the room

Scan the actual card, on the actual table, under the actual lights, with the oldest phone in the building. Test it at an angle, and again at night when the lighting drops. A code that scans on your monitor has proved nothing about the laminate.

Print the address underneath

Always. A line of 8 pt text reading example.com/m rescues every failure the code cannot: a cracked lens, a locked-down work phone, a guest who does not know the camera scans codes, someone who would rather type. It also reassures people who have learnt, correctly, to be wary of scanning an unknown square in public.

Some customers will not scan, and that is fine

A QR menu shifts work onto the guest. Plan for the ones it does not suit.

  • Keep paper menus in reach, unasked. Having to request one is the barrier. A stack on the table removes it.
  • Serve a real web page, not a PDF. A PDF of an A3 menu on a phone means pinch, zoom, drag, and it is close to useless with a screen reader. Plain HTML reflows, zooms and can be read aloud.
  • No app, no login, no wall. If a cookie banner or a sign-up form appears before the food does, you have made ordering harder than a laminated card.
  • Allergens as text, not as a picture of a table. This is the part somebody may genuinely need a screen reader for.
  • Large print, decent contrast. Your guests include people over sixty in dim lighting. Body text no smaller than 16 px.

Checklist

  1. Decide whether you will ever need to retarget. For a menu, you will not.
  2. Buy a domain, set auto-renew, and pick one permanent short path.
  3. Generate a static code containing that address, and read the decoded text before downloading.
  4. Put it where a seated hand already is, not in the middle of the table.
  5. Size it from the scanning distance: 40 mm for a table tent, 200 mm for a window.
  6. Keep four modules of quiet zone, dark on light, vector artwork.
  7. Matt laminate, not gloss.
  8. Print the address under the code.
  9. Test the printed piece on the oldest phone you can find, in situ, at night.
  10. Keep paper menus out where nobody has to ask.
  11. Serve real HTML with real text, and no wall in front of it.