What Is a QR Code Menu?
A QR code menu is a printed code — on a table tent, counter, or window — that opens your menu on a guest's phone the moment they scan it. No app, no typing, no laminated binder. The code itself never changes; the page behind it can change as often as you like.
How scanning works, from the guest's side
- The guest points their camera at the code. A bubble appears with the menu link; one tap opens it in the browser.
- The menu loads as a normal web page. It is a plain page — big text, sections, prices, allergen notes — sized for a phone, so scrolling feels like any site.
- They order. Nothing to install, nothing to sign up for, no account between the guest and your prices.
Want to see exactly what a guest sees? Open our live sample menu — it is a real hosted menu page, the same shape a restaurant gets.
Static vs dynamic codes: the one decision that matters
Every menu QR code is one of two kinds, and the difference decides whether you will ever need to reprint.
| Static code | Dynamic code | |
|---|---|---|
| Where the URL lives | Printed into the squares | Behind a short redirect address |
| Change the menu link later | Reprint every code | Change the destination, keep printing |
| Change a price | Edit the linked page (if the link still works) | Edit the page; code untouched, live within 60 seconds |
| Works if your service is down | Same — the page still has to load | Same |
| Typical use | Permanent link that will never move | Restaurants that edit menus and prices |
You can make a static menu code free in your browser — it is the right tool when the URL is final. If your prices move, you want the dynamic route: see what QR code tracking can and cannot tell you once codes are in the dining room.
The honest pros and cons
Pros. Menus update in seconds instead of print runs; ink and paper stop being the bottleneck for seasonal changes; you can fix a wrong price from your phone between services; and per-table codes tell you which tables actually scan — useful for checking that a table tent is placed where guests see it.
Cons. Guests need a phone and a signal — print a small number of paper menus for anyone who prefers one or whose battery is dead; an untested URL wastes a whole print run, so always scan every code after printing; and a code pointing at a PDF that you replace (rather than edit) silently breaks, because the address changed underneath a printed square. This is the failure that pushes restaurants to dynamic codes.
One code at the door, or one per table?
A single entrance code shows everyone the same menu and is the cheapest start. A code on every table does everything the door code does, plus one thing restaurants actually ask for: it distinguishes Table 7's scans from Table 12's — enough to spot which table tents get noticed, and nothing about the person holding the phone. Guest-side privacy is simple here: menu pages run no analytics scripts and collect no names, phone numbers, or location.
Per-table codes are the whole model behind QRdishes pricing — flat per restaurant, table codes unlimited — and our print-ready table code sheets are the A4 part of the job.
Four setup mistakes that waste a print run
- Linking to a PDF that gets replaced, not edited. Uploading "menu-oct.pdf" and later replacing the file under the same name usually works — but if the filename changes, every printed code breaks. Prefer a page you edit, or a redirect you control.
- Testing only on the owner's phone. Scan with two phones and both camera apps before printing; camera apps differ in how forgiving they are of small codes.
- Printing too small. Below roughly 0.4 mm per module on paper, older phone cameras start failing at arm's length — especially in the low light of a dining room.
- Forgetting a paper fallback. One stack of paper menus on the host stand costs nothing and keeps the table served when a phone is dead.