A Restaurant Menu QR Code Done Properly

The menu QR code has a bad reputation, and it earned most of it honestly. A table tent, a code, and then a document that opens at the size of a postage stamp while the person you are with waits for you to finish pinching at it.

The technology is not the problem. Almost every bad menu code fails for one of five reasons, and all five are avoidable in an afternoon.

What diners actually hate

• A PDF that opens as a shrunken page. A document designed for A4 does not become a phone screen because it is on a phone. This is the single most common complaint and it is a format choice, not a technology problem.
• Being asked to sign in before seeing the food. An ordering platform that demands an account, a phone number or a marketing opt-in before showing a price. People put the phone down.
• A dead link three months later. The menu moved, the trial expired, the agency that set it up stopped answering. The code is still glued to the table.
• No paper option at all. Some people have no data, a flat battery, or simply do not want to read a menu on a phone at dinner. Removing the choice entirely is what turned opinion against these codes in the first place.
• A code that will not read. Glossy laminate under a spotlight, or a code printed too small on the corner of a card.

Fix those five and nobody notices your menu code, which is the goal. Nobody has ever praised a restaurant for its QR code.

A PDF or a proper page?

This is the decision that determines whether people can actually read it, so make it deliberately.

• A PDF is what you already have, it keeps your typography exactly as designed, and it takes about a minute. The cost is that a phone treats it as a document: fixed layout, pinch to zoom.
• A hosted page reflows to the screen, so the text is readable without zooming and the whole thing scrolls like anything else on a phone. It takes longer to set up and your designer will have opinions.

If the PDF route is the right one, the PDF QR code builder shows a branded page with your name on it first, and the file opens from there. The scan lands somewhere that looks like your restaurant, not on a bare download.

A reasonable rule: if your menu is a designed object that changes twice a year, PDF is fine. If people are reading it at a table, in low light, with the dishes changing weekly, build the page.

Changing prices without reprinting anything

This is the part worth understanding before you print a hundred table tents.

A plain code carries the address inside the pattern itself. Change where the menu lives and every printed code is wrong: new stickers, new stands, new cost.

A PDF or dynamic code points at an address you control. Swap the file, edit the page, change the whole menu for Ramadan: the printed pattern is untouched because only the thing behind it moved. Seasonal menus and a price rise stop being a print job.

The trade-off is a real dependency, and worth going in with your eyes open. Dynamic versus static QR codes sets out both sides, including what happens to a printed code if you stop paying for the service behind it.

For a menu you host yourself and simply want to be able to redirect later, a dynamic link code does the same job without the file living with us.

Printing a table tent that scans

Restaurant conditions are harder than they look: dim light, laminate, a stand that sits in the middle of a four-top with somebody leaning across it.

• Size it for the far side of the table. The usual guide is about a tenth of the reading distance. Someone leaning in is 30 cm away and three centimetres is enough; the person opposite is closer to 70 and will want five or six. Print it bigger than the mock-up looked like it needed.
• Leave the blank margin alone. The clear space around the pattern is part of the code. Running a border or a line of text right up to its edge is a classic reason a code refuses to read.
• Matte, never gloss. A laminated card under a downlight is a mirror, and a mirror does not scan. Matte stock costs the same.
• Dark pattern, pale background, nothing behind it. A code over a photograph of a burger looks wonderful in the design file and fails on the table. Pale grey on cream is the other popular way to lose.
• Test it the way it will be used. On a cheap old phone, at your actual table, under your actual lighting, at night. Not on the designer's monitor.

If a printed code is refusing to read, the cause is almost always on a short list: nine reasons a QR code will not scan runs through them in order of likelihood.

What to put beside it

• The word “Menu”. A bare code gives nobody a reason to lift their phone.
• Your Wi-Fi details, or a second code for them. A menu code is useless to a guest with no data, and this is the most common cause of a scan that goes nowhere.
• A line saying paper menus are available. It costs nothing and it removes the whole objection.

Knowing whether it is working

A hosted menu code counts its scans: how many, when, and roughly where from. That is enough to answer the questions actually worth asking: whether the terrace stand earns its space, whether lunch scans at all, whether the new tents made any difference.

The same visitor scanning twice at one table is not counted twice, and link previews and scanners are left out, so the number is closer to real people than a raw hit count would be. What it cannot tell you is which dish anyone looked at. Nothing honestly can.

Readable on a phone, changeable without a reprint, printed matte and big enough, and paper still behind the host stand for anyone who asks.