QR codes for restaurants: menus, reviews and payments that get scanned

Restaurants were the proving ground for QR codes, and most of what fails about them was discovered on a sticky table somewhere. This is the playbook that survives contact with real service: spills, dim lighting, impatient guests and a menu that changes on Thursdays.

The thread running through all of it: the code is the easy part. Durability, placement and what happens after the scan decide whether anyone uses it.

The menu code

Point a static code at a stable URL you control, like yourplace.com/menu. When the menu changes, you edit the page and every printed code keeps working. Codes that encode a PDF's direct upload link break the first time someone re-uploads the file under a new name.

On the destination itself, a mobile page beats a PDF. Pinch-zooming a three-column PDF designed for print is the single most common complaint about QR menus. If a PDF is all you have, make it single-column and large-type.

Keep a few paper menus regardless. Dead batteries, older guests and accessibility all argue for a fallback, and servers shouldn't have to debug a phone at the table.

Surviving the table

Cardstock table tents look fine on day one and wilt within a week of wipe-downs. Synthetic paper holds up for months, and an acrylic holder with a replaceable printed insert is the cheapest sustainable setup: when the insert fades, you swap a piece of paper instead of reprinting tents.

Skip gloss lamination. Under a table spotlight it turns into a mirror at exactly the angle a seated guest scans from. Matte film wipes down nearly as well without the glare.

Size the code at 3 cm or larger, put it on both panels of the tent so nobody reaches across the table, and keep the area around it clean. A code competing with a cocktail photo loses.

And test the folded tent, not the flat PDF. The first version of our own table tent generator drew both panels the same way up, so every test fold came back with the reverse side upside down. We caught it later than we'd like to admit, which is why this paragraph exists.

Review codes and timing

Review requests work when they arrive after the experience: on the receipt, the check presenter or a small card by the door. A review code on the table at minute one mostly collects accidental scans.

Link straight to the review form using the official review link rather than your business profile page, so the guest lands one tap from the star rating. And ask everyone the same way; filtering who sees the request violates Google's review policies and gets detected.

WiFi and payment codes

A WiFi code on the counter or table card saves the staff from spelling out a password forty times a night. Copy the network name and password from the router settings rather than memory, mind the capitalization, and scan it once on someone else's phone before printing.

Payment codes deserve more caution than any other type. Verify the link or UPI ID character by character, set a fixed amount only when it genuinely should be fixed, and run a small live payment before the code reaches a counter. A typo here isn't a broken link; it's money going to a stranger.

Counting scans without a tracking service

Add UTM parameters per placement before generating each code: one for table tents, one for the window, one for receipts. Your analytics then shows which placement actually gets scanned and which one is wallpaper, with no subscription and no third party sitting between guests and your menu.

Common questions