Putting your menu behind a QR code
The decisions that stop you reprinting table tents — where the menu lives, static versus dynamic, and the test worth doing first.
Making the code is the easy part. The decision that costs money is what it points at, because the printed code can never be changed, but the page behind it can be changed as often as you like. Get that relationship right and one print run lasts for years.
This covers the choices worth making before you send anything to a printer: where the menu should live, why the “dynamic” codes sold as a feature are a risk, and the one test that separates a working table tent from a reprint.
Where the menu actually lives
A QR code holds a web address. It does not hold your menu. You still need a page for it to point at, and the choice of page matters more than anything about the code itself.
| Where the menu lives | What you get | What it costs you |
|---|---|---|
| A page on your own website | Full control. Change prices whenever you like, and the printed code never goes stale | You need a website, or somewhere to put one page |
| A PDF you host | Easy — you already have the file from the printer | Pinch-and-zoom on a phone is a poor way to read a menu, and a print-resolution PDF can be slow on mobile data |
| Your listing on a delivery app | Free, and already exists | It hands your seated customer to a marketplace, where a competitor is one scroll away and an order earns the platform a commission |
The first option is the only one where you control both the destination and what it shows. If you have no website at all, a single hosted page — even a very plain one — is worth more than a PDF, because the menu is read on a phone and a PDF is laid out for paper.
The trap in “dynamic” QR codes
Two kinds of code are sold, and the difference only becomes visible after you have printed.
A static code has the address written into the pattern. Nothing sits in the middle. Print it and it works for as long as the destination exists — no account, no subscription, nobody who can switch it off.
A dynamic code has a short link belonging to a provider written into the pattern. Scanning goes to them first, and they forward the customer to wherever you have currently pointed it. That is genuinely useful: you can change the destination without reprinting, and you get scan statistics.
The cost is rarely stated plainly. Every printed code depends on that provider staying in business and keeping your redirect free. If they close, raise prices, or expire the free tier, every table tent in the room stops working on the same day — and you cannot fix it without reprinting all of them.
There is a way to get the useful half without the risk: point a static code at a page you control, then change what that page shows.
QR code → yourrestaurant.com/menu → whatever you serve there today
↑ ↑
printed yours to change
once whenever you like
New prices, a seasonal menu, a link to an ordering system, a redirect somewhere else entirely — all of it changes behind a URL that never changes. The code on the table never needs to know.
When you have settled on that address, the QR code generator will turn it into a code. Choose SVG if the printer asked for vector artwork, PNG for anything else.
Size, finish and where it sits
A table tent is read at roughly arm’s length, which puts the code at about 2.5 to 3 cm across. Smaller works in good light on a new phone and fails for the customer at the next table with an older one. The full reasoning and a size table for other formats is in what size should a QR code be for print.
Three things matter more than size in a dining room:
- Matte, not gloss — laminate throws a reflection back at the camera from exactly the angle someone holds a phone over a table. Matte finishes scan far more reliably in the same light.
- Leave the white border alone — the margin around the code is part of it. Scanners use it to find the code’s edge. It is the first thing a designer crops and it breaks the code.
- Keep it off the fold — a code across the crease of a folded card sits on two planes at once, and the camera cannot resolve both.
Print the essentials in text too
A code with no fallback is a dead end for that table. Some customers will not scan, some phones will not cooperate, and some will have a flat battery and be reading over a friend’s shoulder.
Print the address in readable text next to the code. Add the phone number. If the menu link is long, it is worth setting up a short one just so it can be typed.
This costs a line of text on artwork you are already printing, and it is the difference between a customer who has to flag down a member of staff and one who does not.
Wi-Fi needs its own code
Do not try to combine them. One code holds one thing, and a code that joins a network cannot also open a page.
If you want both, print two, label them clearly, and keep them apart on the card — a customer who scans the wrong one gets a confusing result rather than an error. Wi-Fi codes carry the password in plain text, so put guests on the guest network rather than the one the till is on.
Test before the print run
One test print, on the actual card stock, at the actual size.
- Scan it with two different phones, ideally one iPhone and one Android.
- Do it in the dining room, in the lighting the room actually has, not at a desk.
- Hold the phone the way a customer would — at an angle, over the table, not square on.
- Follow through to the menu and check it reads well on a phone screen, not just that the code opened something.
If it will not scan, the nine usual causes are listed in the order they turn out to be the problem.
One test print costs almost nothing. Reprinting every table tent in the restaurant does not.