On this page+
A static QR code printed on a menu is a printing-cost machine. Every menu update means a reprint. A new dish, a price change, a supplier swap, a seasonal item, a discontinued cocktail. Restaurants that printed static QRs in 2020 ended up reprinting them six times in 18 months.
A dynamic QR fixes this in 30 seconds. Update the destination URL behind the QR. The printed code keeps working. No reprint. Here is the practical guide.
What dynamic QR means for a restaurant
The setup:
- Buy a short branded domain (acme.co or similar). $10 to $20 per year.
- Generate a dynamic QR through your shortener that points at a redirector URL like
acme.co/menu. - Print the QR on the menu, table, or insert.
- The redirector points at your actual menu page, which can be a PDF on your site, a hosted menu page, or a third-party menu platform.
When you update the menu (new dishes, price changes, daily specials), you change the redirector's destination URL. The printed QR stays the same. Every customer who scans tomorrow gets the new menu.
Where the QR earns its place
Three menu surfaces worth a QR:
1. On the table directly. A plastic table-tent or stand-alone holder with the QR. Customers scan from their seat without picking up a menu. Best fit for fast-casual concepts where physical menus are minimal.
2. On the back of a printed menu. Customers see the printed menu first; the QR is a "view full nutritional info" or "online ordering" affordance. Best fit for traditional dine-in where the printed menu is the primary surface.
3. On a takeout bag insert or receipt. Customers scan after the meal for loyalty signup, online ordering history, or feedback survey. Best fit for takeaway-heavy operations.
Each surface gets its own utm_content value so you can compare which surface drove the most scans:
| Surface | utm_content |
|---|---|
| Table tent | table-tent |
| Back of menu | menu-back |
| Takeout bag | takeout-bag |
| Receipt | receipt |
| Door (entrance) | door-entrance |
Sizing and design
The 10:1 rule for QR sizing applies:
| Surface | Scanning distance | QR size |
|---|---|---|
| Table tent or stand | 30 to 50 cm | 3 to 5 cm |
| Back of printed menu | 30 cm | 2.5 to 3 cm |
| Takeout bag insert | 30 cm | 3 cm |
| Receipt | 20 cm | 2 cm |
| Door / entrance window | 1 to 2 m | 10 to 20 cm |
Restaurants suffer wear on printed surfaces (coffee, sauce, hand oil, repeated handling). Use error-correction level Q or H so the code can recover from smudges. Black on white is the safest contrast; brand colors work as long as the dark color is dark enough.
The piece on branded QR code design rules covers the contrast, logo, and color rules in depth.
What the destination URL should be
Three options, in order of how mature your menu management is:
1. PDF or web page hosted by you. Simple, free, you control everything. The PDF's URL needs to be stable; do not change the path when you update the file. Replace the file in place.
2. Hosted menu platform. Toast, Square, OpenTable, MenuTiger, and similar tools host menu pages with built-in update flows. The QR points at your platform-hosted menu URL.
3. Online ordering platform. ChowNow, Toast Online Ordering, Olo. The QR points at your ordering page so the customer can scan, browse, and order from their phone.
For most restaurants the right answer is #2. The platform handles menu management, photo hosting, dietary tags, daily specials, and price updates with no engineering involved.
What about a per-table QR for ordering?
Some restaurants use a different QR per table for table-side ordering. The QR encodes both the menu URL and a table ID:
acme.co/menu?table=12
Or a separate slug per table:
acme.co/t12
The destination page reads the table ID and routes the order to the right server. Useful for self-service models. Most full-service restaurants do not need this; the same QR on every table works fine.
If you do per-table QRs, name them programmatically: acme.co/t1 through acme.co/t40. Trakl can create these in bulk through CSV import (planned for late 2026; manually one-by-one until then).
The menu-update workflow
The whole point of dynamic QR is that updates happen without reprinting. The actual workflow when the menu changes:
- 01
Update the menu on the platform that hosts it.
Toast, Square, MenuTiger, or your own CMS. Make the changes there first. - 02
Confirm the menu URL did not change.
If it did (uncommon, but possible if you renamed the menu in the platform), you need to repoint the redirector. - 03
If the URL changed, update the redirector.
Open Trakl. Edit the menu short link. Paste the new destination URL. Save. The QR's destination is now updated; printed codes still work. - 04
Verify with a fresh scan.
Scan the QR with your phone to confirm it lands on the updated menu. Do this from the customer's seat to validate the workflow end to end.
For most platforms, the URL stays stable across updates so step 3 rarely fires. The QR keeps working through normal menu updates without intervention.
Tracking and reading the data
The scan data a restaurant gets from a dynamic QR:
- Scan count by day of week. Weekend volume vs weekday volume. Useful for staffing decisions.
- Scan count by hour. Peak hours for digital engagement (often slightly different from peak dining hours).
- Scan count by table-section utm_content. Which seating areas drive the most scans (booth vs bar vs patio).
- Mobile OS distribution. iOS vs Android of your guest base. Affects which mobile ordering platform feature set to invest in.
The number that matters most for ROI: scan-to-conversion rate, where conversion is whatever digital action your QR campaign was designed for. Online order completion, reservation, loyalty signup, feedback survey response. The conversion rate justifies the digital surface; the scan count alone is vanity.
Common restaurant-QR mistakes
- Using a static QR generator that costs $0 today and $5,000 in reprint costs over the next year. Dynamic QR is the only sensible default.
- Sizing the QR too small to scan reliably. A 1.5 cm QR on the corner of a menu might look elegant but scan reliability drops at low resolutions.
- Heavy logo overlay without bumping error correction to Q or H. Logo overlays of more than 25 percent of QR surface need the higher EC level.
- Pointing at a non-mobile-optimized menu page. A scan happens on a phone. The destination should be mobile-first or the conversion rate craters.
- Forgetting to remove the QR when the campaign ends. If you stop using dynamic QR for a season, leave the redirector live (do not delete it) until you have confirmed all printed pieces are out of circulation.
For the broader QR strategy, the QR codes pillar guide covers the static-vs-dynamic question. For the placement patterns across other industries, trackable QR for print marketing is the next read.
Frequently filed
Common questions.
Q.01What is the best QR code for a restaurant menu?+
A dynamic QR code printed on the table or back of the menu, pointing at a redirector you control. Dynamic means you can change the destination URL (the actual menu page) without reprinting the QR. The same physical card stays useful through menu updates, seasonal changes, and supply-driven substitutions.
Q.02How big should a QR code be on a restaurant table?+
3 to 5 centimeters. Tables are scanned at 30 to 50 centimeters, the 10:1 rule sets the QR at 1/10 the scanning distance. Smaller works at high print resolutions, but margins for error get thin once the print piece picks up coffee stains.
Q.03Should the menu QR code carry UTMs?+
Yes. utm_source=qr, utm_medium=offline, utm_campaign=menu, utm_content=<location-or-table-section>. Per-table-section utm_content lets you compare scan volume across booths, bar seats, patio. Useful for understanding which sections of the restaurant drive digital engagement.
By the byline
Trakl TeamEditorial team
We build Trakl, a link shortener and UTM tracker for marketing teams. We write here from the cleanup work, support tickets, and campaign reviews that fill the rest of our week. Specifics over slogans, and we cite the source.
Photo: Haberdoedas on Unsplash



