A QR code menu is a printed square that points a phone at a web page holding your menu. That's the whole mechanism — the code stores a URL and nothing else. Everything that makes diners love or hate the experience happens after the scan, on the page that loads. Which is exactly where most restaurants get it wrong, and why "QR menu" became a complaint in the first place.
The honest verdict, post-pandemic.
QR menus arrived as a hygiene measure and stayed as a cost measure, and plenty of diners resent them — you've read the columns. We won't wave a survey at you, because the pattern is visible from behavior, not polling: nobody complains about a QR menu that loads in a second and reads like it was made for a phone. The resentment is aimed at a specific artifact — the four-megabyte PDF scan of the print menu, loading sideways over patio Wi-Fi while the table waits.
So the verdict is conditional. Diners tolerate QR menus when they're fast and readable, and they punish them when they're not. The technology was never the problem; the implementation was. This guide is about being in the first group, spending nothing to get there, and knowing when it's worth paying to go further.
Why a PDF is the worst option.
The default move — scan the print menu to PDF, upload it, point a QR code at it — is the worst version of this idea, for reasons that compound:
- It's built for paper, rendered on glass. A print layout on a phone means pinch, zoom, and scroll in two directions. Every diner does this dance at every visit, forever.
- It's heavy. A scanned PDF is routinely several megabytes. On a full restaurant's shared connection or one bar of cell signal, that's a long, silent wait — and some diners give up and flag down a server, which was the cost you were trying to save.
- Updates are a production. Changing one price means editing the source file, re-exporting, and re-uploading. So nobody does it, and the PDF drifts out of date — the worst outcome, because a wrong price costs you an argument at the till.
- Phones treat it as a file, not a page. Some open it in a viewer, some download it, some just show a spinner. You don't control the experience at all.
A web page fixes all four at once: it reflows to the screen, it loads in a fraction of the weight, a price change is a thirty-second edit that's live immediately, and every phone knows exactly what to do with it.
Set one up free, in an afternoon.
The generic path, in the order that avoids rework:
- Build a mobile menu page. One column, real text — never photographed pages — with clear sections, prices next to items, and dietary marks where you need them. Any tool that outputs a fast page works; we compared the field in our guide to the best free website builders.
- Generate the QR code. Point it at the menu page's URL. Our free QR code generator does this with no signup, and the code never expires — more on why in a moment.
- Test at table distance. Print one copy, put it where it will live, and scan from a seated position at arm's length, in evening light. Then run the patio test above.
- Print and place. Table tents or laminated cards, one per table, plus one at the door and one at the counter. Label every code "Menu" and print the short URL underneath as a fallback.
Disclosure before the next sentence: Mewayz is our product. The free plan includes the website builder, so the menu page itself costs nothing — free pages carry "Made with Mewayz" branding, and using your own domain or removing the badge is paid. Between that and the free code generator, the honest total for a working QR menu is zero, and we'd rather say so plainly than pretend the free tier is a trial. It isn't; it's the product, with a badge on it.
About the code itself — and "expiring" QR codes.
A static QR code is just your URL drawn as dots. It cannot expire, because there's nothing to expire — the same way a printed street address doesn't stop working. When you hear about QR codes that expired, that's a different product: dynamic codes, which point at a redirect service that points at your page, and which stop working when the subscription does. Redirect services have legitimate uses, but a restaurant menu isn't one of them — you control the destination page anyway, so you can change the menu without changing the code. Use a static code pointed at a URL you own, generate it with the free generator, and the laminated tents you print today work until you choose otherwise.
When to upgrade to ordering.
A QR menu is for reading. The next step up is a code that takes the order: diners browse, order, and pay from the table, and the ticket lands in your workflow. That's what the paid tiers of our Restaurant module do — digital menus with QR codes, online ordering, and table management, one flat fee rather than a per-order cut. The details live at Mewayz for restaurants and on the pricing page.
Our honest advice on timing, though, is to wait until two things are true. First, the free menu page has been live for a few weeks and diners are actually scanning it — the measurement section below tells you. Second, table ordering genuinely fits your service. It shines for counter service, high-turnover casual spots, and anywhere order-taking is the bottleneck; it fits badly where the server's recommendation is part of what you sell. Upgrading because the button was there is how restaurants end up resenting their software. Start free, watch the scans, then decide.
Design rules that decide whether anyone scans.
Most QR menu failures happen at the table, not on the page. The rules are short:
- Dark code on a light background. Inverted codes — light dots on dark — fail on a meaningful share of camera apps. If your brand is dark, put the code in a white box.
- Size for the distance. The working rule of thumb: code width of about one-tenth the scanning distance. Arm's length on a table means at least 2×2 cm; a poster read from across the room needs to be dramatically bigger.
- Keep the quiet zone. The white margin around the code is part of the code. Don't crowd it with borders or text.
- Label it "Menu." An unlabeled QR square is indistinguishable from an ad or a scam sticker, and diners have learned caution. One word above the code changes the scan rate.
- Print the URL under it. A short readable address is the fallback for the diner who won't scan — and there's one at most tables.
- Laminate flat, mind the glare. Curved, creased, or glossy-under-spotlights codes scan badly. Matte lamination on a flat tent is the boring, correct answer.
- Keep a few paper menus. A printed fallback for the diner with a dead battery, no data, or no patience isn't a retreat — it's hospitality. The QR code is an option you offer, not a gate you enforce.
Measure it.
A QR code has no analytics of its own, but the page it opens does — you just have to make scans distinguishable from other visits. Point the code at your menu URL with UTM parameters attached: ?utm_source=qr&utm_medium=table. Generate separate codes for separate placements — utm_content=table, utm_content=window, utm_content=receipt — and any analytics on the page (Mewayz pages include them; so do most builders) will show you scans by location. Two questions this answers within a month: whether diners actually use the thing, which tells you if table ordering is worth paying for; and whether the code in the window converts passers-by, which tells you if it deserves better placement. You're no longer guessing, which puts you ahead of nearly everyone who printed a code and hoped.
FAQ
Are QR code menus really free?
The reading version, yes: a static QR code costs nothing to generate and never expires, and the menu page can be built on a free plan — Mewayz's free website builder works, with "Made with Mewayz" branding on the page. What costs money is the next tier: online ordering, table management, and a custom domain.
Do QR codes expire?
Static codes never expire — the code is just your URL drawn as dots. Codes that "expire" are dynamic codes from redirect services, which die when the subscription does. For a menu, use a static code pointed at a page you control; you can change the menu anytime without reprinting.
Do diners still use QR menus in 2026?
Yes — when they're fast and readable. The backlash is aimed at slow, zoom-and-scroll PDF menus, not at the format. A light web page that loads in a second draws few complaints, and keeping a handful of paper menus covers everyone else.
Should my QR menu be a PDF?
No. A PDF is built for paper: it forces pinch-and-zoom, loads slowly on restaurant connections, behaves inconsistently across phones, and makes price updates a chore, so they don't happen. A mobile web page fixes all four and costs nothing to build.
How big should the QR code be on a table?
Rule of thumb: code width of about one-tenth the scanning distance. For a seated diner at arm's length, print at least 2×2 cm, keep the white quiet zone around the code, use dark-on-light, and label it "Menu" with the URL printed underneath.
The afternoon, summarized.
Build a one-column menu page with real text. Point a static code at it with UTM tags. Run the patio test. Print matte tents labelled "Menu" with the URL underneath, and keep some paper menus by the till. Total cost: an afternoon. Then let the scan numbers — not a sales page, including ours — tell you whether table ordering is the next move. When it is, the Restaurant module will be there, and everything else a restaurant runs on — the rest of the 150+ modules — comes on the same flat fee. Start free and have the menu live by dinner service.