Setting Up Restaurant Menu QR Codes Properly

Menu codes earned a bad reputation in 2020 for reasons that had nothing to do with QR technology: PDFs of the paper menu, a too-small code on a sticky label, taped to a table in direct light. The version that works differs in almost every respect.

Decision one: the menu should be a web page, not a PDF

	Menu as a web page	Menu as a PDF
Reading on a phone	Reflows to screen width	Pinch-zoom, sideways scrolling
Changing one price	Edit, save, done	Edit source file, re-export, re-upload
Sold-out item at 8pm	Mark unavailable in seconds	Re-export and re-upload, if anyone bothers
Load time	A few hundred KB	Often 3–10 MB of embedded images
Search / accessibility	Findable, translatable by the browser	Usually neither
Allergen updates	One edit	One edit plus a re-upload, if you have the source

The objection is always "but I have the designer's PDF." Keep it for print and use it as the basis for a simple page — even plain HTML with headings and a price list beats a PDF on a phone. If that is too much, put the menu on whatever platform you use for bookings and point the code at that. See PDF QR codes for the cases where a document is genuinely the right answer.

Decision two: "see the menu" or "order and pay"?

These get lumped together and they are not remotely the same project.

• Scan to browse: the code opens the menu, the waiter still takes the order. Easy to implement, works anywhere, and preserves the table experience most full-service restaurants are selling.
• Scan to order: the code opens a live ordering flow tied to a table number and a payment method. This changes your staffing model, your kitchen ticket flow, and the way you handle complaints about the wrong dish arriving.

Order-at-table works where speed is the product and struggles where the server's recommendations are part of what people pay for. Every table then needs its own code or a way to enter the table number — get it wrong and food lands in front of strangers.

Size, angle and material for the physical code

A table code gets scanned downward at 30–50 cm, often through glass, often with someone's drink nearby. Three rules cover most of it:

1. Size: 5 cm square minimum for a table sticker. Bigger if the code sits flat under a menu holder a guest must lift.
2. Contrast: black on white. Brand-coloured codes look great and scan terribly, particularly anything with low luminance contrast like navy on grey.
3. Surface: matte laminate, vinyl or hard plastic — anything that survives a wipe and a bag being dropped on it.

Menu URLs are short, so the symbol stays sparse — usually version 4 at error correction M, 33 × 33 modules or fewer. What kills these codes is glare, condensation and scratches, not density. Tilt the sticker 10–15 degrees toward the seated guest, and keep it near the table edge rather than dead centre, where spills land.

Multi-language without duplicating codes

Three approaches, in rough order of preference:

1. Language switcher on the page. One URL, one code, a flag or dropdown at the top. The browser can often pre-select the right language.
2. Separate codes per language. Needs clear labelling ("Menü — DE") and only makes sense on different placements.
3. One long bilingual page. Doubles scrolling; guests give up halfway and ask staff anyway.

Whoever changes the menu owns the translations too. A translated menu two weeks behind the original is worse than none, because guests will hold you to it.

The expiry problem: who owns updates

Every menu QR installation eventually shows last season's prices. Name one owner and give them a routine, or assume staleness:

1. One owner — a manager, not "whoever is on shift".
2. Two triggers: any price change and any 86'd dish. Nothing else justifies an edit; everything else waits for the weekly check.
3. A standing weekly review — same slot each week, open the page on a phone, verify prices match the POS.
4. Sold-out handling decided in advance, either a strike-through or a hidden item. Do not let each shift improvise.

Allergen information deserves its own line in that routine: "contains nuts" errors escalate much faster than wrong prices. If your rules require allergen disclosure, treat the QR menu as the official record — beyond that, take specifics up with your local authority rather than a QR blog.

Staff scripts and the human fallback

Roughly one guest in ten will not be able to scan: dead battery, borrowed phone, no signal in a basement dining room, or they simply prefer paper. Decide what happens for them before opening week.

• A written phrase every server uses — "Hi, we keep the full menu here; the code is on the table, or I can bring a paper copy." Neutral, no implication that scanning is the guest's job.
• A small stock of disposable or wipeable menus for exactly this case.
• Wi-Fi. If your signal is weak and the menu needs a network request, the whole thing stalls. Either improve coverage or publish the guest network details — see sharing WiFi with a QR code.
• A known answer for "can I order with you instead?" Yes, always — unless you genuinely run order-only service, and then that should be obvious before guests sit down.

Launch checklist

1. Scan the code from the actual seated position, under the actual lighting. Not at your desk.
2. Time the load on 4G cold. Under two seconds or expect people to give up.
3. Verify the menu page needs no pinch-zoom and no horizontal scroll.
4. Confirm prices match the till for every item, including specials.
5. Wipe a sticker with a wet cloth; check it still scans.
6. Watch two people outside your team scan it, told nothing. Their hesitation shows where the script is unclear.
7. Run one test order end to end if you offer order-at-table, including the wrong-table-number case.
8. Put the update owner's name somewhere operational, not on the menu.

Distance maths for print lives in QR code print sizes, campaign do's and don'ts in QR best practices.

FAQ

Is a PDF menu really that bad?

On a phone, yes, in most cases. Readers zoom and pan a two-column layout designed for A4, and every change means re-exporting the file. A simple page is less work over a year, even after you spend the setup time.

How large should a table QR sticker be?

Around 5 cm square as a floor. Menu URLs are short so the symbol is sparse; your constraints are lighting angle, glare and wear, not data capacity.

Can one code cover several tables?

Yes for browsing — every table can share a code pointing at the same menu URL. No for ordering, where the order needs to be tied to the correct table.

What about guests whose phone cannot scan?

Keep paper copies and give staff a script. Roughly one table in ten will need it, and "no problem, I'll bring a menu" costs you nothing while "just scan it" can cost you the review.

Should there be a different code per language?

Prefer one code with a language switcher on the page. Separate codes mean separate stickers, separate testing, and the risk of a guest sitting at the wrong one.

Does the code need to change when prices change?

No, if it points at a URL. Change the page, not the sticker. This is exactly why the page-not-PDF decision pays off.

Do menu codes need error correction above level L?

Level M is a sensible default for anything on a table that gets wiped and scuffed. It costs some density, which short menu URLs can easily absorb.