QR menus that actually work: a restaurant checklist

A QR menu fails silently. The customer points a phone at it, nothing happens, they try again at a slightly different angle, and then they wave a waiter over — which is exactly what the QR was supposed to prevent. Nobody complains to you about it, because from their side it looks like their phone is being slow. You find out months later, when you notice how many tables still ask for a paper menu.

The failures are boringly consistent, and every one of them is decided before you send the file to the printer. Here is the checklist, in the order the mistakes actually happen.

Size, and the margin nobody remembers. The working rule is 2×2 cm of code for every 20 cm of scanning distance. A table tent is read from 30-40 cm, so 3×3 cm is a safe floor. A poster by the entrance is read from a metre or more, which puts it at 6×6 cm minimum. But the spec people forget is the quiet zone: the blank margin around the code, which needs to be about four modules wide — roughly 10 percent of the code’s width. Crop it tight to save space, or let a border or a photo edge run into it, and scanners lose the pattern even though the code itself is perfectly printed.

Contrast, and why inverted codes look great and scan badly. Scanners expect dark modules on a light background. Light-on-dark works on some phones and fails on others, which is the worst possible outcome because it will pass your test and fail your customers. Low-contrast brand colours are the most common cause of dead menus: gold on cream, light grey on white, pastel on pastel. You can keep brand colour as long as you keep it dark — a deep purple or navy code on white scans about as reliably as pure black. Test it in greyscale: if the code nearly disappears when you drop the colour, a camera in poor light will lose it too.

Error correction, which buys you tolerance for the real world. QR codes carry redundant data, and the level you choose decides how much of the code can be obscured before it stops working. A menu card lives on a table. It will get a thumbprint of curry on it, a water ring, a crease from being wiped down. Higher error correction costs you a denser pattern but survives that. It is also what makes a logo in the middle possible at all: the logo is covering real data, and the code only still works because the redundancy absorbs it. If your generator does not raise the correction level when you add a centre image, it is handing you a code that scans on a clean card and dies on a used one.

Glare, the mistake that only shows up after service starts. Glossy lamination under warm restaurant lighting throws a specular highlight across the card, and it lands exactly where a seated guest holds their phone. The card looked fine on your desk under a window. Matte lamination fixes it for a few satang per card and is the single cheapest decision on this list. If you have already printed glossy, angle the stands so the ceiling lights do not bounce straight back up — and check it while seated, at the height a customer actually is, not standing over the table.

Placement, which is mostly about how people hold phones. One code per table beats one code at the counter, because a code at the counter creates a queue of people scanning instead of ordering. Lay it flat or at a slight angle rather than standing it vertically, where it ends up behind a sauce bottle or a napkin holder by the second sitting. And print the short link in plain text under the code — luud.link/yourmenu — so the guest whose camera app is broken, or whose phone is too old, can still type their way in. That one line of text is the difference between a QR menu and a QR-only menu, which is a worse restaurant.

Put a short link inside the code, not the raw menu URL. This helps twice. Fewer characters mean fewer modules, which means a coarser and physically larger pattern at the same print size — easier for a camera to resolve in bad light. And it decouples the printed card from the destination: when you redesign the menu next season, or move it to a new platform, you change where the link points and every card you already printed keeps working. Encode the long URL directly and the card becomes disposable the moment anything changes.

Print from vector, not from a screenshot. A QR code is geometry, so export it as SVG and let the printer scale it. A PNG sized for a web page and then blown up to 6 cm arrives with soft, uneven module edges, and the scanner has to guess where each square ends. If you only have a raster file, generate it at the final print size at 300 dpi rather than enlarging a small one.

Then test like a customer, not like the person who made it. Sit down. Use the oldest phone in the building, not your own. Try it in the lighting the room actually has in the evening, not at noon with the blinds open. Scan from the far side of the table, one-handed, at the angle you would really hold a phone while talking to someone. Try it with a smudge on the card. If it works under all of that, it will work in service.

One last thing worth doing after launch: use a code that counts its scans. A static QR tells you nothing, so a menu that is quietly failing stays invisible. A trackable one turns each scan into a number you can look at, which means you can compare table tents against the poster, notice the week the numbers drop because someone reprinted the cards glossy, and stop guessing about the thing your guests never mention.