What a QR code menu is, and what it is not
A QR code menu is a printed square that opens your menu in a guest's phone browser. There is no app to install and nothing for the guest to sign up for. They point a camera at a table tent, a page loads, they read it.
It is worth separating this from two things it gets confused with, because both confusions lead people to buy the wrong product.
It is not a digital menu board
Search for "digital menu" and most of what comes back is signage: wall-mounted screens behind a counter, a media player, a subscription to push content to them. That is a fit-out decision with a hardware budget, and it solves a different problem -- what a queue looks at while it waits. A QR menu solves what a seated guest reads. Some venues want both. They are not substitutes.
It is not a PDF on a link
The fastest way to get a QR menu live is to upload your existing PDF and generate a code pointing at it. It is also the single decision most responsible for people disliking QR menus. A PDF is a page-shaped document on a phone-shaped screen: the guest pinches, zooms, drags sideways, loses their place, and gives up. It cannot be read by a screen reader, cannot be searched by Google, and cannot show a guest only the vegetarian dishes.
A menu built as a real web page can do all three. That difference runs through the rest of this guide.
The one decision that cannot be undone
A static QR code contains the destination inside the pattern itself. Change the destination and you have a different code, which means new artwork, a new print run, and someone walking the floor swapping table tents.
A dynamic QR code contains a short redirect URL that the platform controls. The printed square never changes. What sits at the other end of it can change every day.
This sounds like a technical detail and is actually the whole economic argument. Work out what a reprint costs you: artwork, printing, laminating or mounting, and the hour of someone's shift spent replacing them. Multiply by the number of times a year a supplier price moves, a dish is dropped, or a season changes. That number is what a static code costs you, and you pay it every time.
Dynamic codes have a second, quieter advantage. Because they encode a short URL rather than a long one, the pattern is less dense, which makes the code faster and more reliable to scan at small print sizes and in poor light. A dining room is exactly where that matters.
There is one case where static still wins: a one-off event with a destination that will never move, where nobody will ever need scan counts. For a restaurant, that case almost never comes up.
What guests actually think in 2026
QR menus arrived in most dining rooms in 2020 for a reason that has since gone away, and a lot of the early implementations were bad. It is worth being precise about what people objected to, because the complaints were specific and most of them are fixable.
- The menu was a PDF that had to be pinched and dragged.
- The link was dead, or pointed at last season's menu.
- The page demanded an app install, an email address, or a table number before showing a single dish.
- There was no paper alternative for anyone who could not or would not scan.
Survey data since then has been consistently more positive, though it is worth knowing where the numbers come from. A figure widely quoted in the industry -- 78% of respondents preferring QR menus to paper -- traces to an Eater reader survey, and a 67% preference figure is attributed to a 2025 National Restaurant Association study. Both are usually repeated on vendor blogs rather than linked to the primary source. Treat them as directional evidence that the objection has softened, not as measurements of your dining room.
The honest summary: guests stopped objecting to the idea and kept objecting to bad execution. The full survey picture is in a separate post, and the guests who genuinely cannot scan are covered in QR menu accessibility.
Getting the code onto the table
Print is where a good menu quietly fails. The rule that governs everything: a QR code scans reliably from roughly ten times its own width. Take the distance a guest will scan from, divide by ten, and that is your minimum size.
A seated diner is about 30 to 50cm from a table tent, which puts the code at 4 to 5cm (1.5 to 2 inches) square. A window decal read from the pavement needs to be far bigger than most people assume.
- Print from vector (SVG or PDF) wherever possible, or a PNG at 1000x1000px and above. 300dpi minimum.
- Keep contrast high. A gradient-filled code in brand colours photographs beautifully and fails at dinner service.
- Prefer matte over gloss. A gloss laminate under a downlight bounces the light straight back into the camera.
- Put words under it. "Scan for our menu" measurably outperforms a bare square.
Then test before you commit to a print run: two phone platforms, one older handset, one cracked screen if you can find one, in the actual lighting of the actual room, from a seated position. The full print guide covers sizing by placement, material, and the test protocol.
What the law expects from a menu
This section is a map, not advice. The rules differ by market and the thresholds move.
European Union and United Kingdom
Regulation (EU) No 1169/2011 requires information about 14 named allergens for non-prepacked food, which includes what a restaurant serves at a table. Since December 2016 it has not been enough to answer verbally on request: the information has to be available in writing. The 14 allergens, and what "in writing" permits goes through the detail.
United States
There is no nationwide rule requiring every US restaurant to print allergens next to every dish. California changed the picture for larger operators: the Allergen Disclosure for Dining Experiences (ADDE) Act, SB-68, took effect on 1 July 2026 and requires chains with 20 or more locations nationally to disclose the Top 9 allergens on their menus. Notably, it permits doing this in a digital format such as a QR code, provided a print option is also offered. What the ADDE Act actually requires unpacks it.
Separately, the FDA menu labeling rule requires calorie information on menus and menu boards at establishments with 20 or more locations doing business under the same name with substantially the same menu items, plus fuller nutrition information on request.
What you can measure afterwards
A dynamic code records every scan. That is genuinely useful and routinely oversold, so it is worth being clear about both halves.
| You can see | You cannot see |
|---|---|
| How many scans happened, and when | How many people were at the table |
| Which language guests switched to | Whether they understood the dish |
| Which items got opened or viewed | What they actually ordered |
| Which day and hour scanning peaks | Whether the menu caused the sale |
The language column is the most immediately actionable number a tourist venue can get: it tells you which language to add next, from evidence rather than assumption. The item-view data is the most interesting and the easiest to over-read. What QR menu analytics can and cannot tell you goes further, and menu engineering with digital menu data covers what to do with it.
The menu as a search asset
One consequence of building the menu as a real web page rather than a PDF: search engines can read it. People search for "[restaurant name] menu" constantly, and for dishes by name, and a PDF answers neither query well.
A menu published as HTML, with structured data describing the venue and its dishes, can be indexed and can be the thing a guest finds before they arrive. It is also what belongs in the menu field of a Google Business Profile. Restaurant menu SEO covers what to point where.
What it costs, honestly
Nobody publishes a straight answer to this, so here is the shape of it.
There are three costs and only one of them is the subscription.
| Cost | Typical shape | Frequency |
|---|---|---|
| Platform subscription | A monthly or annual fee, usually per location | Ongoing |
| Getting the menu in | Hours of someone's time, or a one-off import | Once, then small edits |
| Table tents, stickers, window decals, mounting | Once with a dynamic code |
The second line is the one people underestimate and the one that decides whether the project succeeds. Typing a hundred items with descriptions, prices, allergens, and dietary flags is a real afternoon. An import from a photo or a PDF shortens it, but the output is a draft: names and prices come through reliably, descriptions and anything allergen-related need a person.
The third line is where a static code quietly becomes expensive. Print is a one-off only if the code outlives the menu. Price it as a recurring cost if you are considering a static code, because that is what it is.
Free tiers exist and are genuinely usable for a single small venue. What they typically drop is the thing that matters most at scale: more than one location, more than one language, or a code that stays yours if you stop paying. Read what happens to your printed code at the end of a free plan before you print two hundred of them.
Briefing the floor
A QR menu is a service change, not a software purchase, and the most common reason one fails has nothing to do with the software.
If the floor staff are not briefed, one of two things happens. Either they keep handing out paper by default and the whole thing quietly does not launch, or they treat the code as the only option and a guest who cannot use it has an awkward two minutes.
What a brief needs to cover, and it is short:
- Where the paper menus are kept, and that offering one is normal rather than a failure.
- How to answer "is there an app?" -- there is not, it opens in the browser.
- What to do when a phone will not scan: hand over paper, do not troubleshoot the guest's phone at the table.
- Who changes a price, and how fast it appears. Servers who know a sold-out item can be marked in seconds stop apologising for the menu.
- That allergen information on screen is the restaurant's own data, so the kitchen still owns the answer to a specific question.
The last point matters more than it looks. A digital menu that lists allergens can create the impression that the question is fully answered and nobody needs to ask the kitchen. For a guest with a serious allergy that impression is dangerous, and the correction belongs with the staff, not in a footnote.
The guests a QR code leaves behind
Some guests cannot scan. Some can and would rather not. Neither group is large enough to abandon the format and both are large enough that ignoring them is a service failure.
- No smartphone, a dead battery, or no data allowance in a basement dining room.
- Low vision, where a screen reader needs real text rather than an image of text.
- Motor difficulty holding a phone steady enough to focus on a small square.
- A guest who simply does not want to look at a phone over dinner, which is a legitimate preference.
The standard answer, and the right one, is to keep a few printed menus behind the counter and to have staff offer one without making a performance of it. Common practice is a code on every table plus three to five paper copies in reserve. In California, where digital allergen disclosure is permitted, offering a print option is not just courtesy -- it is a condition of the allowance.
A launch checklist
- Build the menu as structured items, not as an uploaded PDF or photograph.
- Choose a dynamic code so the printed square outlives the menu behind it.
- Enter allergen and dietary information per item, and review every AI-drafted value before it is published.
- Add a second language only if your guest mix justifies it, and keep dish names in the original.
- Size the code for the scan distance, print from vector, and label it in words.
- Test on two phone platforms, in the real room, from a seated position, before the print run.
- Keep printed menus in reserve and tell the floor staff they exist.
- Point your Google Business Profile menu link at the live menu page.
- Wait a month, then look at scan times and language mix before changing anything.
The order matters more than the speed. Almost every expensive mistake in this list is a print decision made before a data decision. Start with how to create the menu itself.