QR Codes for Restaurant Menus: Print Size, Design, and Mistakes to Avoid

The single most common reason a menu code fails is that it was printed too small for how far away people scan it. There is a dependable rule of thumb: the minimum width of the code is about the scan distance divided by ten. A code someone holds 30 cm from their face needs to be roughly 3 cm wide. A table-tent code that sits in the middle of the table and gets scanned from 40 to 60 cm away wants to be closer to 4 to 6 cm.

That ratio assumes a clean print, a decent phone camera, and reasonable light. Restaurants rarely have all three, so round up rather than down. Dim ambient lighting, a candle on the table, a glossy laminate, a curved surface, or a long URL packed into the code all push you toward the larger end. As an absolute floor, do not print any handheld code smaller than about 2 cm (0.8 inch) no matter what the formula says — below that, older phones and cracked screens start to struggle.

For print resolution, export the code at a size that gives you at least 300 DPI at your chosen physical dimension. Our generator exports PNG up to 4000 px as well as a true SVG vector, and for anything printed the SVG is the safer choice: it stays razor-sharp at any size, so a designer can drop it into a laminated menu or a large table tent without the pattern turning fuzzy.

Every QR code needs an empty margin around it, called the quiet zone. It is not decorative whitespace a designer can trim to make the layout tighter — it is part of the specification. Scanners use that clear border to find where the code begins and ends. Crop it away and many phones simply never lock on, especially in a busy print layout where the code sits next to text, a logo, or a photo of a dish.

The rule is to leave at least four modules of clear space on all sides, where a module is one of the little squares in the pattern. In practice, tell whoever lays out your menu to keep a clean margin roughly equal to the width of one of the three corner squares all the way around the code, and to put nothing in it — no border line, no wine-glass illustration, no fold in the card. On a table tent, make sure the code is not so close to the edge or the fold that part of the margin curls away from the camera.

Scanners read the difference between dark modules and a light background. That contrast is the whole mechanism, and restaurant branding is where it quietly breaks. A code in your brand's warm taupe on a cream menu looks tasteful and scans terribly, because the two tones are too close for the camera to separate reliably in candlelight.

You can absolutely brand a menu code, within limits. Keep genuinely dark modules on a genuinely light background — the equivalent of near-black on near-white. Avoid inverting it (light modules on a dark background) unless you have specifically tested that combination on several phones, because many scanners assume dark-on-light and give up on the reverse. If you want your logo in the middle, keep it small — around 20 to 30 percent of the code's area at most — leave the three corner squares completely untouched, and raise the error correction to level H so the covered modules can still be reconstructed.

This is the design decision almost nobody warns restaurants about, and it wrecks otherwise perfect codes. A menu laminated with a glossy finish, or a table tent in a shiny acrylic holder, acts like a mirror. Overhead spotlights, a window, or the diner's own phone flashlight reflect straight off the surface and wash out part of the pattern. The code looks flawless flat on your desk and fails the moment it is on a table under a downlight.

Choose a matte or satin laminate for anything carrying a QR code. Matte scatters light instead of bouncing it back as a hot spot, so the code stays readable from more angles and under harsher lighting. If your menus are already glossy and you cannot change that, at least make the code larger than the formula suggests and position it away from the most reflective part of the sheet. The same logic applies to acrylic table-tent holders — a frosted or matte holder beats a mirror-clear one every time.

It is worth testing this in the actual room, not just at your desk. Put the finished, laminated code on a real table under your real lights and scan it from a seated position. Glare problems only appear at the angle a diner actually holds their phone.

Placement decides whether people even notice the code, let alone scan it. The best spot is a standing table tent in the center of the table, angled so it faces seated diners rather than lying flat where it catches ceiling glare and forces an awkward top-down scan. A tent that a person can pick up and tilt toward their phone will always outperform a sticker glued flat to the tabletop.

If you use a flat sticker, put it toward the near edge of the table where a seated guest can lean in comfortably, not dead center where the far side of the table is out of easy reach. Avoid the classic mistakes: a code under the glass tabletop (the glass adds reflection and a focus problem), a code on the underside of anything, or a code so low on a menu that the diner's own hand covers the quiet zone while holding it.

Give the code a reason to be scanned. A tiny line of text — "Scan for our full menu and specials" — converts far better than a bare square, because it tells the guest what they get and that it is worth the two seconds. In table service, a single well-placed tent per table beats scattering codes on every printed surface.

This is the decision that saves restaurants the most money, and it is genuinely a trade-off rather than a clear winner. A static code bakes the menu link permanently into the pattern. It is free, it works forever, and it never depends on anyone's server staying up. The catch: if your menu URL ever changes, every printed code is dead and you reprint the lot.

A dynamic code encodes a short redirect you control, so you can re-point it any time — swap in a seasonal menu, a lunch versus dinner page, a holiday special — without touching a single printed tent. You also get scan counts, which tell you how many people actually use it. The honest catch is that a dynamic code depends on that redirect continuing to work; if the service behind it goes away, the printed codes go dead too.

For a menu the practical answer is usually dynamic, and here is the reasoning: menus change. Prices move, dishes rotate, you run a Friday special. Reprinting and re-laminating table tents every time is exactly the cost QR menus were supposed to eliminate. Point a dynamic code at a stable menu page and update the destination as the menu evolves. If you would rather keep it free and never touch a server, a static code pointing at a permanent URL on your own domain (where you update the page content, not the address) gets you most of the same benefit.

Menu-code failures are boringly predictable, and almost all of them are invisible until a guest is sitting there getting nothing. The worst offender is the dead link: a static code pointing at a menu page that was moved or deleted, or a free trial redirect that lapsed. Confirm the destination is stable and, if it is dynamic, that whatever powers the redirect is one you will keep.

The rest of the list repeats across thousands of restaurants: printed too small for a table-tent distance, low-contrast brand colors, a cropped quiet zone, glossy lamination glare, and a menu page that is not built for phones so the guest lands on a slow, pinch-to-zoom PDF. Always give people a fallback — print a short, typeable URL right under the code so a failed scan still ends at the menu. And test the finished, laminated, table-placed code with two or three different phones in your actual lighting before you print a hundred of them.