QR code menus for restaurants

A small bistro in Austin reprinted laminated table cards four times in fourteen months. Two staff turnovers, a beverage supplier change, a partial menu redesign, and a holiday brunch promotion. Each reprint cost about $180 in design time plus another $90 in printing and the awkward week where half the tables had the old cards and half had the new ones. That is not a QR code story. That is a printing budget story — and it is exactly the kind of slow bleed that pushes operators to look at dynamic QR menus in the first place.

We work with a lot of restaurant operators at Linkaroo, and the questions we hear are almost never about scanning technology. They are about pragmatic operations: should I bother with a QR menu at all, what is the cheapest reliable workflow, how do I handle allergens, what do I do about Spanish-speaking guests, and is anyone actually scanning these things? This piece answers those questions directly, with the opinions we have formed from watching hundreds of restaurants do this well and badly.

If you want the higher-level overview of QR for restaurants, the restaurant industry page covers it. This is the deep dive.

We have a strong opinion here, and it is not the obvious one. A static QR menu — where the QR code itself encodes the menu URL — is fine if you are absolutely certain you will never change that URL, never move hosting providers, never rename the file, and never want to know who is scanning. For roughly zero restaurants, that is true. For everyone else, dynamic is the default.

The reason is mostly about cost of mistakes. A static QR is cheap when nothing changes and very expensive when something does. A typo in the encoded URL, a CMS migration, a domain rename, a change of beverage partner — any of those means reprinting every table tent, window decal, and to-go menu. Dynamic QR codes shift that update from the physical world (printer, shipping, swap-out on a Tuesday lunch shift) to the digital one (log in, change the destination, done in 30 seconds). The break-even is roughly one unexpected change.

The thing nobody tells you is that the QR code is the easy part. The actual work is deciding what guests scan into. Here is the workflow that holds up across the restaurants we have seen do this well.

1. 01

   Decide what lives at the destination

   Three options, in order of how much we recommend them. First, a mobile-friendly page on your own website at a clean URL like yourrestaurant.com/menu. This is best if you already have a website, because guests trust your domain, you control SEO, and you can add allergen filters and language toggles directly. Second, a PDF hosted on your own domain. Workable, but PDFs are awful on phones — pinch-to-zoom is a guest experience tax you should not be charging people. Third, a third-party menu platform. Fine if you already pay for one, but do not buy one for this purpose alone.

2. 02

   Wrap it in a dynamic QR

   In Linkaroo this is one screen: create a new dynamic QR, point it at your menu URL, pick a short slug like lnk.ro/menu-bistro, and download the SVG. Two notes on the design. Keep the dark modules genuinely dark — fashion-forward gray-on-cream QR codes scan poorly in low light, which is exactly the lighting most dinner services run in. And add your logo in the center; it doubles as a trust signal for guests who reasonably worry about scanning random codes.

3. 03

   Test in the actual environment

   Print one table tent. Walk it to a four-top in the back corner of your dining room at 7:30pm. Try to scan it with the dimmer at the level you actually run dinner service. About one in five restaurants finds out at this stage that their print contrast or their lighting is wrong. Better to find out now than after a $400 print run.

4. 04

   Print everything you would have printed anyway

   Table tents, window decals, takeout boxes, business cards, the chalkboard outside. The QR is the same on all of them because it is dynamic — you can change every destination from one dashboard later. This is the part that pays back the work.

5. 05

   Update from your phone, not the printer

   When your sommelier changes the by-the-glass list, or your kitchen 86s the special, or you swap to a brunch menu at 10am Saturday, the QR does not change. The destination does. From the operational side, this should feel like editing a Google doc, not ordering more table cards.

This is the section operators in tourist-heavy areas care about most. Miami, San Francisco, New York, anywhere with reliable international tourism — guests arrive expecting Spanish, Mandarin, or Portuguese, and printing four separate menus per table is absurd.

There are three patterns that work, and one that is tempting but bad. The bad one first: do not use separate QR codes per language on the same table. It clutters the card, guests pick the wrong one, and you end up with worse analytics because every language switch looks like a fresh scan.

On translation quality: do not Google Translate your menu. Get one bilingual staff member to spend ninety minutes on it once, and treat the translation as a permanent asset. Translated menus full of nonsense (“chicken in the form of a flame” for pollo a la llama) read as carelessness in a way that spills over into the food.

Three things to know. First, allergen disclosure rules vary by jurisdiction. The EU has the 14-allergen list and explicit written disclosure requirements; the UK has Natasha's Law for pre-packaged food sold on-premises; the US is more fragmented at the state and city level. If you operate across regions, your menu page is the cheapest place in the world to handle all of this. A printed menu cannot adapt; a web page can.

Second, the practical implementation that works: each menu item has a small row of icons for the top allergens (gluten, dairy, shellfish, tree nuts, peanuts, soy, egg, sesame, fish) and a short text disclaimer at the bottom of the page that says something like “Please inform your server of any allergies. Our kitchen handles all major allergens and cross-contamination cannot be fully eliminated.” The icons are the guest-facing UX. The disclaimer is the legal-facing backup. You need both.

Third, accessibility. A QR menu that is not screen-reader accessible is worse than a printed menu, because at least a printed menu can be read aloud by a companion. Real semantic HTML, alt text on item photos, sufficient contrast, and a font size that does not require pinch-zoom. If you cannot guarantee this, keep at least one printed menu at the host stand and advertise it.

This is the killer feature that operators tend to underestimate until they use it once. Same physical QR, different destinations depending on the day and time. A standard week at a neighborhood place might look like this:

Linkaroo's scheduled changes feature handles this without anyone needing to log in on a Saturday morning. We have customers who set up the next year of holiday menus in a single afternoon and never think about it again. That is the right operational mode.

The mistake to avoid is over-segmenting. We have seen operators try to schedule fifteen different time windows in a week, and the cognitive load of debugging which menu is showing at any given moment outweighs the benefit. Three or four windows is the sweet spot. If you need more, you probably actually need a different platform for live menu editing.

Most QR analytics dashboards show you fifteen numbers. About three of them matter for a restaurant.

Scans per cover

Take your daily scan count and divide it by your daily cover count from your POS. The number should sit somewhere between 0.4 and 1.2 depending on how many people per table use one phone. Below 0.4 means your placement is wrong — the QR is on the back of the menu, or the table tent is being moved by servers, or your dimmer is too low. Above 1.5 usually means you are getting re-scans from the same party, which is good signal that your menu page is genuinely useful as a reference (people are re-opening it to check prices, look up a wine, show their partner the dessert).

Scan time-of-day distribution

If you have a time-based menu schedule, the scan distribution should mirror your service windows. A bimodal curve with peaks at noon and 7pm is healthy. A flat distribution means people are scanning your menu from outside the restaurant — usually a takeout QR or a window decal being scanned by passers-by. Both useful to know.

Device split

iOS vs Android. This matters because of viewport sizes. If you see a 70/30 iOS skew (typical for higher-priced restaurants in the US) you can design for iPhone screen widths first. If you see a 40/60 Android skew you should test on a wider variety of screens, because Android viewport fragmentation is real.

What to ignore

Unique vs total scans for a single QR placed at a single restaurant is mostly noise — guests change phones, clear cookies, scan from different angles. Country-level analytics unless you are in a tourist district. Day-of-week patterns are almost always your normal cover patterns and tell you nothing new. The temptation is to spend an hour every Monday in the analytics dashboard; the right amount is ten minutes a month comparing the three numbers above to last month's.

A QR menu is not a 2020 pandemic artifact and it is not a sophisticated marketing channel. It is a small piece of operational plumbing that, when done well, removes friction from two specific problems: keeping your menu current without reprinting, and serving multilingual or allergen-sensitive guests without a stack of laminated cards. Done badly, it actively annoys guests and tells you nothing useful. The difference between done well and done badly is almost entirely about the page the QR points to, not the QR itself.

If you take one thing from this: make it dynamic, build a real mobile-first menu page, schedule your time-based swaps once and then forget about them, and keep printed menus at the host stand. That is the entire program.