QR codes for restaurants: from menu to reviews

A restaurant touches a QR code at almost every stage of the visit — table, receipt, delivery bag, review request — and each of those touchpoints has a different right answer for static versus dynamic, and for what the code should point to.

Why the menu code must be dynamic

Menus change more often than table tents get reprinted. Seasonal items rotate, prices move, a dish gets pulled when a supplier runs out, and none of that should require new laminated cards on every table.

A dynamic QR code encodes a short redirect link instead of the menu URL itself. When the menu changes, you edit the destination in your dashboard and every printed code — table tents, window stickers, receipts — starts resolving to the new page immediately, with nothing reprinted.

A static code baked with today's PDF link works fine until the file moves, gets renamed, or the menu needs a full redesign. At that point the only fix is new artwork on every table, which is the exact cost a dynamic code exists to avoid.

What to point it at: a fast page or a lightweight PDF

A mobile-first web page beats a PDF for almost every restaurant menu. It loads fast on cellular or weak café WiFi, scales to any screen, and lets you update individual items without regenerating a whole document.

If you do use a PDF, keep it small — a scanned, image-heavy menu can run into tens of megabytes and take a painfully long time to open over congested guest WiFi, which is the opposite of what a QR code menu is supposed to deliver: an instant answer to "what can I eat".

• Prefer a lightweight HTML menu page over a scanned PDF
• If a PDF is unavoidable, compress images and keep it under a few megabytes
• Test the destination on a phone with WiFi throttled, not just on your office connection

One code per table vs one code per venue

A single venue-wide code is simpler to print and manage, but it collapses all your scan data into one line. A code per table costs a little more design and print work but lets you see which tables scan most, at what times, and how demand shifts across the room — without ever asking a guest who they are.

This is table-level analytics, not guest profiling: you are counting scans against a table number, not attaching them to a person. That distinction matters both for privacy and for how useful the data actually is — you learn about your floor plan and service flow, not about individuals.

Allergen and legal information belongs on the page

Many jurisdictions require allergen and nutritional disclosures on menus, and rules differ by country and sometimes by region — check what applies to your venue locally rather than assuming; this is a general pointer, not legal advice.

Whatever the requirement, put that information on the destination page rather than trying to cram it onto the printed code artwork. The QR code's job is simply to get the guest to the page reliably; the page's job is to be complete, current and compliant, and a dynamic code lets you update that page the moment a recipe or supplier changes.

Placement: table tent to delivery bag

• Table tent or laminated card for dine-in menu access
• Window sticker for walk-up and takeaway customers
• Receipt footer to drive a post-meal review or loyalty signup
• Delivery bag or box sticker linking back to the online menu for repeat orders

The review-request flow

A post-meal QR code — on the receipt or a small table card — that opens a review landing page listing your Google, Yelp or platform-specific review links is one of the simplest ways to collect honest feedback at the moment satisfaction is highest.

The one rule that matters here: never gate or filter who sees the request based on how the visit went. Sending happy guests to a public review site and unhappy guests somewhere else is review gating, and it is explicitly against the policies of major review platforms. Put the same code and the same page in front of everyone, every time.

Guest WiFi as a separate static code

The WiFi code should live on its own card, separate from the menu. Once your network name and password are set, they rarely change, and the WiFi standard encodes those credentials directly into the code — there is nothing to redirect and nothing to update remotely, which makes it a textbook static use case.

Keep the WiFi and menu codes visually distinct on the table so guests don't scan the wrong one expecting food and getting a network prompt.

Multilingual menus, one code

You don't need a code per language. A single dynamic code can point to a page with a language switcher, or the destination can route by the guest's device locale automatically. Either approach keeps the printed artwork identical across every table and every language, so you only manage one physical asset per touchpoint.

Measuring what matters

Scan analytics on a dynamic code tell you scans over time, peak hours and device mix (mostly iOS versus Android, which affects which browser your menu page needs to render well in). Used per table, that data shows which sections of the restaurant see the most traffic and when — useful for staffing and for deciding where a code is worn out and due for reprint.

Operational hygiene for printed codes

1. Laminate any code that will be wiped down or handled daily
2. Keep the quiet zone — the blank margin — intact through any die cut or fold in the card
3. Re-test the printed code with a phone after every reprint run, not just the design proof
4. Keep one spare printed sheet on hand so a damaged table tent can be replaced same-day

When the menu URL changes

If you migrate your menu to a new site, a new page builder, or a new PDF host, edit the dynamic code's destination — never reprint the table tents for a URL change alone. This is the entire reason to use a dynamic code for the menu in the first place: the printed square stays valid, and the update happens once, centrally, in your dashboard.