How to create a QR code menu for your restaurant — the GDPR-safe way
4 July 2026 · 6 min read
The laminated menu on table six has a wine stain on the pasta section that's been there since March. The edges have curled. Someone's crossed out "£14" and written "£16" in biro, twice. Every owner knows this menu. Replacing it with a QR code sounds like the obvious fix — until you remember the last time you heard about QR menus, which was probably 2021, in a story about restaurants nobody liked.
The technology's moved on since then, and so has the reason to use it. Done properly, a QR code menu saves you reprinting costs, lets you fix a typo or swap out a sold-out dish in seconds, and — if you're in the UK or EU — it can be done in a way that's genuinely privacy-friendly rather than a quiet data-harvesting exercise. Done badly, it's a slow-loading PDF that annoys your regulars and quietly puts you on the wrong side of GDPR. This guide covers both: how to build one that works, and how to make sure it's legal.
Why bother — and when not to
The case for a QR menu isn't really about being "modern." It's about the boring stuff that eats your week: reprinting every time a dish changes, laminating replacements, briefing new staff on what's actually in stock today versus what the menu still claims is available. A dynamic menu fixes all of that. Change the wine list on Monday morning from your phone; it's live before the doors open.
It also helps with the awkward moments — the guest with poor eyesight who can't read 8pt font on a paper card can zoom in on their phone. Someone unsure about allergens can read the full ingredient list instead of flagging down a waiter mid-rush. None of that is revolutionary, but it adds up over a service.
Now the honest bit, because most articles on this skip it: not every customer wants to scan a code. Older guests especially will sometimes just ask for a paper menu, and you should have a few on hand — don't make anyone feel excluded because their phone's playing up or the pub's WiFi is patchy. A code only works if it loads fast; if your guest is stuck watching a spinner on 1-bar 4G, you've made things worse, not better. And a QR code won't rescue a bad menu or an off night — it's a convenience layer, not a marketing miracle.
Static vs dynamic: the difference that actually matters
Most people who've tried a free QR generator and been unimpressed hit the same wall: they made a static code. A static QR code has the destination baked directly into the pattern — usually a link straight to a PDF sat somewhere on your website. It works, but if you need to change the menu, you're printing a new code and binning the old table talkers.
A dynamic QR code points to a short link that you control behind the scenes. Scan it in January and it takes you to the winter menu; scan the same physical code in June and it's already updated to summer. You print the code once — on a card, a sticker, a wooden stand — and never touch it again, even as the menu itself changes weekly. Most free generators only do static codes, which is exactly why they feel like a false economy the first time you need to update anything.
How to actually build one: five steps
Get your menu into a mobile-friendly format. Not a scanned PDF that requires pinch-zooming — a proper mobile page or a clean, readable PDF with dietary and allergen info included. This is the part people skip and then wonder why nobody uses the code.
Choose a QR platform that's built for this, not a generic generator. Look for one that gives you dynamic codes, doesn't quietly log more about your customers than it needs to, and is upfront about where your data lives (more on this below). Qrius.io is built exactly for this — free to start.
Create the code and point it at your menu link. Give it a sensible name so future-you can find it again ("Front Bar Menu," not "QR1").
Test it properly, on real phones. Both iOS and Android, on ordinary mobile data rather than your office WiFi. If it takes more than a couple of seconds to load, fix that before it goes anywhere near a table.
Print once, place it, and leave the link alone. Any future menu changes happen at the destination — the code on the table never needs reprinting again.
That's genuinely the whole process. Most owners have it live within about ten minutes once the menu itself is ready.
The GDPR angle — the part most guides gloss over
Here's what actually happens when someone scans a QR code: their phone opens a link, and that request typically carries the visitor's IP address, device type, and a timestamp. Depending on the service, it might log the approximate location too. Under GDPR (and the UK's Data Protection Act 2018), an IP address is personal data. That means a scan isn't a neutral, anonymous event — and as the restaurant that put the code on the table, you're the data controller. Not your web developer, not the QR vendor. You.
This matters more than it sounds, because a lot of free QR generators are built by companies based outside the EU/UK, hosting data on servers wherever's cheapest, with no particular interest in European privacy law. If that service logs raw IP addresses and stores them on a server in the US with no proper safeguards, you've potentially got an unlawful international data transfer happening every time a customer looks at your specials board. That's not a hypothetical you can shrug off — it's your name on the till receipt.
What to actually look for in a QR provider:
- EU hosting. Data physically stored in the EU (Qrius hosts in Stockholm) sidesteps a lot of the transfer-risk headache.
- No raw IP logging. A responsible service doesn't need to keep your customers' exact IP addresses to tell you how many people scanned the lunch menu.
- A Data Processing Agreement (DPA). This is the paperwork that formally makes the vendor your processor under GDPR — ask for it, and if a provider doesn't offer one, that's a red flag, not a technicality.
- A one-line mention in your privacy policy. Honest and brief: "we use QR codes to share our menu; scanning may collect basic technical data via [provider]."
None of this needs a lawyer or a compliance course. It needs picking a provider that's already done the hard part, and being straightforward with customers about what happens when they scan.
Design and placement
Print the code at least 2cm x 2cm — smaller than that and older phone cameras start struggling in dim lighting. Add a short instruction next to it: "Scan for our menu" is enough; don't make people guess what it's for. Put it somewhere obvious — table centre, at eye level near the entrance, or both — rather than tucked behind the cutlery. Test the whole journey yourself on an older phone with mediocre signal before you trust it in front of a full room. And keep a handful of paper menus behind the bar regardless; it costs you nothing and saves an awkward moment for the one table that just wants to read a card.
FAQ
Will customers actually scan it? Most will, if it's obviously placed and clearly labelled — people are used to scanning codes for menus now. Some won't, and that's fine; keep a few paper backups so nobody's left waiting on a phone that won't cooperate.
What if our WiFi is unreliable? Customers usually scan on their own mobile data, not your WiFi, so this matters less than owners assume. What does matter is your menu page loading fast on a weak signal — a lightweight, EU-hosted platform helps here more than people expect.
Do I need to update my privacy policy? Yes, but it doesn't need to be complicated — one honest paragraph explaining that scanning the code may collect basic technical data, and naming the provider, covers it.
Can I see how many people scanned the menu? With a proper dynamic QR platform, yes — scan counts and rough timing, without needing to identify or track individual customers. If a "free" QR tool is offering you detailed visitor profiles, ask yourself where that data's really coming from.
What if I change my menu three times a year? That's precisely what a dynamic code is for. You update the link behind the scenes — the printed code on the table never changes, so there's nothing to reprint.