QR code menus for restaurants: a complete setup guide

Never point a QR menu at a PDF

A PDF is a fixed-width document designed for A4 paper. On a phone it opens in a viewer, renders at a width nobody can read, and forces the guest to pinch, zoom and pan their way around while holding a drink. Bounce rates on PDF menus are dismal, and the guest's first interaction with your restaurant becomes mild irritation.

Point the code at a mobile-first web page instead: type sized for a phone held at arm's length, courses in collapsible sections, prices that you can change from a phone behind the pass, dietary tags that filter, and photographs that lazy-load so the page still appears instantly on weak mobile data in a basement dining room.

The practical test is simple. Open your menu on a phone, one-handed, in a dimly lit room, on a throttled connection. If you would not want to order from it, neither will your guests.

• Target under two seconds to first meaningful content on 4G.
• Body text at 16 px or larger; no horizontal scrolling at any width.
• Collapsible sections per course so the whole menu is navigable with a thumb.
• Allergen and dietary filters rather than a footnote key.
• Mark sold-out dishes instead of removing them, so guests are not confused by a changing list.

Table tents, sizing and the stock you print on

Table codes are scanned from roughly 30–40 cm, which puts 3 cm square in comfortable territory and 2 cm at the floor. Anything smaller runs into the minimum focus distance of the phone camera, which is the failure mode guests experience as 'it just won't read'.

Stock matters more than most people expect. Gloss and laminated finishes produce specular highlights under the warm, directional lighting that restaurants favour, and those highlights land exactly where a seated guest holds their phone. Matte or silk stock diffuses the same light and scans reliably. If the tents live on tables and will meet wine, oil and cleaning spray, choose a matte laminate rated for wiping rather than an untreated card that will curl by week three.

Placement is the other half. A code flat on the tabletop under a centrepiece is invisible; a code on an upright tent at eye level from a seated position is scanned without instruction. Add three or four words of prompt — 'Scan for menu' — because a bare code still confuses a meaningful share of guests.

One code per table, and what that unlocks

It is tempting to print one code for the whole restaurant. Resist it. Give every table its own dynamic code, all pointing at the same menu page. The menu experience is identical for the guest, but your scan data now has a dimension it otherwise never would: location within the room.

That tells you when the terrace fills relative to the inside room, which tables turn over fastest, whether the bar-counter codes are noticed at all, and how the room behaves across a service. Restaurants routinely use this to re-plan sections, re-time staffing, and settle arguments about whether the back room is genuinely dead or just feels that way.

Because the codes are dynamic, all of them can be re-pointed at once from a single dashboard, so per-table codes cost you nothing in maintenance.

Languages, seasons and service-time switching

Do not print one code per language. Route on the landing page instead: detect the browser language, offer a visible switcher, and keep a single physical code per table. Guests who need a different language find it in one tap, and you avoid a table tent covered in four codes that nobody can distinguish.

Seasonal and daypart switching is where dynamic codes earn their keep in hospitality. Point the code at the brunch menu until 11:30, the lunch menu until 16:00, and the dinner menu after that, without anyone touching a single tent. The same mechanism handles a festive menu in December and a reduced menu on a short-staffed Tuesday.

• Detect language, but always show a manual switcher — detection is often wrong for tourists.
• Switch dayparts on the destination, not by swapping printed codes.
• Keep one canonical menu page per language so search engines can index it.
• Publish the menu as real text, not images of text, so it is readable and indexable.

What to measure, and what it means

Three numbers carry most of the signal. Scans per service tells you adoption and lets you compare weeks fairly. Device split tells you whether investing in Apple Wallet loyalty passes is worth it for your particular clientele. Repeat scan rate — the same guest scanning two or three times in one sitting — is usually a warning rather than a win: it typically means the page is slow, the navigation is confusing, or the menu is so long that people lose their place and start over.

Compare scans against covers to get an adoption rate. If half your tables never scan, the problem is almost always physical: the tent is in the wrong place, there is no prompt text, or the printed size is too small for the lighting.

None of this is visible with a paper menu, which is the honest argument for the whole exercise. You are not saving on printing; you are turning the menu into something you can observe and improve.