A QR code menu lets you change prices without reprinting a single table tent, see how many people scanned at lunch versus dinner, and hand a guest the menu in their own language. That is the short version of why restaurants kept QR menus around after 2020, even as printed menus came back to the table. The longer version is about one decision you make before anything gets printed: dynamic or static.
QR codes for restaurant menus come in two kinds that look identical at scan time. A static code encodes your menu's web address directly into the pattern, so once it is printed the destination is frozen. A dynamic code encodes a short link instead, and the short link points wherever you tell it to today. If you ever expect to change a price, swap a seasonal dish, route diners to a different language, or learn anything about who scanned, you want dynamic. Static only makes sense when the menu address will never change and you genuinely do not care about scan data. For a working restaurant, that is almost never true.
This guide covers the whole setup: choosing dynamic over static, designing a table QR that actually scans, routing by language or device, tracking scans by table and time, printing and laminating so the code survives a busy service, keeping the whole thing accessible, and a step-by-step you can follow in an afternoon.
Why a QR Code Menu Beats a Reprinted One#
Three things change the day you move from a printed-only menu to a digital menu QR code.
The first is editing. Costs move, a supplier swaps an ingredient, a dish sells out, the seasonal cocktails launch a week late. With a printed menu, every one of those is a reprint or a sticker over the old price. With a dynamic QR code menu, you change the destination once in a dashboard and every table tent in the room points to the new menu instantly. The code on the table never changes.
The second is measurement. Each scan of a dynamic code is a redirect, and a redirect is a logged event. You can see how many people scanned, roughly where, on what kind of device, and when. For a single restaurant doing a few hundred to a few thousand scans a week, that is enough to answer real questions: is lunch or dinner driving more menu views, which day is busiest, did the new window placement get any scans at all.
The third is reach. One code can serve a guest in English, German, or Ukrainian by routing on the phone's language. No second printed menu, no laminated translation that goes out of date. We get into the routing mechanics below.
There is a fourth benefit people still ask for by name: contactless. A QR menu means a guest reads the menu on their own phone without handling a shared, wiped-down card. The pandemic made that the headline feature. Today it is a quieter convenience, but it still matters for turnover and for guests who prefer it. The deeper reason to keep the code, though, is the first three: edit, measure, route. Those are the things a reprinted laminate can never do.
If you want the conceptual foundation before going further, dynamic vs static QR codes walks through exactly what each kind encodes and why the difference is locked in at print time. And what is a URL shortener covers the redirect layer that makes any of this work.
How a Dynamic Table QR Code Routes a Scan#
Here is the path a scan takes, end to end. A diner points their camera at the table tent. The phone decodes the QR and opens the short link it contains, something like s.elido.me/menu-12. That link hits Elido's edge, which looks up the current destination, logs the scan, optionally checks the phone's language or location, and redirects to the right menu page.
That one redirect hop is where every useful feature lives. Because the destination is looked up at scan time rather than baked into the print, you can change it whenever you want. Because the lookup is logged, you get analytics. Because the lookup can branch, you can route by language or device. The redirect itself adds a few milliseconds on a cache hit, which is nothing next to the camera focus, decode, and page load a phone does anyway. The diner never notices the extra hop.
The short link is the part worth getting right. A code that encodes s.elido.me/menu-12 is a small, sparse grid that scans cleanly at 3cm. A code that encodes a long address full of tracking parameters is a dense grid that needs to be printed larger to scan at the same distance. Shorter link, smaller code, more reliable scan. This is the underrated reason to put a shortener in front of a menu even if you never edit it: the code is physically easier to read.
For restaurants specifically, URL shorteners for restaurants covers the wider campaign picture - window clings, takeaway stickers, reservation funnels - that sits around the table menu. This post stays focused on the menu code itself.
Designing a Table QR Code That Actually Scans#
A QR code that fails to scan is worse than no QR code, because the guest already tried. Most failures come from four design mistakes, and all four are easy to avoid.
Contrast comes first, and it beats color every time. Black modules on a white background is the most reliable combination there is. Brand colors are tempting, but a pale code on a pale background drops the scan rate fast, sometimes to zero in dim light. If the brand demands color, use a dark ink (deep navy, near-black brown) on a light, plain background, and test it before you commit. Pastel on pastel is a reprint waiting to happen.
Size is set by distance. The widely repeated rule of thumb is that a code should be at least one tenth of its scanning distance. A table tent read from about 30cm wants roughly 3cm of code, and that scans on most modern phones. In a low-lit dining room, go to 4cm or 5cm. The standard that defines QR structure, ISO/IEC 18004, describes how the module grid grows with data, which is why the shorter your encoded link, the smaller you can print and still scan.
The quiet zone is the rule designers break most often. A QR code needs clear, empty space around it, at least four modules wide (a module is one of the small squares in the pattern). Crowd text, a logo, or a border right up to the code edge and scanners struggle to find it. Leave the margin.
Placement is the part the spec does not cover. Put the code where a seated guest can reach it without leaning across the table or picking up a heavy holder. A table tent at eye-ish level, angled slightly toward the chairs, beats a sticker flat on the tabletop that catches glare from overhead lights. Glare is a real killer on glossy laminate, which is why finish matters as much as position.
For the branding side - logos, frames, color within safe limits - branded QR codes design goes deeper than there is room for here. The one design rule to never trade away is contrast.
Multilingual and Device-Aware Menu Routing#
A single QR code can lead to different menus depending on who scans it. This is the smart-routing part of a dynamic link, and for restaurants it solves two real problems.
The first is language. A guest whose phone is set to German can land on the German menu; a guest on an English phone lands on English. The redirect reads the browser's language preference and picks the matching destination, falling back to a default when there is no match. One printed code, several menus, zero extra table tents. For a restaurant in a tourist city or near a border, this is the feature that earns its keep.
The second is location or device. A code on a takeaway bag can send local scans to an ordering page and out-of-area scans to a plain menu. A code that should behave differently by country can route on the scanner's region. The mechanics are the same redirect-time branch; you are just choosing what to branch on. Geo-targeting short links covers the location case, and smart links explained covers the routing engine in general, including how the rules are evaluated and what happens when none match.
A word of caution: keep the rules simple. A menu code with one language branch and a sensible default rarely goes wrong. A code with six nested conditions is a thing that breaks quietly at the worst time. Route on the one or two dimensions that actually change the menu, and let everything else hit the default.
Tracking Scans by Table, Location, and Time#
This is where a digital menu stops being a convenience and starts being a source of data. Every scan of a dynamic code is logged, so the question becomes how granular you want the breakdown.
The simplest setup is one code for the whole room. You get total scans, by hour and by day, which already tells you your lunch-to-dinner ratio and your busiest service. The next step up is one code per zone or per table, each pointing to its own short link that redirects to the same menu. Now the analytics break down by table or section. You can see that the window tables get scanned more, or that table 12 in the corner barely registers, which might be a placement problem rather than a seating one.
For a chain, the same idea scales by location. Tag each link with the location and the placement, then filter the analytics to compare one restaurant against another, or compare every window placement across the group. The tags do the slicing; you read the result. Elido's analytics records each scan as a raw event with no sampling, so even a quiet table's numbers are exact rather than estimated.
A practical note on what the data can and cannot tell you. A redirect event captures the scan: when, roughly where, what device. It does not by itself tell you whether the guest read the whole menu or ordered the special. For that you need the menu page to report back, which most restaurants skip at first and add later if they care. The scan-level data alone is enough to manage placements and staffing, which is most of the value.
If you are building a wider tracked campaign rather than just a menu, building a QR code campaign from scratch is the step-by-step for that, and URL shorteners with QR codes covers generating and managing codes at volume.
Printing, Lamination, and Surviving Service#
A QR code in a restaurant lives a hard life. It gets splashed, smudged, scuffed, and bent. Design for that.
Error correction is your insurance. QR codes carry redundant data so they still scan when part of the pattern is damaged, and the level is adjustable. The highest level recovers from roughly 30% of the code being obscured, which is exactly the margin you want on a surface that will get sauce on it. The trade is that higher correction makes the grid a little denser, but because your encoded link is short, you have room to spare. For table tents and bag stickers, lean toward higher correction.
Lamination protects the print but introduces glare. A glossy laminate under direct downlights can bounce enough light back at the camera to defeat the scan, especially when the guest tilts the tent to read it. A matte or satin laminate scatters that light and scans far more forgivingly. If you only change one thing about your current setup, make the laminate matte.
Print test, every time. Export the code, print the actual size on the actual stock with the actual finish, and scan it from a seated distance on three or four different phones, including an older one and one in a case. The on-screen preview always looks fine. The laminated card under your dining-room lights is the only test that counts. Order the batch after that passes, not before.
One more thing the design files should carry: vector, not raster. Export the code as SVG where you can, so the printer scales it without the edges going soft. A blurry module boundary is a scan failure on a worn card months later.
Accessibility and the Text Fallback#
A QR-only menu excludes people, and that is both an ethical and a practical problem. Some guests have no smartphone. Some have no data and your dining room has no usable signal. Some have a cracked camera, an older phone that scans badly, or low vision that makes the small screen hard to use. Designing only for the confident-scanner guest leaves real customers stuck.
The fixes are cheap. Print a short, human-readable web address next to the code so anyone can type it instead of scanning, which also doubles as a recovery path when a scan just will not catch. Keep printed menus available on request and tell staff to offer them without making it a thing. And make the digital menu page itself usable: real text rather than a photo of a menu, readable font sizes, and structure a screen reader can follow.
That last point matters more than the print. A menu delivered as a flat image is invisible to a screen reader and unreadable to anyone who needs to zoom. Public accessibility guidance like the W3C WCAG overview sets the baseline here: text alternatives, adequate contrast, and content that reflows. A digital menu is a web page, and the same rules apply to it as to any other page you would publish.
Treat the text fallback and the printed-menu option as part of the QR menu, not as an afterthought. A guest who cannot scan should never be the guest who cannot order.
A Step-by-Step QR Code Menu Setup#
Here is the whole thing in order, assuming you start from nothing.
First, get the menu online. It can be a clean PDF, a page on your site, or a simple mobile-first menu page. The only hard requirement is a stable web address. Make sure it reads well on a phone, because that is the only screen it will ever appear on.
Second, create a dynamic short link that points to that menu. This is the editable, trackable layer. Give it a clear label so you recognize it later, and if you run more than a couple of placements, tag it with the location and the spot (table, window, takeaway).
Third, set up routing if you need it. Add a language branch for a second or third menu, or a location branch for takeaway. Keep it to the one or two dimensions that actually change what the guest should see, and confirm the default destination is sensible.
Fourth, generate the QR from that short link, using a QR code menu generator that produces a dynamic code rather than baking the address in. Set high error correction, keep it black on white, and export as SVG. Browse the QR gallery if you want examples of styling that stays inside the contrast rules.
Fifth, print a test, scan it on several phones at seated distance under your real lighting, then order the batch on matte laminate. Add the human-readable address next to the code on the print.
Sixth, watch the analytics for the first two weeks. You are looking for the lunch-to-dinner shape, the busiest day, and any placement getting near-zero scans. That last one usually means the code is hard to reach or catching glare, not that nobody is interested.
That is a working QR menu: editable when prices move, multilingual when the room needs it, measured so you can manage it, and accessible so nobody gets left at the table. The smart links and QR codes features handle the routing and generation, and the marketers solutions page covers the campaign workflow if you grow beyond the menu. Tier details are on the pricing page.