QR Code Menus for Restaurants: What Actually Works in 2026

A QR menu is either the cheapest operational upgrade in your restaurant or a laminated card nobody touches. The difference is almost never the code itself. It is the decision you make before printing, the page behind the code, and where the card physically sits on the table.

Decide first: static or dynamic

This is the one choice you cannot undo cheaply, so make it consciously.

A static QR code has your menu URL baked into the pattern. It works forever, needs no subscription, and no one can switch it off. It also cannot be edited. If the URL changes, or you move from a PDF to a proper page, every printed card, decal and tent becomes scrap paper.

A dynamic QR code points to a short redirect you control. The printed pattern never changes; the destination does. You get scan analytics as a side effect. The catch is honest and worth stating: a dynamic code stops redirecting if the account behind it lapses, so it needs an active plan for as long as the printed material is in circulation.

Practical rule: if the destination is genuinely permanent — your homepage, a WiFi network, a booking link you have used for five years — static is fine and free. If it is a menu with prices, use dynamic. Menus change more than owners expect. See editable menu prices for the version-control side of this.

The page behind the code

Most bad QR menus are bad web pages, not bad codes.

No PDFs. A PDF forces pinch-zoom on a 6-inch screen, often opens in a separate viewer, and is typically 2-8 MB on a phone that is already fighting your dining-room walls for signal. Use a mobile web page.
Under two seconds to first readable text. Compress dish photos to roughly 100 KB each and load them lazily. A guest who is hungry will not wait through a hero video.
No login, no app download, no mandatory email. Every gate costs you scans, and a menu behind a signup form generates complaints, not newsletter subscribers.
Body text at 16px minimum, categories collapsible, prices right-aligned and unambiguous with the currency.
Mark sold-out items on the page rather than letting servers apologise twelve times a night.

If you want a template for structure and copy, the restaurant menu page walks through the layout that converts best.

Allergens: the part worth getting right

A digital menu is a good place for allergen information precisely because you can correct it the same afternoon your supplier changes a stock cube. Some ground rules that hold up in practice:

In the EU, Regulation 1169/2011 requires information on the 14 declarable allergens to be available to the customer before they order. Rules differ by country and change; confirm your local obligations rather than trusting a blog, including this one.
Write allergens per dish in words, not as a legend of eight ambiguous icons. Nobody memorises your icon key.
Do not make the digital menu the only route. A guest with a dead battery, no data, or no smartphone still has the right to that information. Keep a small number of printed menus behind the bar and make sure staff know where they are. This single habit prevents most of the one-star reviews QR menus attract.
Date-stamp the page (for example, Updated 14 August 2026). It signals care and it helps you internally when someone asks whether the change went live.
Be plain about cross-contamination. A short line about a shared fryer is more useful and more defensible than silence.

Order-at-table: when it pays and when it costs you

Ordering through the QR code is a genuinely different product from a QR menu, and it is not universally a win.

It tends to pay off in high-volume, low-complexity service: cafés, beer gardens, pool and beach bars, food halls, anywhere guests order in several small rounds and waiting for a server is the bottleneck. Second-round drink orders are where the revenue actually shows up.

It tends to cost you where the server is the upsell — tasting menus, wine-led restaurants, anywhere the recommendation is the product. It also quietly costs you payment processing fees on every ticket and adds a failure mode: if the kitchen printer integration drops, orders vanish into a browser tab.

Two operational details decide whether it works: a unique code per table (one shared code means guessed table numbers and food at the wrong table) and a visible fallback to call a server. If you go this route, keep table numbers physically printed next to the code so a guest can correct a mistake.

Printing and placement

Boring, and it decides everything.

Size to distance. Rule of thumb: the code scans reliably from about 10x its own width. Table tent read at arm's length: 3-4 cm (1.2-1.6 in) minimum, never below 2 cm. Window decal read from the pavement at 2 m: 15-20 cm.
Quiet zone. Leave blank margin equal to four modules (four of the little squares) on all sides. Menus that fail to scan are usually cropped too tight.
Print from vector (SVG or PDF) at 300 dpi. An upscaled screenshot produces fuzzy module edges and intermittent scans.
Dark code on light background. Inverted codes fail on a meaningful share of older phone cameras.
Matte lamination, not glossy. Glare from a spotlight over table 6 is a real and very annoying failure mode.
Logo in the middle: keep it under about 20% of the code area and use high error correction.
Print the short URL underneath in small text. It costs nothing and rescues the guest whose camera app is misbehaving.
Placement: tent card facing the guest, not the wall; not under the condiment tray; a duplicate at the entrance so people can read the menu before they sit down.

Updating without reprinting

This is the whole argument for dynamic codes, and it is more mundane than it sounds. With the same printed cards you can point the code at a lunch menu from 12:00 to 15:00 and an evening menu after that, swap in a Christmas set menu for three weeks, push a price change the day it takes effect, or redirect to a holiday-hours notice while you are closed.

Scan analytics tell you things you cannot see from the floor: how many people scan at the entrance versus at the table, whether the window decal earns its space, which hour your menu page peaks. If the entrance code gets 40 scans a day and converts nobody, that is a menu problem, not a marketing problem.

One discipline: keep a single source of truth for the destination URL and never let two generations of stickers coexist pointing at different places.

Mistakes worth avoiding

Linking to a Facebook or Instagram page instead of a menu. Guests want prices, not your reel.
Testing only on your own phone. Test on at least one iPhone and one Android, in the actual lighting of the room, at the actual table distance.
Adding six different codes to one tent card. Two is the practical maximum before guests scan none of them.
Using a free static code for prices, then reprinting 80 laminated cards in March.
Forgetting the WiFi. In a basement dining room with one bar of signal, the menu will not load at all — put the network credentials next to the menu code with a WiFi QR code.

A 20-minute launch checklist

Menu lives on a mobile web page, not a PDF, with prices and allergens per dish.
Decide static or dynamic, honestly, based on how often prices move.
Generate the code, export as SVG, print a single test card.
Scan it from three tables, in evening light, on two phones.
Check the quiet zone and the short URL underneath.
Print the run, matte finish, table tents plus one entrance decal.
Brief the staff: where the printed menus are, and what to do if a guest cannot scan.
Check scan counts after one week and move the codes that nobody uses.

Make yours

You can generate a static QR code for your menu URL free on the homepage generator — no account, PNG download, fine for a permanent link. If your prices or seasonal menus move and you would rather not reprint, the dynamic codes on pricing let you change the destination behind cards that are already on the tables, and show you how often each one gets scanned.