QR Code Menus: What Actually Works in a Real Venue

QR menus got a bad reputation because most of them are badly done. The failures are consistent and every one of them is fixable before printing.

Fix the destination before the code

The single biggest complaint about QR menus is not the code. It's what the code opens.

Never point a QR menu at a PDF. A PDF on a phone means pinch, zoom, drag, and squint. It's the reason people ask for a paper menu. Point it at a plain web page with real text that reflows to the screen.

The page needs almost nothing: readable type, prices, sections, and no popups. No cookie wall, no "download our app", no newsletter modal covering the starters. A hungry person holding a phone one-handed has very little patience.

Size it for how people actually scan

The working rule is ten to one — the scanning distance divided by ten is your minimum code width.

• A table tent, scanned at arm's length, about 60cm — roughly 6cm of code
• A code printed on the menu itself or a card, about 30cm — roughly 3cm
• A window or A-board scanned from the pavement, 2m — roughly 20cm

Round up. Older phones and dim lighting both eat your margin, and restaurant lighting is deliberately dim.

Print decisions that matter

• Matte, not gloss. Laminated table tents catch overhead spotlights and the glare can wipe out the code entirely. This is the most common in-venue failure and it never shows up in testing under office lights.
• Print from vector. Export SVG so the module edges stay sharp at any size. An upscaled PNG goes soft, and softness is what defeats the camera.
• Keep the quiet zone. The code needs clear space around it. Designers crop it tight against a border; scanners then struggle to find its edges.
• Dark on light. Brand colours are fine if the contrast is genuinely strong. Mid-tone on mid-tone looks tasteful and fails.

Make it dynamic, always

A static code has your URL baked into the print run. Change anything and the printing is waste.

A dynamic code encodes a short link, so the destination is editable forever. For a venue that means: seasonal menu changes without reprinting, a Christmas menu for three weeks and back again, and a page you can repoint to "closed for refurbishment" in ten seconds.

It also means you get scan data — how many, when, and roughly where — which turns the menu into a measurement you didn't previously have. Scan counts by time of day tell you when the room actually fills.

Practical details people forget

• Wifi. If your signal is poor, a QR menu is a worse experience than paper. Test in the far corner of the room, not by the router. Consider printing the wifi password beside the code.
• Always keep some paper menus. Accessibility, dead batteries, and customers who simply don't want to. A QR menu should be an option, not a gate.
• Label the code. "Scan for menu" removes all ambiguity. An unlabelled code is a small act of mystery nobody enjoys.
• Test with the oldest phone on staff, in the actual room, in evening lighting.

Worth doing beyond the menu

The same dynamic code approach works for the review page, the booking page and the loyalty signup — and because every scan is tracked, you finally learn which table tents, flyers or window stickers actually get used.

Generate a menu QR code — pick your error correction, download the SVG, and test it in the room before it goes to print.