QR code menus for restaurants and cafés

A restaurant menu code fails for reasons no other code faces: dim lighting, laminated glare, and a hungry person who gives up after two seconds.

6 min read · Updated

Every other guide here is about making a code that works. This one is about making a code that works at a corner table, at 8pm, on a phone at 12% battery. Those are different problems, and most menu codes fail the second one.

Point it at a web page, not a PDF

A PDF menu on a phone is a pinch-and-drag ordeal: text too small to read, no reflow, and a download prompt on some devices. A plain HTML page costs nothing extra and reads instantly. If you only have a PDF, at least make it a single portrait page sized for a phone screen.

Keep the URL short. Every character makes the code denser, and density is the enemy in low light. yourplace.com/menu beats a link with tracking parameters bolted on.

Size and placement on the table

A table tent is scanned from roughly 40–60 cm, which by the distance ÷ 10 rule means at least 4 cm of code — go to 5 cm and stop worrying. Put it where a phone can reach it without moving glassware, and keep it upright: a code flat on the table gets scanned at a steep angle, which costs you contrast and focus.

Print it on more than one surface. One table tent per table is a single point of failure when someone knocks it over or a server clears it away with the plates. A small code on the napkin holder, the wall or the placemat costs nothing and saves the visit.

Restaurants are dark, and lamination is glossy

This is the difference that catches people out. A code that scans perfectly at your desk fails at table six because two things stack up: the room is dim, so the camera opens up and loses sharpness, and a glossy laminate throws a bright reflection straight across the modules.

  • Matte lamination, always. It costs the same and it is the single biggest improvement you can make.
  • Plain black on white. Save the brand colours for the frame around the code, not the modules themselves.
  • Error correction Q rather than M — menus get greasy, creased and scratched within a week.
  • Test at the table, in the evening. Not at the pass, not in daylight, and not on the newest phone in the building.

Tell people what they get

A bare code on a table tent gets ignored. A code with “Scan for the menu” under it gets used. Add the line in every language your guests speak, and add a caption frame so the instruction is part of the artwork rather than an afterthought.

If you also run a guest network, a second small card with a Wi-Fi code removes the other question your staff answer forty times a night.

Keep the paper menu

Not everyone can use a QR menu: older guests, someone with a dead battery, a phone with no data, a visitor roaming abroad. Several jurisdictions also require a readable price list on request. Keep a handful of printed menus behind the bar — the code is there to save time, not to remove an option.

Your code should outlive your menu

Print a code that points at a stable URL, then change the page whenever the menu changes. Never encode the dish list itself, and never point at a file name with a date in it — the code is permanent, the menu is not. This is exactly why a static code pointing at a page you control beats a dynamic code from a vendor: the redirect belongs to you, so nothing expires when a subscription lapses.

Before the print run

Print one proof, laminate it the way the real batch will be laminated, and scan it at a real table in real evening light with an old phone. If it hesitates even once, size up or simplify before you order two hundred. The troubleshooting checklist covers what to change first.