A menu QR code that people actually use

The PDF trap

PDF is a fixed-layout format. It was designed so a page looks identical everywhere, which is exactly what you do not want on a phone. Either the text becomes tiny or the guest has to scroll sideways, and both lose.

Print the same content as a normal web page instead. One heading per course, prices right-aligned or after the dish, no multi-column layout. If the kitchen changes a dish, you edit text rather than exporting a new PDF and hoping every printed code still resolves.

• One column, body text at default zoom, no pinch required
• Prices next to the dish, not in a separate column that collapses
• No page-flip animation: it breaks on slow connections
• Test on an old phone on mobile data, not on your laptop

Static code, editable menu

A static code is not a limitation here. Generate it once, point it at your own domain, and forward that path to whatever the menu is today. When the menu changes, the page changes and the printed code does not.

The only case that genuinely needs a redirect service is when you must move to a different domain and cannot set up a redirect yourself. If you control DNS, you can do that without paying anyone.

Table size, and the code people ignore

A code on a table tent is read from about 30 cm, so 3 cm is enough and 4 cm is comfortable. Anything over 5 cm starts to look like an advertisement rather than a menu.

Do not put the code on the table alone. Put it on the same card as the guest Wi-Fi code, so the card has two reasons to exist and guests pick it up. A card that does one thing gets ignored; that is why the Wi-Fi code on the same tent roughly doubles the number of people who scan either.

• Table tent: 3 to 4 cm, matte, at an angle rather than flat
• Never behind glass or under a laminate that catches the lamp above the table
• Keep printed menus available: not every guest wants to use a phone

What to track, and what not to

If you want to know how many people open the menu, that requires a redirect service, and in the EU that service processes personal data. You then need a legal basis and a line in your privacy policy.

The honest alternative is to count nothing. Use server logs you already have, which record a request without giving you a per-guest profile, and accept that you will know roughly how much the menu is used rather than exactly who used it.