What people actually hated in 2021, itemised
The complaint was almost never "I object to scanning a code". Read the 2021 coverage again and the same four things sit underneath it.
- The code opened a PDF — a document laid out for A4 paper, rendered on a screen 6cm wide, pinched and dragged one column at a time.
- There were no photos and no descriptions, because the PDF was the print file, and the print file was designed to be read at arm's length rather than tapped.
- Some codes wanted an app, or an email address, or a table number typed in before the menu would appear.
- A meaningful number of codes were simply broken: a dead link, a menu from two seasons ago, or a printed code that had been regenerated since.
Those are four different failures and only the last is about QR codes at all. The first two are a file-format decision. The third is a decision to collect something from a guest who came in for lunch.
The distinction predicts what happens next. A backlash against a technology does not subside when the technology improves. A backlash against PDFs does.
The survey numbers, and why none appear here
Search this question and you will find confident percentages: some share of diners prefers scanning, some share wants paper back. They are quoted everywhere, usually without a link.
Follow them to the source and the pattern is consistent. The favourable ones were published by companies selling digital menus. The unfavourable ones came from print suppliers or a trade body reporting a members' poll. Sample sizes and question wording are usually missing, and the wording is where the entire result lives — "would you rather scan a code or be handed a menu?" and "would you rather scan a code or wait for someone to bring one?" are different questions, and they do not get the same answer.
The answerable version of the question is not what diners say in the abstract. It is what your diners do in your room, which you can measure directly — see qr menu analytics.
The three failures that still produce complaints
Most of the 2021 problems were solved by not using a PDF. These were not, and they are the ones guests still notice.
The menu is slow, or blank, on a bad connection
Restaurants are often bad radio environments: basements, stone walls, a wifi login nobody can complete. A menu that needs several seconds and a working JavaScript bundle before anything appears fails hardest for the guest with the oldest phone and the weakest signal. That guest tells the table the QR menu is broken, and they are right.
Something stands between the code and the food
A cookie banner, a language picker, a newsletter modal, a table-number prompt. Each is defensible alone and each is a wall between a hungry person and a list of dishes. The menu should be the first thing on the screen.
The printed code has drifted from the live menu
This is the failure a static code makes permanent: the code is printed, the URL behind it is fixed, and on the day that URL changes every table tent in the building is wrong. A dynamic code moves the destination without a reprint, which is the whole of the argument in static vs dynamic qr code menu.
Where a QR menu is genuinely the wrong choice
Some rooms should not run a QR-first menu, and the honest answer to an owner in one of them is to say so.
| Situation | Why it goes badly | What to do instead |
|---|---|---|
| Fine dining, tasting menus | The service is the product. Handing someone a phone task downgrades the thing they are paying for. | Printed menu, with a code as the secondary route for allergens and wine detail. |
| Guests skew significantly older | Not incapacity — unfamiliarity, and a reluctance to fumble with a phone in front of company. | Paper as the default, offered first. The code stays available. |
| Basements, thick walls, no usable wifi | The menu cannot load, and no amount of design fixes physics. | Fix the signal or keep paper. Do not ship a menu that needs a network the room does not have. |
| Loud bars, standing service | Reading a phone at a crowded bar is worse than reading a board. | A board or a short card. The code earns its place for the full list. |
The pattern across all four: a QR menu is wrong wherever the phone is a worse reading surface than the alternative in that specific room. That is a question about the room, not about the year.
What a competent implementation looks like in 2026
If you are going to run one, the bar is well established by now. None of it is novel and all of it is checkable in an afternoon.
- A real HTML page rather than a PDF or a photograph of a menu: text that reflows, enlarges, and can be read aloud.
- No app, no login, no email address, no table number required before the food is visible.
- A dynamic code, so the destination can be corrected without reprinting anything.
- Photos on the dishes that benefit and descriptions on the dishes that need them — the two things paper usually cannot afford.
- Allergen and dietary information attached to items rather than printed as a footnote nobody reads.
- Printed menus kept in reserve and offered without being asked twice.
The photos and the allergen detail are the part worth dwelling on, because they are the only entries on that list a paper menu cannot match at any budget. A QR menu that merely reproduces the paper one has taken on all of the format's costs and none of its advantages.
The paper-menu question, answered honestly
Operators ask whether keeping printed menus means the QR menu has failed. It does not, and the framing is the mistake.
Common practice is a code on every table and a small number of printed copies behind the counter, offered to anyone who wants one. That is not a hedge. It is the same logic as keeping a card terminal and a cash drawer.
Two things go wrong with the reserve. The copies drift, because the digital menu changes the moment someone edits a price and the laminated ones in the drawer do not — and nobody notices until a guest is charged something other than what they read. And the reserve quietly runs out, because three copies that were plenty in February do not survive a coach party in August.
How to tell whether your own guests are struggling
You do not need a survey. Your own room answers this in a week.
- Ask the floor staff how often they fetch a paper menu, and for whom. They already know, and nobody has asked them.
- Compare scans against covers for the same service. A gap is not automatically bad — one scan often serves a table of four — but a gap that widens over a month is worth explaining.
- Load your own menu on the worst phone in the building, standing at the worst table, with wifi off.
- Watch one table you do not know scan the code, without helping. The point where they hesitate is the fix.
- Read the language mix in your scan data. A tourist venue whose guests are all reading in one language has a translation problem, not a QR problem.
Step four costs nothing and finds more than the other four together. What it usually finds is not the code — it is the second tap, where the guest cannot work out how to get from the landing screen to the mains.
For the guests this format leaves out altogether, and what to do for them, see qr code menu accessibility. For how the platforms differ on the failures above, see best qr code menu software.