A customer sits down, scans the code on the table, and gets a 9 MB PDF that loads sideways over one bar of signal. They pinch, zoom, squint, give up, and flag down a server for a paper menu. Nothing shows up on any report, but that little moment of friction plays out in restaurants every night, and it quietly trains your guests to stop scanning.
The frustrating part is that a good QR menu is easy to get right, costs nothing per month if you set it up correctly, and never breaks unless you break it. The bad ones fail in one of three ways: the code won't scan, the thing it opens is painful, or the link behind it quietly died. All three are fixable in an afternoon.
Point the code at a domain you own
A QR code is just a pointer. The code itself is nothing; the URL inside it is everything. So the single most important decision is what that URL is, and the rule is short: it should live on a domain you control. Something like `yourplace.com/menu`. Not a menu host's short link. Not a QR generator's redirect.
The trap works like this. You search for a free QR generator, and most of them default to a "dynamic" code, which means the code doesn't contain your menu link at all. It contains a redirect through their domain, which then forwards to your menu. That's the hook. When the free trial ends or the plan lapses, the redirect stops forwarding and starts showing an upgrade page, or worse, ads. Every table tent and window sticker you printed now belongs to somebody else's pricing plan.
A plain static code pointing at your own URL has none of that. It's free to generate, it works forever, and nobody can hold it hostage. When the menu changes, you change the page behind the URL. The printed code never needs to change, because the URL never changes. That's the entire trick behind "no monthly fee," and it's also the fix for dead links: a link on your own domain only dies if you kill it.
Dynamic codes do have a legitimate use, which is repointing a code after it's printed and tracking scan counts. But you get the repointing for free by owning the URL, and scan counts on a menu tell you less than your till does.
PDF, web page, or ordering page
What the code opens matters as much as whether it scans. Pick based on how often your menu actually changes.
| What's behind the code | Right when | The catch |
|---|---|---|
| A PDF | The menu changes a few times a year and you already have the file | File weight. Export a text PDF under 1 MB. A phone photo of the paper menu is not a menu, it's a punishment |
| A simple web page | Prices move, items sell out, specials rotate weekly | Someone has to actually update it, and that someone needs to know it's their job |
| An ordering page | You want the scan to end in an order | This is software, not a file. It earns its keep at dine-in volume |
Whichever you pick, it has to work on a phone held in one hand: a single column that reads without zooming or sideways scrolling. Test it on cellular data with the wifi off, because your guests aren't on your office wifi and the patio has two bars on a good day. If the menu isn't readable within about five seconds on a weak connection, the file is too heavy.
Print it so it actually scans
We'll keep this short, because most of it is common sense that somehow still goes wrong on real tables.
- Size: at least 2.5 cm (1 inch) square for arm's length scanning. For a wall poster, take the scanning distance and divide by ten; a code meant to be scanned from 3 metres should be about 30 cm wide.
- Contrast: dark code on a light background. Never invert it to look stylish. Phone cameras are trained on dark-on-light and some will refuse anything else.
- Quiet zone: leave a white border around the code. Art that crowds the edges breaks scans.
- Laminate: matte beats gloss. Glossy laminate under sunlight throws glare that kills the scan, which is why the patio codes always fail first.
- Before you print fifty of them, scan the proof with one iPhone and one Android from a real seated position.
Scratched or faded codes stop scanning long before they look bad to you. You walk past them every day; your camera never does.
Run this test on your own tables today
This takes fifteen minutes and costs nothing.
- Take two phones, one iPhone and one Android, turn the wifi off on both.
- Scan every code in the building from a seated position. Every one, including the window sticker.
- Time each menu load. More than five seconds on cellular means the file needs shrinking.
- Look at the URL preview before tapping. If the link routes through a domain that isn't yours, you've found a dead link waiting for a billing date.
- Check what loads: are the prices current, are dead items still listed, does it read in one column without zooming?
- Inspect the physical codes for fading, scratches, glare, and codes taped over older codes.
Whatever fails, you now know exactly which of the sections above fixes it.
When the menu should become an order form
An honest boundary: if you're a twelve item counter spot and the menu changes twice a year, a clean PDF behind a static code on your own domain is all you need. It costs nothing monthly, and anyone selling you a subscription for that is selling you the redirect trap with better branding.
The step up is worth thinking about when dine-in guests are already scanning at the table. At that point the same scan can do the whole job: the guest orders and pays from the phone, and the ticket goes straight to the kitchen instead of through a server's notepad. Ordering and payment are software territory, and that's exactly the dine-in flow Eatz runs, with a QR code per branch and the kitchen display on the other end. Plans are on the pricing page, and if you're weighing whether your own ordering channel makes sense at all, start with how restaurant online ordering actually gets set up.
Either way, the QR menu itself should never cost you a monthly fee. Save the budget for the version that takes orders.
Frequently asked questions
Do QR code menus need a monthly subscription?
No. A static QR code pointing at a menu page on your own website is free to create and works forever. Subscriptions buy you a redirect you can repoint plus scan statistics, and you don't need either if the code points at a URL you control, because you can change the page behind that URL any time without touching the printed code.
What should a QR code menu link to?
A URL on a domain you own, like yourplace.com/menu. Behind that URL, use a light text based PDF if your menu rarely changes, or a simple mobile friendly page if prices and items move often. Avoid linking to a menu host's short link or a QR generator's redirect, because the code dies when that account does.
Can I change what a QR code points to after it's printed?
A static code, no, the URL is baked in. But you get the same effect by pointing the code at your own URL and changing the page behind it. The printed code stays valid forever and you swap menus as often as you like. Paid dynamic codes solve a problem you can avoid having.
How big should a printed QR code be?
At least 2.5 cm (1 inch) square for table tents scanned at arm's length. For posters, divide the scanning distance by ten: a code scanned from 3 metres should be roughly 30 cm wide. Keep a white margin around it and print dark on light, never inverted.
Are QR code menus still worth using?
For dine-in spots where the menu changes, yes, they save reprinting and they're the doorway to scan to order. But keep some paper menus on hand. A share of guests will always prefer paper, and forcing a phone on someone who doesn't want one costs more goodwill than the printing saves.