How to Create a QR Code Menu for Your Restaurant

Before you start

Three things make the difference between a thirty-minute job and a week of revisions.

• The current menu in text form. Not a photograph, not last year's PDF -- the actual current items, sections, and prices. If the only current version is in the head of one person, that conversation is the real first step.
• A decision about photos. Photographing some dishes and not others makes the un-photographed ones look like an afterthought. Either commit to a consistent set or use none.
• Someone who can answer allergen questions. If you serve in the EU or UK this is a legal input, not a nice-to-have.

Step 1 — Build the menu as items, not as a document

The single decision that determines what your menu can do later: is it a set of structured items, or is it a file?

A file -- PDF, image, or a design exported from a layout tool -- can be displayed and nothing else. A structured menu can be filtered by dietary need, translated, priced in a second currency, indexed by a search engine, and read by a screen reader. It can also have one price changed without anyone opening a design tool.

Practically, that means entering categories, then items, then per-item detail: name, description, price, allergens, dietary flags, and any variations. It is more work on day one and less work every day after.

If you already have a printed menu or a PDF, an import step can usually extract the items for you. Treat whatever comes back as a first draft: extraction reliably gets names and prices right and reliably needs a human eye on descriptions and anything allergen-related.

Step 2 — Choose a dynamic code

A static QR code encodes the destination inside the pattern. Change the destination and it is a different code, which means new artwork and a new print run.

A dynamic code encodes a short redirect that the platform controls. The printed square is permanent; what it points at is not.

For a restaurant this is not close. Prices move, dishes are dropped, seasons change, and the whole argument for a digital menu is that those changes cost nothing. A static code re-introduces the reprint you were trying to avoid. The full comparison, including the reprint maths.

Step 3 — Generate and export properly

The export settings matter more than the design does.

• Format: SVG or PDF for anything printed. Vector stays sharp at any size. PNG only if your printer insists, and then at 1000x1000px or larger.
• Resolution: 300dpi minimum for print.
• Error correction: level M or H. Higher error correction means more of the pattern can be damaged, smudged, or curved around a table tent edge and still resolve.
• Contrast: dark code on a light background. Inverted codes scan unreliably on many phones, and a low-contrast brand palette fails in a dim room.
• Quiet zone: leave the clear margin around the code alone. Designers routinely crop it to make the square look tidier, and it is functional space.

On branding: a logo in the centre is usually fine because error correction covers the loss, but a gradient fill across the whole pattern is not. If you brand the code, re-test it after branding rather than assuming it survived.

Step 4 — Put it where guests will scan it

Size follows from distance: a QR code scans reliably from roughly ten times its own width, so divide the scan distance by ten to get the minimum.

Add words. "Scan for our menu" under the code measurably outperforms a bare square, because a bare square in a restaurant could be a loyalty scheme, a payment link, or a wifi code.

Material matters too: matte over gloss, waterproof if it lives on a table, and mounted where a guest looks rather than where the tent stands upright most easily. The full print guide covers materials and finishes.

Step 5 — The five-scan check

This is the step everyone skips, and it is the only one that catches problems while they are still free to fix.

Print one test card at final size on the final material, put it on a real table, and scan it five times:

1. 1On an iPhone, seated, in the room's normal evening lighting.
2. 2On an Android phone, same position. Camera behaviour differs more than people expect.
3. 3On the oldest phone anyone on the team owns.
4. 4With a cracked or heavily scratched screen if you can find one. Guests have them.
5. 5On the venue's guest wifi rather than mobile data, if the room has poor signal -- which is the actual condition in a lot of basements and stone-walled dining rooms.

You are checking three things: that the code resolves, that the page loads fast enough that nobody gives up, and that the first thing on screen is the menu rather than a cookie banner, a language picker, or a request for a table number.

Step 6 — What to change in week one

Resist redesigning anything for the first week. Watch instead.

• Are guests scanning at all, or are servers still handing out paper by default? If it is the second, the issue is the floor briefing, not the menu.
• When do the scans happen? A cluster in the first few minutes after seating is the normal pattern; scans spread evenly through the service usually mean people are re-checking something they could not find.
• Which language are guests choosing, if you published more than one?
• How many guests ask for a paper menu? That number is real information, not a failure.

One change at a time after that, with a week between changes, or you will not know which one did anything. What the analytics can and cannot tell you is worth reading before you draw conclusions from a small sample.

The mistakes worth naming

• Pointing the code at a PDF. It preserves every problem a printed menu had and adds a pinch-to-zoom.
• Using a static code because it was free, then reprinting the whole floor in month three.
• Cropping the quiet zone around the code for design reasons.
• Publishing a half-entered menu. Missing prices and empty sections read as broken, and an empty menu page is worse than no page at all.
• Removing every paper menu on day one. Keep a few and tell the staff they exist -- see QR menu accessibility.
• Letting AI-drafted allergen or nutrition values reach a guest without a person checking them.

The pattern across all of them: an irreversible print decision made before a reversible data decision. Get the menu right, then print.