QR code menus for restaurants: the agency guide to doing it right

QR code menus went from a pandemic workaround to a permanent fixture, and most of them are done badly. A blurry photo of the paper menu, an app you have to download before you can read the starters, a tracking script that quietly logs where you are: this is the version diners have learned to resent. It does not have to be that way. Done well, a QR menu is faster than paper, instantly updatable, and genuinely useful. Done badly, it annoys the customer and exposes the restaurant to accessibility and privacy complaints.

This is the guide for agencies setting up QR menus for hospitality clients. We will cover the first decision that changes everything (view-only or order-and-pay), why the menu has to be dynamic, the single technical choice that makes or breaks accessibility, the privacy line you should not cross, and how to place and measure the codes so the restaurant actually benefits.

View-only menu or order-and-pay? Decide this first

"QR code menu" hides two very different products, and picking the wrong one wastes the client's money.

A view-only menu simply shows the menu on the diner's phone. The customer scans, reads, then orders from a server as usual. It is cheap, quick to build, needs no integration with the kitchen or payments, and it is what most restaurants actually want. The whole job is a well-made mobile web page behind a code.

An order-and-pay menu lets the diner browse, add items to a basket, send the order to the kitchen, and pay from the table. It can lift average spend and cut staff load, but it is a real software project: point-of-sale integration, payment processing, table mapping, and staff training. It is a hospitality-tech decision, not a print job.

Be explicit with the client about which one they are buying. Most briefs that say "we want a QR menu" mean view-only, and selling them an order-and-pay build they do not need is how a simple win becomes a stalled project. The rest of this guide focuses on the view-only menu, because that is the common case and the part an agency owns end to end.

Why the menu must be dynamic

The reason QR beats paper is not the code, it is what the code points to. A printed menu is frozen the moment it leaves the press. A QR menu can change its content while the printed code on the table stays exactly the same.

That is only true if you build it on a dynamic QR code, where the code encodes a short, fixed redirect and the destination is editable. With that in place, the restaurant can update prices the day they change, pull a sold-out dish ("86 the salmon") in seconds, run a seasonal menu, or swap to a brunch menu in the morning and dinner at night, all without reprinting a single table tent. You can change the destination without reprinting as often as the kitchen needs. A static code that hard-codes a single menu URL throws this entire advantage away, so this is the one non-negotiable of the build.

Link to a web page, not a PDF or an image

Here is the mistake that ruins more QR menus than any other: pointing the code at a photo of the paper menu or a PDF. It feels quick, and it breaks the experience for everyone.

What a good table setup looks like:

1. The code, printed large enough to scan at arm's length, with a clear quiet-zone margin around it.
2. A short plain-text URL and a "scan for the menu" label beside it, so anyone who cannot scan still has a way in.
3. It opens a mobile-friendly web menu made of real text, not a photo or a PDF.
4. A paper menu stays available on request, so the code is never the only way to see what is on offer.

A JPEG or a flattened PDF is just a picture of text. On a phone it means pinch-zooming around a tiny document, and for anyone using a screen reader it is silence: assistive software cannot read words that are baked into an image. A real HTML menu page, by contrast, reflows to the screen, lets people change text size, and can be read aloud. It is also the version you can actually update and measure. Treat the menu as what it is, a mobile landing page whose only job is to present the food clearly and load fast.

Accessibility is not optional

A menu is core information, and a restaurant has to give everyone equivalent access to it. The US government's own Section 508 guidance on QR codes is a good, concrete checklist, and it applies just as well to a menu:

• Provide an alternative way in. Print a short URL and, ideally, a phone number alongside the code, so a diner who cannot or will not scan can still reach the menu. Section 508 explicitly recommends including a URL in print media next to the code.
• Label the code clearly. "Scan with your phone's camera for our menu" sets expectations and doubles as a usability win.
• Keep strong contrast. Dark code on a light background, meeting at least a 4.5:1 contrast ratio, the same WCAG threshold used for text.
• Make the destination accessible too. A code that opens an inaccessible page has just moved the barrier, not removed it. The menu page needs real text, proper headings, and alt text on any dish images.
• Keep paper menus on hand. The simplest equivalent-access guarantee is a stack of printed menus for anyone who asks, with no fuss.

None of this is exotic, and most of it overlaps with plain good design. The broader principles are worth a read in our piece on QR code accessibility. The headline rule: never let the QR code be the only way to see the menu.

Do not make diners pay with their data

The other reason QR menus earned a bad reputation is surveillance. Reporting by the ACLU and others has documented that many third-party QR-menu providers collect and share personal data, from location to demographics to ordering behaviour, often with no clear way for the diner to opt out. A customer came in for dinner, not to join a marketing database.

Build the client's menu to the opposite standard:

• Do not require an app, an account, or an email address just to read the menu. That is the single most resented pattern, and it is unnecessary for a view-only menu.
• Minimise data collection. Counting anonymous scans to understand traffic is reasonable and proportionate. Quietly harvesting personal data to retarget diners later is not.
• Be transparent and lawful. Any tracking has to respect privacy law; what a scan does and does not collect is exactly the question covered in are QR codes GDPR-compliant. Keeping the menu itself free of personal-data collection makes that whole problem small.

A menu that respects the diner's privacy is not just ethical, it is better marketing: it is the difference between a tool people are happy to use and one they grumble about.

Placement, print and getting people to scan

A QR menu only works if diners actually scan it, and that is mostly about placement and a clear ask.

Put a code on every table, on a sturdy, laminated stand or a sticker that survives wiping down. Size it for arm's length: comfortably scannable from a seated position without anyone leaning across the table. Keep the quiet zone clear and the contrast high, the same fundamentals from how big should a QR code be. And always tell people what the code is for. A bare code gets ignored; a code with "Scan here for our menu and today's specials" gets used. Explaining the purpose is the cheapest scan-rate boost there is, and it doubles as the accessibility label you needed anyway.

One practical tip: a distinct code per table, or at least per area, costs nothing to generate and tells the restaurant far more than a single shared code. Which brings us to measurement.

Make it measurable, and ready for multiple sites

Because the menu lives behind a trackable code, the restaurant can finally see how it is used. With dynamic codes you can watch scans by day and hour to see genuine peak times, compare locations for a group, and gauge how many diners reach for the digital menu at all. Be honest about the limits: scans tell you reach and timing, not who someone is, and that is exactly the boundary you want to keep. The same disciplined reporting from our scan analytics guide applies here.

For a chain or a multi-location client, generate a separate code per venue (and per table if you want that granularity) in one pass with bulk QR generation, each pointing at that site's menu. One design, many codes, clean per-location numbers, and every menu still editable on the day.

A launch checklist for a QR menu

Before a client's QR menu goes live:

1. Scope agreed: view-only or order-and-pay, with the client clear on which they are buying.
2. Built on a dynamic code so the menu can change without reprinting.
3. Destination is a mobile-friendly web page, not a JPEG or PDF.
4. An alternative way in: a short printed URL (and phone number) beside every code.
5. Accessible end to end: descriptive label, 4.5:1 contrast, real text on the menu page, paper menus on request.
6. Privacy-respecting: no forced app or login, minimal data, lawful tracking.
7. Placed and labelled on every table with a clear "scan for the menu" prompt.
8. Trackable, ideally per location or table, with a baseline noted so you can show usage.

Frequently asked questions

How do I make a QR code menu for a restaurant?

Build a mobile-friendly web page with the menu, generate a dynamic QR code that points to it, and print that code on table stands or stickers with a short URL and a "scan for menu" label beside it. Use a dynamic code so you can update dishes and prices later without reprinting. Keep paper menus available for anyone who needs one.

Should a QR menu link to a PDF or a website?

A website. A PDF or an image of the menu is hard to read on a phone and impossible for screen readers, since the text is locked inside a picture. A real web page reflows to the screen, can be read aloud, resizes cleanly, and is the only version you can update and measure.

Are QR code menus accessible and ADA compliant?

Only if you design them to be. Provide an alternative way to reach the menu (a printed URL and phone number), label the code clearly, keep strong contrast, make the menu page itself screen-reader friendly with real text, and keep paper menus on request. The QR code must never be the only way to see the menu.

Do I still need paper menus?

Yes, keep some on hand. They are the simplest way to guarantee equivalent access for diners who cannot or prefer not to scan, and they are your fallback if a phone is out of battery or the network is slow. The QR menu is an addition, not a full replacement.

Can I update a QR menu without reprinting the code?

Yes, if it is built on a dynamic code. The printed code stays the same while you edit the menu it points to, so you can change prices, remove sold-out dishes, or swap menus by time of day instantly. A static code that encodes the menu URL directly cannot do this.

Do QR code menus track customers?

Some do, more than diners realise. Many third-party providers collect location, device and behavioural data and may share it. A well-built menu counts anonymous scans for traffic insight and nothing more, never requires an app or login to read the menu, and complies with privacy law.

How much does a QR code menu cost?

The code itself is trivial; the cost is the menu page and, if you go that route, the ordering and payment system behind it. A view-only menu is inexpensive to build and maintain. An order-and-pay system is a larger investment with point-of-sale and payment integration, so decide which you need before budgeting.

The short version

A good QR menu is a fast, current, accessible web page behind a code, not a photo of a laminated card. Decide first whether the client needs a simple view-only menu or a full order-and-pay system, then build it on a dynamic code so the kitchen can change dishes and prices without ever reprinting. Point the code at a real mobile web page, never a PDF or image, and make it accessible: a printed URL alongside, clear labelling, strong contrast, real text, and paper menus still on offer.

Respect the diner by collecting no more than anonymous scans, never forcing an app or login. Place a labelled code on every table, tell people what it is for, and track scans by location and time so the restaurant can see what is working. Set those foundations and a QR menu stops being the thing diners tolerate and becomes the thing that genuinely makes service quicker. Build your client's next menu on a dynamic, trackable, accessible page, and it will still be right a year of specials from now.