QR Codes for Restaurants
A QR menu is a revenue-per-table lever, not a convenience feature. Every minute a party waits for a paper menu, the kitchen has one fewer ticket to work. Every static menu reprint costs real money and loses weeks of price-update responsiveness. This guide runs the table-turnover economics, the menu-update velocity math, the placement trade-offs (table tent vs. sticker vs. window), and the PCI boundary you hit the moment you add order-and-pay.
A QR menu is a revenue lever, not a convenience feature.
Most QR-menu vendor content talks about convenience — cleaner than paper menus, faster to update, no ink costs. All true, and all missing the real number. The real number is revenue per table per night. Every minute a party spends waiting for a server to bring a menu, take the drink order, and come back for the food order is a minute that table isn't turning. At a mid-tier casual restaurant doing $14 per-person-per-hour in revenue, a party of four that turns in 70 minutes instead of 82 earns the house roughly $11 more that visit. Over 40 tables and three seatings a night, that's $1,320 a night that a well-placed QR menu puts on the board.
That's the economic reason to care about QR menu design. The second reason is less dramatic but compounds over years: menu update velocity. A printed menu costs $80-250 per batch to design, proof, and reprint. If you're updating prices monthly (as most operators should be post-2023), that's $1,000-3,000 in print alone per location per year, plus the 10-day turnaround that means your prices are always 10 days out of date. A dynamic QR pointing to a hosted menu page moves that to a zero-print-cost update that takes 90 seconds and is live for every scan in every location immediately.
Everything in this guide is downstream of those two numbers. Size is set by the seated scan distance. Placement is set by the server-avoidance pattern (you want scans to happen before the server arrives, not during). The decision to move to order-and-pay is a PCI-scope decision, not a UX decision. And the measurement plan — what you track and why — comes directly from "how much revenue did this change add" rather than "how many people scanned." If any of those feel obvious, the rest of this page will fill in the specific numbers.
One preview: for 80% of restaurants, the right answer is a dynamic URL QR on a 3 × 3 inch table tent, pointing to a mobile-optimized menu page you host yourself, with lead-form and order-and-pay as follow-on additions once you've validated the baseline scan rate. The rest of the decisions are covered below.
By Ahmad Tayyem, Founder & CEO of QRLynx
The table-turnover calculation most operators never run
Here's the math laid out explicitly, because most restaurant operators have never seen it with the QR variable isolated. Pick your revenue-per-person-per-hour number (the full dining industry average in the U.S. for 2025 was around $14 for casual, $22 for upscale casual, $45+ for fine dining). Multiply by average party size. That's your table's hourly earnings. Divide by 60 to get revenue-per-minute-per-table.
For a four-top casual table at $14 per-person-per-hour, that's $56/hour or $0.93/minute. If a QR menu saves seven minutes on the average cycle — which is a realistic range, not a stretch, based on operator-reported data — that's $6.51 in additional revenue per turn. At three turns per night, that's $19.53 per table per night. At 40 tables, $781 per night. At 350 operating days a year, $273,350 per location per year in recovered revenue.
The seven-minute figure deserves unpacking because it's the number everyone waves past. Where does it come from? Four sources. First, the menu-delivery cycle: a server's average time from seating a party to putting menus in their hands is 90-180 seconds during peak hours. With a QR, the party can scan while the server is still getting drinks. That's 60-120 seconds recovered. Second, decision-plus-attention-plus-capture: a paper menu ties up the server to hover and answer, then walk the order to POS. QR menus with in-browser order-building cut the server from the decision loop entirely — typical savings 2-4 minutes on larger parties. Third, the reorder cycle (appetizers → mains → desserts → drinks) adds another 1-2 minutes of recovery because guests don't need a second round of menu delivery. Fourth, check close: order-and-pay via the same QR collapses the 6-12 minute "wave down server, ask for check, wait, come back, process card, wait" chain into a 90-second self-serve close. Sum: six to eleven minutes per table, depending on the party size and the service style.
Not every restaurant captures all of this. Here's the realistic capture rate by service type. Fast-casual (Chipotle, Panera style): mostly menu-delivery savings, 2-4 minutes realistic recovery. Order-and-pay doesn't apply because guests already order at counter. Full-service casual: full menu-delivery + order-and-pay savings, 6-9 minutes realistic per table. Full-service upscale: the server is part of the experience, so order-and-pay is wrong for the guest context; expect 3-5 minutes from menu-delivery alone. Fine dining: rarely the right setup — the QR is for the take-home menu and wine list reference, not the table. Revenue recovery happens in takeout growth, not turnover.
The menu-update velocity number is the second piece of the math, and it's cleaner. A monthly print update at $150 per batch × 12 months × locations gives you the annual print cost. For a 3-location operator, that's $5,400/year. A dynamic QR moves that to $0 plus the hosting cost (effectively negligible). On top of the direct savings, the ability to push price updates in real time — say, when a protein cost jumps 8% overnight — is worth several percentage points of margin on high-frequency menu items. Getting a $0.50 price adjustment live in three hours instead of three weeks, on a burger that sells 80 units per day, is $40 of margin per day recovered. Compound that across 20 items and a whole year and the number gets interesting fast.
This is why the right answer for most restaurants is a dynamic QR pointing to a hosted menu, not a static QR pointing to a PDF. The dynamic is what unlocks the update velocity; the static locks your menu to the moment you printed the QR, which defeats most of the point.
Which QR setup for your restaurant type
The right configuration depends on the service model. Here are the five restaurant archetypes and the corresponding QR recommendation — built from actual operator patterns, not generic advice.
Casual dining (full-service)
Dynamic URL QR on 3 × 3 inch table tent → mobile menu page with order-and-pay. This is the default revenue lever. 6-9 minute turnover recovery, 30-40% order-ahead adoption within 90 days. Add lead form on menu page for loyalty capture.
Fast-casual / counter-service
Dynamic URL QR on wall graphic near entrance + smaller QR on each table. Points to menu page WITHOUT order-and-pay (guests already queue at counter). Purpose: menu browsing before the line, reduces counter decision friction by 40-60%, shortens queue throughput. Add nutrition/allergen link as secondary QR.
Upscale casual
Dynamic URL QR on table (small, subtle placement) → menu page that respects the service experience (NO order-and-pay, NO lead form). Purpose: menu-delivery time savings + wine list + allergen detail. Server still owns the experience. Expected 3-5 minute turnover recovery.
Fine dining
Skip table QRs entirely. Use a takeout/website QR on the door or business card — wine list reference, reservation page, takeout menu. In-room QR is wrong for the service context. Focus the QR investment on takeout and catering channels instead.
Drive-thru / QSR
Dynamic URL QR on window signage (visible from driver seat, 6-inch minimum size) → loyalty sign-up + app download. In-car scans spike around ordering, so the QR is for follow-through conversion, not menu access. Menu board stays physical.
Cafés & bakeries
Dynamic URL QR on chalkboard or counter card → menu page with order-ahead link. Specific value: bakery-case items rotate fast and chalkboards get repainted weekly. Dynamic QR points to a live-updated menu that matches the case; no stale menu board confusion.
Placement strategy most operators get backwards
The canonical placement advice for restaurant QRs is "put it on the table." That's half right. The right frame is: put the QR exactly where the guest will notice it in the first 30 seconds of being seated, before the server reaches them. The first 30 seconds is the only window where the QR menu replaces paper menu delivery. Miss that window and you're just a backup in case the server is slow, which captures maybe 15% of the economic value.
So the placement hierarchy, in order of revenue impact: (1) table tent in the center of the table — visible to every guest, impossible to miss, scans happen within 10-15 seconds of seating; (2) menu holder sticker attached to the salt-and-pepper caddy or napkin dispenser — cheap, durable, nearly as visible; (3) laminated card at each place setting — adds friction because it requires the guest to pick it up; (4) sticker on the table surface itself — prone to smudging, scans with finger-over interference; (5) chalkboard at the entrance — only works if the restaurant has a waiting pattern; (6) QR on the paper menu itself — the worst option, because if the guest already has a menu, the QR is adding friction not removing it.
Size is set by the seated scan distance, which is shorter than most people think. A guest sitting in a chair looking down at a table tent is typically 18-24 inches from the QR. Applying the 1:10 rule (minimum QR size = scan distance ÷ 10), that gives a 1.8-2.4 inch minimum. Practical recommendation: 2.5 × 2.5 inches on a table tent, 2 × 2 on a sticker, 3 × 3 on a wall graphic at 4-5 feet away. Smaller than this fails in low-light rooms (many casual and upscale rooms run at 100-200 lux, which is the bottom of what phone cameras handle reliably).
Table tent orientation matters more than vendors talk about. Four-sided tents beat two-sided because guests from any seat can see the QR without rotating the tent. If you must use a two-sided design, orient the QR so it's readable from the two long sides of a four-top (not the short sides), because that's where 80% of guests sit. Lighting matters too: restaurants with candlelight or pendant spotlights often have hot-spot glare directly on the table center where tents sit. Test scans from every seat position under the actual lighting before committing to placement — or use a matte (not glossy) laminate for the tent finish.
One counterintuitive finding: putting the QR on the INSIDE of a closed menu (for restaurants that still use menus) underperforms putting it on the outside. Operators assume guests will see the QR when they open the menu, which misses the guests who never open the menu because they already know what they're getting. Outside-cover placement gets both populations. If you're keeping menus, print the QR on the front cover.
Order-and-pay: the PCI scope boundary most operators miss
If your QR menu is read-only (guests view the menu, then the server takes the order), you are outside PCI scope. Simple. The guest's phone loads a mobile page you host, nothing on that page touches a card, you're fine. The instant you add order-and-pay, your scope changes. Not necessarily in a bad way — but the compliance implications are real and should be planned into the launch, not retrofitted later.
The clean path: use a PCI-compliant payment processor (Stripe, Square, Toast) whose hosted checkout page the QR menu redirects to for payment. The card data never touches your domain or your menu page. Your PCI obligations reduce to SAQ-A (the simplest self-assessment, 22 questions). If instead you build your own payment form inline on the menu page, you're at SAQ-A-EP or SAQ-D — meaningfully more work (network segmentation, quarterly ASV scans, more detailed policies). For 95% of restaurants, hosted checkout via a major processor is the right architecture, not in-page card entry.
Two technical details that matter. First, the QR itself cannot contain payment data or any PAN (primary account number) or sensitive authentication data. That should be obvious but we've seen operators try to encode promotional codes that incorporate card-like identifiers into static QRs — don't do this, and verify the QR generator doesn't leak any sensitive data into the URL parameters. Second, the session handoff from menu page to payment page should use HTTPS throughout (a given in 2026 but worth verifying), and the session token used to track "which table is checking out" should be scoped to a short TTL and not be guessable.
Operational implications: an order-and-pay QR menu typically lifts per-party revenue 8-15% because guests order impulsively from a visual menu (more appetizer add-ons, more upgrades, more desserts) and pay at their own pace. It also redirects tip behavior — average tip percentages on order-and-pay are 2-4 percentage points lower than server-delivered checks. Net revenue is still up, but budget for the server-compensation adjustment or the model creates friction in the back of house.
If you're just starting, ship read-only first. Validate that your baseline scan rate is strong (target 60-80% of seated parties scanning within 5 minutes of sitting), iterate on menu page UX for 30-60 days, then layer order-and-pay once the menu page is performing. Shipping order-and-pay on a menu page with 20% scan rate is a fiscal mistake because you've built the complex part before validating the simple part.
What to measure, and what to ignore
Most restaurant QR dashboards track the wrong numbers. Total scans, scan trend, and top-scanning table are directionally interesting but don't answer the operating question, which is: did the QR change the economics per table per night. Here's a tighter measurement set worth the five minutes it takes to set up.
Scan-to-seated-party ratio. How many of your seated parties are scanning? If it's under 50%, the QR placement, design, or menu UX is the problem and no amount of additional features matters until you fix that. Target 60-80% for full-service, 30-50% for counter-service (where the counter is the primary order channel). Calculate: daily scans ÷ party count. Party count comes from POS.
Time-to-first-order-click. If your menu page has order-and-pay, the time from scan to first "add to cart" click is a direct signal of the decision friction. Under 90 seconds is healthy. Over 3 minutes means your menu page is too long, too slow, or the category structure is wrong.
Table-turn time with and without QR scans. This is the econ number. Cross-reference POS table-turn timestamps against QR scan timestamps for the same table. Parties that scanned should turn 5-10 minutes faster. If they don't, your service flow is re-inserting the server into steps the QR was supposed to remove (e.g., the server is still hand-delivering menus to scanned tables). Retrain.
Peak-hour scan coverage. Friday/Saturday 7-9pm should show 70%+ scan coverage for full-service. If peak-hour scan rates drop vs. weekday midday, it's almost always a server-interference issue (busier servers get in front of the QR more often, ironically reducing utility). Separate operating data.
Ignore these. Total lifetime scans (vanity). Scan-by-country (not useful at location level). Device type breakdown (iOS vs Android doesn't change the operator decision). Scan-to-menu-view conversion rate (menu-page analytics overlap with QR analytics; pick one).
One operational note: benchmark-wise, typical seated-party scan rates across QRLynx's restaurant customers in 2026 cluster around 55-65% for full-service casual, 28-42% for counter-service, and 8-15% for fine dining (where most operators shouldn't have table QRs at all). If your numbers are meaningfully below these, there's a placement or design fix available.
Restaurant QR FAQ
How big should a QR code be on a restaurant table tent?
2.5 × 2.5 inches is the reliable default for a seated guest scanning at 18-24 inch distance. Smaller QRs (under 2 inches) fail in low-light dining rooms, which most casual and upscale rooms are by design. For wall-mounted signage at 4-5 feet away, scale up to 3 × 3 inches or larger using the 1:10 rule (QR size = scan distance ÷ 10).
Do I need a dynamic QR for a restaurant menu?
Yes, for almost every restaurant. Dynamic QRs let you update menu prices, availability, and hours without reprinting table tents. The whole point of moving off paper menus is menu-update velocity, which static QRs don't give you. The only exception is a very short-lived pop-up where the menu literally won't change.
Does a QR menu replace the server?
No — it changes what the server does. The server stops being a menu-delivery system and a check-close-processor, and gets more time for hospitality, upsell conversations, allergen questions, and covering more tables per shift. Done correctly, a QR menu lets servers handle 20-30% more tables per night without degrading guest experience. Done wrong (where servers are still hand-delivering menus to QR-capable tables), it just adds a step.
Can I use a QR menu for a fine dining restaurant?
Almost never at the table. Fine dining's value proposition includes the ritual of menu presentation — replacing that with a self-scan breaks the experience. Where fine dining CAN use QRs: wine list and spirits reference cards (physical pour menus with a QR for the full 200-bottle list), takeout and catering pages linked from business cards, and reservation QRs near the door.
Will guests actually scan a QR menu or ask for paper?
Ballpark: 60-80% of guests scan in full-service casual, 30-50% in counter-service, lower for older demographics and fine dining. If your demographics skew older (65+), keep paper available on request but don't default to it. Scan rate is a placement and design problem more than a demographic problem — rooms with the QR obviously placed and a clean mobile menu page consistently see high scan rates across age brackets.
What happens to the QR menu when the WiFi goes down?
The guest's phone loads the menu over cellular data — WiFi going down doesn't break QR scans as long as the hosting provider's servers are up. This is actually more resilient than traditional POS terminals. The failure mode to plan for is the hosting provider's downtime (rare but real) or a menu-page bug after a rushed update. Mitigation: keep one laminated backup menu per section for emergencies.
Can I put the QR inside the printed menu for a hybrid approach?
Print it on the FRONT cover, not the inside. Guests who don't open the menu (regulars, decisive orderers) still see the QR, and guests who do open see it twice. Inside-cover placement loses the first population entirely. A hybrid with paper menu for those who want it plus outside-cover QR captures both audiences.
Is a QR order-and-pay setup PCI compliant?
It can be, depending on implementation. The clean path: redirect the QR menu to a PCI-compliant hosted checkout (Stripe, Square, Toast) for the payment step — your PCI scope stays at SAQ-A. Don't build inline payment forms on your own menu page unless you have dedicated compliance resources (that moves you to SAQ-A-EP or SAQ-D, significantly more work).
How do I measure if the QR menu is working?
Track four numbers: (1) seated-party scan rate (target 60-80% full-service), (2) scan-to-first-order-click time (target under 90 seconds), (3) table-turn time with vs. without QR scans (target 5-10 minute reduction), (4) peak-hour scan coverage (should match weekday midday coverage; if it doesn't, server interference is the likely cause). Ignore total scan count — it's a vanity metric.
Can I use one QR code for all my restaurant locations?
Technically yes, but you'll regret it. Each location's menu, hours, and pricing will diverge over time (different landlord hours, local price adjustments, regional menu items). A per-location dynamic QR lets you manage each menu independently and — if you use QRLynx's smart redirect rules — route a single QR to different menus based on the user's location. The one-QR-for-everything path forces you to either standardize harder than you want to, or build a location-detection layer yourself.
Should every table have its own QR code or can tables share one?
For read-only menus, one shared QR per section is fine. For order-and-pay, each table needs its own QR (or a tabletop identifier inside the URL) so the kitchen knows where to deliver the order. The common pattern is ONE table tent per table with a URL parameter like ?table=12 — then your menu page reads the parameter and the POS knows which table submitted the order.
Do I need Wi-Fi for guests to scan a QR menu?
No. Modern smartphones have enough cellular data coverage in most developed markets that guests don't need your WiFi for scans. Offering WiFi is still a hospitality move and helps page-load speed for guests on slow cellular networks, but it's not a technical requirement for the QR menu to work.
Where to go next — linked guides & QR types
Restaurant QRs connect to three parts of the QR knowledge graph. If the immediate question is which physical surface your QR lives on, start with the material guides: table tents are card-stock at 3 × 3 inches printed on laminated paper, and that pattern is covered in the business cards guide (same material, same finish decisions, same durability). Window stickers and wall graphics for drive-thrus follow the sizing math in the posters guide. Takeaway stickers on bags fall under the packaging guide.
If the question is which QR type to use for the specific action, the answer for a restaurant menu is almost always a dynamic URL QR code pointing to your hosted menu. For loyalty and email capture layered on top, add a lead-form QR or the lead-form feature built into the menu page. For WiFi access (especially in cafés), a separate WiFi QR code on a card at each table outperforms printing the password on a wall.
If you're running multiple locations or a franchise, the smart redirect rules guide covers the pattern where one QR routes to different menus based on user location, language, or time of day — useful if you want a single QR on franchised-in materials that customizes to the specific store. For time-limited menu items (happy hour, seasonal drinks, lunch-only), expire rules auto-retire the special menu at the right hour without manual intervention.
One last pointer: before you print any table tents, run the QR through the analytics setup so the first scan from the first guest is tracked. Operators who retrofit analytics after the print run lose the first three months of baseline data, which is exactly the period when the QR's performance is diverging fastest.
By QRLynx Team · Last updated: