How to Make a QR Menu for a Restaurant, Step by Step

What to prepare before you generate anything

Almost every QR menu that fails does so because the destination was not ready, not because the code was wrong. Before you open a generator, have the destination settled and looked at on a phone.

You need four things, and none of them takes long:

• The menu itself, as a web page or a PDF, already published at a public URL that does not require a login.
• Your logo as a PNG or SVG with a transparent background, if you intend to brand the code.
• A decision about who updates prices, and how you will know the change went live.
• A phone that is not yours, to test with — your own device caches the page and will lie to you about load time.

PDF or a mobile page: choose by what changes

A PDF is faster to launch. If your menu already exists as a designed PDF, you can be live in ten minutes, and for a small, stable menu that is a perfectly reasonable answer.

It costs you on the phone, though. A PDF opens in a viewer rather than a browser, arrives at whatever size the page was designed for, and asks the guest to pinch and drag to read a price. Allergen notes set in eight-point type are unreadable at arm’s length on a table.

A mobile page is the better answer as soon as the menu has structure — categories a guest wants to jump between, allergens they need to filter, dishes that sell out, an offer that runs only at lunch. It is also the only version you can measure properly, because a page can tell you which section people opened and a PDF cannot.

A useful rule: if the menu changes more than once a month, or if a guest would ever want to search it, build the page. Otherwise the PDF is fine, and you can move to a page later without touching a single printed code — which is the next decision.

Always make a restaurant menu code dynamic

A static QR carries the destination inside the matrix itself. It works forever, needs no service behind it, and can never be changed. Once it is printed on a table tent, that URL is the URL.

A dynamic QR carries a short redirect address instead, and the destination behind it is a setting you can edit. The printed code never changes; where it lands does.

For a restaurant this is not a close call. Menus change — seasonally at minimum, and in practice whenever a supplier fails or a price moves. A static code commits you to reprinting every table tent, window sticker and takeaway sleeve on the day you change a single price. A dynamic one turns that into an edit.

The one genuine advantage of static codes — that they depend on nothing — matters for a Wi-Fi password or a vCard, not for a menu that already depends on your website being up.

Generate the code and brand it without breaking it

Create the code, point it at your destination, and then leave the technical settings alone unless you know what you are changing. The defaults are chosen to scan.

Branding is where menus most often get damaged, because it is the step that looks purely cosmetic. Three constraints are worth knowing, because every rule you will read about logos and colours follows from them:

• Error correction. A QR code carries redundant data so it still reads when part of it is obscured — the levels recover roughly 7%, 15%, 25% and 30% of the matrix. A logo works by sitting inside that budget. Cover more than the level allows and the code does not degrade gracefully, it stops reading.
• The quiet zone. The specification requires four modules of clear margin on all four sides. Designers reliably crop it, because it looks like empty space. It is not; it is how a scanner finds the code’s edges.
• Contrast, in the right direction. Dark code on a light background. Light-on-dark reads on some phones and not others, and a menu is exactly the wrong place to discover which ones.

Write a call to action, not “scan me”

“Scan me” tells a guest what to do with their hands and nothing about why. The words next to the code are the only thing that answers “what do I get”, and they change scan rates more than any design choice.

Say what opens: “Open the menu.” “See the drinks list.” “Check allergens.” “Order from your table.” If the code goes somewhere unexpected — a wine list rather than the food menu — say so, because a guest who lands somewhere they did not want does not scan the second code.

Keep it in the language of the room. In a place with regular international guests, two languages next to the code is worth the space it costs.

Size and placement: print it for the distance it is read from

The common rule of thumb is that a code should be about a tenth of the distance it is scanned from. A table tent read at arm’s length — roughly 30 cm — wants a code around 3 cm across. A window sticker read from two metres away needs about 20 cm, which is far larger than most people expect and the single most common reason a window code goes unscanned.

That is a starting point, not a specification. A longer destination URL packs more modules into the same square, making each one smaller and the code harder to read at the same physical size — which is another quiet argument for a dynamic code, since a redirect address is short by construction.

Placement matters as much as size. Codes fail on tables because of glare from a laminated surface or an overhead light, because a condiment set covers half the matrix, or because the tent faces the aisle rather than the diner. Sit down in your own chair and look at it from there.

Use a separate code per placement

It is tempting to make one code and print it on everything. Do not. Make one per placement type — tables, window, bar, takeaway packaging, receipt — all pointing at the same menu.

It costs nothing and it is the only way the numbers ever mean anything. One code tells you that scans happened. Five codes tell you the window sticker does nothing, that takeaway sleeves drive a third of your traffic, and that the bar list is being opened at eleven in the morning — each of which is a decision you can act on.

If you have more than one location, split by location too. Comparing the same placement across two rooms is the fastest way to find out that a problem is about the room and not about the menu.

Change prices and dishes after printing

This is what the dynamic code bought you, and it is worth having an actual process rather than doing it ad hoc during service.

Update the destination — the page or the replacement PDF — and check it on a phone before you point anything at it. Then change where the code goes, and scan a real printed code from a real table to confirm. Not the preview on your screen: the printed one, because that is the only thing that proves the code you actually have in the room resolves where you think it does.

Do the swap outside service hours where you can. A guest who scans mid-update gets a broken page and no explanation, and they will not try again.

Measure the things that are actually decisions

Total scans is the least useful number on the dashboard, and the one everybody reports. It goes up when you are busy. That is all it tells you.

The numbers that change what you do are comparative. Unique against total scans tells you whether people are re-opening the menu — which reads as interest when the ratio is mild and as bad navigation when a guest opens it six times in one sitting. Scans by placement tell you which printed surfaces earn their space. Scans by hour tell you whether the lunch offer is being seen at lunch.

Watch out for the obvious traps: your own staff testing codes inflates early numbers, and a busy Saturday makes everything look like it worked. Compare like with like — this Tuesday against last Tuesday, this table tent against that window sticker.

Check these before it goes to print

Everything below has broken a real menu. It takes about ten minutes to work through and it is much cheaper than a reprint.

• Scan the code from a printed proof, not from the screen — screen scans hide contrast and size problems entirely.
• Test on at least one Android and one iPhone, and on an older phone if you can find one.
• Test in the actual lighting of the room, including in the evening.
• Check the destination on a phone, not a laptop: tap targets, load time, and whether prices are legible without zooming.
• Confirm the quiet zone survived the layout, and that nothing is printed over the code.
• Confirm the destination is publicly reachable — not a draft, not behind a login, not a file that expires.
• Check the call to action says what opens, and is readable from the seated position.