Menu QR Code Generator
Free contactless menu QR codes for restaurants, cafes, bars, and food trucks. Upload a PDF menu or link your hosted menu page — customers scan one QR from a table tent and see your current menu instantly. Dynamic QR means you update prices anytime without reprinting the table tent.
TL;DR — the right menu QR setup in 60 seconds
Use a dynamic URL QR (not static) pointing to either a hosted menu page or a PDF. Dynamic means you can update the destination — new prices, new specials, new sold-out items — without reprinting the table tent. Static QRs bake the URL into the pattern; once printed, the menu can't change without replacing every sign.
Size the QR at 2.5 × 2.5 inches on a 4-inch table tent, H-level error correction, matte laminate (glossy creates glare under restaurant lighting). Place it on all four sides of the tent so every seat at a four-top can scan without rotating. Typical seated-party scan rate: 60-80% for full-service casual, 30-50% for counter-service.
The rest of this guide covers every real decision — PDF vs hosted menu page, print specs for different restaurant types, dynamic vs static, what to do if WiFi fails, and the order-and-pay / PCI boundary.
Your menu QR is a revenue lever, not a convenience feature
Most menu QR advice treats this as a simple convenience thing — save on ink, avoid paper menus, feel modern. All true, all missing the real number. A QR menu saves roughly 5-10 minutes per seated party on the full order-to-close cycle. At a casual restaurant doing $14 per-person-per-hour in revenue, a party of four turning 7 minutes faster earns the house about $6.50 more that visit. Across 40 tables × 3 turns a night × 350 nights, that's roughly $270K in recovered revenue per location per year.
The operators who get this right turn contactless menus from a cosmetic choice into an operational lever. The rest of this page covers the specific decisions that separate QR menus that work from ones that don't — print specs, dynamic vs static, PDF vs hosted page, placement, update workflow, and the PCI scope boundary you hit the moment you add order-and-pay.
For the deeper workflow-first guide with the full table-turnover math, see our restaurant QR industry guide. This page focuses on the mechanics of the QR itself.
By Ahmad Tayyem, Founder & CEO of QRLynx
PDF menu vs hosted menu page — which to point your QR at
Your menu QR has two realistic destination types. Both work. The right choice depends on how often your menu changes and whether you want analytics.
Option A: PDF menu. You upload your existing menu PDF (say, the one your designer made for printing) and the QR opens it in the customer's browser. Dead simple: no web design needed, no menu-page CMS, the PDF itself is the menu. Update velocity: fast — swap the PDF in your dashboard, next scan serves the new version. Works for 80% of restaurants that don't want to maintain a separate menu website.
When PDF wins: you already have a beautifully-designed print menu and want to avoid recreating it on the web. Your menu changes seasonally (not daily). Your food is photo-led and the PDF layout is the selling feature.
When PDF loses: mobile-viewing is painful on long PDFs (pinch to zoom, scroll on small text). Customer conversion to order is lower than a mobile-optimized page. If you're doing order-and-pay through the QR, PDF can't handle that — you need a real page.
Option B: Hosted menu page. A mobile-optimized HTML page on your domain (or on a menu-builder like Toast, Square, or BentoBox). The QR points to a URL like yoursite.com/menu. Advantages: instant-load on mobile, clean typography, easy to scan through on a phone, supports add-to-order buttons, tracks engagement per dish. This is what Toast, Square, and Shopify Restaurant templates produce by default.
When hosted page wins: your menu changes frequently (weekly specials, daily sold-outs). You want per-item click tracking. You'll eventually add order-and-pay. You already have a website with a CMS. Your customer base skews mobile-first and expects app-quality UX.
The dynamic-vs-static question is separate — and dynamic almost always wins. A dynamic QR encodes a short redirect URL (qrly.ly/xyz); you can change what that URL points at anytime without changing the printed QR. Static QRs bake the destination into the pattern; once printed, you can't change it. For menus that will be printed on table tents with a 6+ month lifespan, dynamic is the correct default. The only time static makes sense is a one-week pop-up where you genuinely know the menu won't change and you'll throw the QR away.
Which menu QR setup for your venue
Restaurants, cafes, bars, food trucks, and hotel restaurants all have different constraints. Here's the right QR configuration for each.
Full-service restaurant
Dynamic URL QR pointing to a hosted menu page. 2.5 × 2.5 in on a 4-sided table tent. Order-and-pay added after baseline scan rate (target 60%+). Server still owns hospitality; QR just removes the menu-delivery and check-close bottlenecks.
Café / coffee shop
Dynamic URL QR on a counter-top card plus small cards at each table. Point to a mobile-optimized menu with order-ahead button. Cafés benefit most from order-ahead — customers pick up faster, counter queue stays short during rush.
Bar / pub
Dynamic URL QR on table tent and bar-top card. Menu page should lead with cocktails + seasonal specials (high-margin). Static QRs acceptable for bars that only update their menu twice a year.
Food truck / pop-up
Dynamic URL QR on truck-side graphic (3 × 3 in for 4-5 ft scan distance). Destination doubles as 'find us next' schedule. Rotating-location businesses get outsized value from dynamic — one print, infinite schedule updates.
Hotel restaurant
Dynamic URL QR on room-service card + dining room table tent. Room version links to room-service menu with room-charge payment. Dining version links to the regular menu. Two QRs, one account, different destinations.
Catering / event venue
Dynamic URL QR on banquet-program card or table tent. Menu page should surface the specific event's menu (customized per event). Dynamic lets you update per-event without reprinting anything.
Print specs for menu QR codes that actually scan
The 1:10 rule (QR size = scan distance ÷ 10) is the starting point. Real-world restaurant conditions — low-to-medium lighting, glossy laminated surfaces, phone cameras held at varying angles — push these numbers.
Table tent (seated scanning, 18-24 in distance): 2.5 × 2.5 inches per side, all four sides. H-level error correction (30% damage tolerance — restaurants are wear-prone environments). Matte lamination on the QR area (glossy laminate creates hot-spot glare under restaurant pendant lighting). White background with dark QR modules. Include a 4-module quiet zone around all sides.
Menu-embedded QR (printed menu with QR on back): 1.5 × 1.5 inches. Reading distance 10-14 inches, so 1:10 rule says 1-1.4 in. Include a label ("Scan for full menu" or "Scan to order") — a labeled QR scans at 15-25% higher rate than a bare QR because customers know what scanning does.
Counter-top card (café / counter service): 3 × 3 inches on a 5-inch A-frame. Scan distance 2-3 feet (customer standing at counter). Can be glossy here because indoor lighting is less directional. Include a clear CTA ("Order at the table").
Window decal (takeout / street visibility): 4 × 4 inches. Reading distance 4-8 feet from sidewalk. Weather-resistant vinyl laminate. Test at 2pm and 9pm — different sun angles affect glare.
Food truck / outdoor signage: 5-6 inches. Scan distance 5-10 feet. UV-resistant outdoor-grade vinyl. Non-reflective backing. Include the day's or week's specials text so the QR is not the only value-add (reduces reliance on scan success).
Print DPI: 300 DPI minimum at the final print size. Most menu-QR failures we see are printers that ran the job at 150 DPI — QR module edges soften just enough to confuse older phone cameras. Always export as SVG or 300+ DPI PNG.
Before committing to a large print run, proof one table tent and run a 20-scan test: scan with an iPhone, Android, and an older phone, at 3 distances (close, typical, far), in 3 lighting conditions (bright lunch, dim dinner, mixed bar lighting). Target 95%+ first-attempt scan success. If any scenario fails consistently, redesign before printing 500.
Operational details most restaurant operators miss
The update workflow is where QR menus deliver or fail. The whole point of dynamic is you can update the menu without reprinting. But if your menu-update process still takes 3 hours (edit PDF, export, re-upload, re-test), you've recreated the old-menu problem in digital form. Set up the update flow once: menu editor → publish button → QR destination auto-refreshes. Target: 90 seconds from price change to live on every table tent.
What happens when your restaurant's WiFi goes down. The QR on the table tent still works because customers scan with their cellular data, not your WiFi. This is actually more resilient than POS terminals. The failure mode to plan for is the hosting provider's downtime (rare but real) or a bug in a menu page update. Keep one laminated paper backup menu per section — it's cheap insurance that rarely needs to be used.
The order-and-pay / PCI scope boundary. A read-only menu QR (customer views menu, server takes the order) is outside PCI scope entirely. Zero compliance burden. Add order-and-pay via the QR and your scope changes. The clean path: use a PCI-compliant processor (Stripe, Square, Toast) whose hosted checkout page the menu redirects to. Your PCI obligations become SAQ-A (22 questions, simplest level). Don't build inline card-entry on your menu page unless you have dedicated compliance resources.
Per-table identifiers. If your menu QR is the same on every table, orders don't auto-route to the right table when you add order-and-pay. Solution: per-table QR with a URL parameter (?table=12). Your menu page reads the parameter, your POS knows which table the order came from. Most operators skip this initially and retrofit later when order-and-pay goes live — cheaper to build it in from the start.
Multi-location operators: one QR per location with per-location menu destinations (prices and specials differ by location). A shared QR across 5 stores forces you to either standardize menus harder than you want to, or build location-detection into your menu page. Most multi-location restaurants use QRLynx's smart redirect rules to route a single QR by IP/geo — simpler than per-location print runs.
Menu QR Code FAQ
What is a contactless menu QR code?
A contactless menu QR code is a QR code printed on a table tent, card, or sign that — when scanned with a smartphone camera — opens the restaurant's menu on the customer's phone. No app download, no paper menu passed from customer to customer, no server required to deliver a menu. The menu loads in the customer's default browser in under 3 seconds on typical cellular data.
How do I create a QR code for my restaurant menu?
Use a dynamic QR code generator like QRLynx's PDF QR generator or URL QR generator. Upload your menu PDF or paste your hosted menu URL, download the QR (SVG or 300+ DPI PNG), and print it on a table tent or counter card. The free tier includes 3 dynamic QRs — enough for most single-location restaurants.
What's the best QR code for a restaurant menu?
A dynamic URL QR (not static) pointing to either a hosted mobile-optimized menu page or a PDF menu. Dynamic is almost always right for restaurant menus because menus change — prices, specials, sold-outs, seasonal items. Static QRs lock the menu into the print run; you can't update without replacing every table tent. For full-service restaurants, 2.5 × 2.5 inches on a 4-sided table tent with H-level error correction is the reliable default.
Is a digital QR menu free for restaurants?
Yes, at the basic level. QRLynx's free tier includes 3 dynamic QRs — enough for most single-location restaurants (menu, WiFi, feedback form). Static QRs are unlimited and free anywhere. Paid tiers ($7/mo Starter+, $14/mo Pro) add more dynamic QRs, custom domains, password protection, and team access — useful for multi-location operators or if you want tighter analytics.
Do customers need an app to scan a menu QR code?
No. Every modern smartphone (iOS and Android) has QR scanning built into the default camera app. Open the camera, point it at the QR, a notification pops up, tap to open the menu. No app download, no signup, no account. This is what makes QR menus practically universal — they work on 95%+ of customer phones without any friction.
Can I use the same QR code for multiple restaurants?
Technically yes, but you'll regret it. Each location's menu, hours, and pricing will diverge over time. A shared QR forces your menu page to detect location or force customers to pick one. A per-location QR lets you manage each menu independently and — with smart redirect rules — route a single printed design to different menus based on the customer's location or the QR's assigned location code.
How big should a menu QR code be on a table tent?
2.5 × 2.5 inches (6.4 × 6.4 cm) per side on a standard 4-inch table tent. Customer seated at the table is 18-24 inches from the QR — the 1:10 rule says 1.8-2.4 inch minimum, and we add a 20% safety margin for real-world restaurant lighting. Smaller than 2 inches fails too often in dim rooms; larger than 3 inches visually dominates the table tent. See our QR size calculator for other placements.
Can I update my QR menu after printing the table tents?
Yes, if you used a dynamic QR. Log into your QR platform's dashboard, update the destination URL (or re-upload the PDF menu), and the next scan serves the new version. The printed QR on the table tent never changes — the redirect does. This is the single biggest advantage of dynamic QRs for restaurants. Static QRs can't be updated; you'd have to reprint every table tent.
What happens if my restaurant's WiFi goes down during dinner?
Customers scan with their cellular data, not your WiFi — so the menu still works even if your WiFi is down. This is actually more resilient than paper-menu operations that depend on servers being available. The failure mode to plan for is the menu-hosting provider's downtime (rare but real) or a bug introduced during a menu update. Keep one laminated paper backup menu per section for that 1% scenario.
Is a QR menu PCI-compliant for restaurants taking payments?
It depends on implementation. A read-only QR menu (view menu, order via server) is fully outside PCI scope — zero compliance burden. The moment you add order-and-pay via the QR, your scope changes. Use a PCI-compliant processor (Stripe, Square, Toast) whose hosted checkout page the menu redirects to, and your obligation stays at SAQ-A (simplest self-assessment). Don't build inline card entry on your menu page unless you have dedicated compliance resources.
How do I print a QR code for my restaurant menu?
Download the QR as SVG (scales cleanly to any size) or 300+ DPI PNG at the final print size. Use any commercial printer — Moo, Vistaprint, or a local print shop. Specify matte laminate on the QR area (glossy creates glare under restaurant lighting), white background, H-level error correction. Test one proof table tent before committing to a full print run of 50+ copies.
Can I track how many customers scan my menu QR code?
Yes, with a dynamic QR. QRLynx's analytics dashboard shows every scan — time, device, location, browser. You can see which meal periods have the highest scan volume, which tables scan most (if you use per-table QRs), and which days of the week your menu gets the most engagement. Static QRs can't be tracked — they route directly from phone to destination without passing through any server.
Can I make a QR code that links to a specific meal or item?
Yes. You'd create a QR code that points to the specific item's anchor on your menu page (e.g., yourmenu.com/menu#appetizers), or to a dedicated item-detail page. This is useful for specials boards, tasting-menu cards, or shelf-edge labels on display cases. Each item gets its own QR, each tracks scans separately, and you can measure which items drive the most engagement.
What's the difference between a QR menu and a digital menu?
A QR menu is how customers access a digital menu — the QR code is the bridge from a physical table to a mobile web page. A digital menu is the menu itself (the HTML page or PDF). Every QR menu is a digital menu; not every digital menu uses a QR code (some embed in a website, hotel TV, or kiosk). For restaurants, QR is the most common delivery format because it works without any install or account.
Related guides
For the industry workflow-first guide including table-turnover economics, PCI scope details, and per-restaurant-type recommendations, see QR codes for restaurants. For the detailed step-by-step on menu setup specifically, see the restaurant menu QR code guide.
On the physical side: table tents are card-stock and follow the business cards material guide for sizing + finish. Window decals for takeout are covered in the posters guide. Food truck graphics are closer to the t-shirts guide conceptually (flexible substrate + weather + UV) but typically use vinyl.
For QR design decisions: use our QR size calculator for exact size recommendations, and the readability checker to verify your QR design will scan reliably before printing. For the specific static-vs-dynamic decision, see our dynamic vs static guide.
If you want tracking on each menu scan: the QR code analytics dashboard shows time, device, location for every scan across all your QRs.
Sources & research
The claims and benchmarks on this page draw on authoritative industry bodies and QRLynx platform telemetry:
- National Restaurant Association — State of the Restaurant Industry — primary U.S. industry body for restaurant operational benchmarks including table-turnover and revenue-per-cover data.
- Toast POS — Restaurant Technology Industry Report — annual data on POS adoption, QR menu penetration, and order-and-pay conversion metrics.
- PCI Security Standards Council — SAQ-A guidance — compliance reference for restaurants moving from read-only menus to payment-enabled QR flows.
- ISO/IEC 18004:2015 — QR Code symbology specification — international standard defining quiet zone, error correction levels, and print requirements.
Platform telemetry references are based on aggregated scan data from QRLynx restaurant customer accounts. Individual data points are directional guidance, not guaranteed outcomes.
By Ahmad Tayyem · Last updated: