How to Make a QR Code Menu for Your Restaurant

Point the code at a stable menu URL you control, and the printed table tent survives every price change — because you edit the page, not the code. If you already have a permanent menu page, even a static QR does this. Choose a dynamic code when you also want scan numbers, or when the destination itself might move.

At a glance

The menu QR type has two modes. Link mode points at a menu URL you already run. Hosted mode takes a PDF or menu photos and builds the page for you.
A static code is fine if your menu lives at a permanent URL you control — update the page and the tents keep working. It is changing the destination that needs a reprint, not changing the menu.
Dynamic earns its place when you want scan analytics, when the URL might change, or when you have no menu page and want the code to host one.
The hosted menu page speaks 7 languages — English, Spanish, Portuguese, French, German, Italian and Dutch. That is the page furniture, not your dish names.
Free accounts show a "Powered by PixlQR" line on the hosted page. Removing it is a Plus feature, which matters more for a restaurant brand than for most.
Free uploads cap at 5 MB, which a photo-heavy PDF menu will exceed. Link mode has no such limit because we are not storing the file.

The choice depends on one question: do you already have a menu page on your own website?

Link mode points the QR code at a URL you control — yourrestaurant.com/menu, an online-ordering page, a Google Doc, anything with an address. PixlQR does not store the menu, so there is no file size limit and no second copy to keep updated. Your site stays the single source of truth.

Hosted mode takes a PDF or a set of menu photographs and builds a mobile page around them, with your restaurant name, a tagline and your logo. Use it when you do not have a menu page, or when the one you have is a desktop-shaped PDF that is miserable to read on a phone.

The honest recommendation: if you already have a decent mobile menu page, use link mode. Hosted mode exists because most independent restaurants do not have one, not because it beats a well-made page on your own site. Link mode also keeps your traffic on your own domain, which matters if you ever want that page to rank.

Does it have to be a dynamic code?

No — and it is worth being straight about this, because QR vendors are usually not.

A static code pointing at a permanent URL handles menu changes perfectly well. If your menu lives at yourrestaurant.com/menu and you control that page, you can change every price on it and the printed tents never notice. The code encodes the address, not the contents. Anyone telling you that a static code means reprinting when the soup changes is selling you something.

What a static code cannot survive is a change to the address itself: a site rebuild that moves the page, a new domain, switching to a delivery platform's menu, or a link that was always a bit temporary — a Google Doc, a Dropbox share, a PDF filename with a date in it. Then the printed pattern points somewhere dead and every tent has to be reprinted.

So the question is not "will my menu change" but "will my menu's URL change".

Dynamic earns its place in three cases:

You want scan numbers. A static code passes through no server of ours, so there is nothing to count. This is the big one for most restaurants.
You are not certain the URL is permanent, which covers most places that have not run their own site for years.
You do not have a menu page at all and want the code to host one.

There is a smaller fourth reason: a dynamic code encodes a short link, so the printed grid stays sparse no matter how long the real URL is. That matters at table-tent size, where a long address crams the modules together.

One practical note about PixlQR specifically. Our dedicated Menu type is dynamic only, because both of its modes need a record on our side to resolve. If you have a permanent menu URL and genuinely want a static code, create a URL type as static instead. What you give up is the scan numbers and the Menu workflow — not the destination, since link mode sends guests straight to your own page anyway. Hosted mode, the one that builds you a menu page, stays dynamic-only for the same reason. Going static is a legitimate choice and we would rather you knew it was available.

Full mechanics in static vs dynamic QR codes, and specifically how to change a code's destination after printing.

Setting one up, step by step

Create a menu QR code and choose link or hosted mode.
Link mode: paste your menu URL. Hosted mode: upload the PDF or the menu photographs, then add the restaurant name, a short tagline and your logo.
Design the code. Keep the contrast high and the code dark on light. Clever colour inversions are the single most common reason a code fails on a dim table.
Download as PNG for screens, or SVG or PDF for the printer. SVG and PDF are Plus features; the free plan gives you PNG and JPEG, which is fine for a table tent but will look soft if the printer scales it up.
Scan it yourself, from the printed proof, at the table. Not from the screen. Not from the artwork. From the actual card, in the actual light, on a phone that is not yours.

That last step catches almost everything: codes printed too small, codes varnished to a mirror, codes placed where the salt shaker sits.

How big should the code be on a table tent?

The working rule is that the printed code should be at least a tenth of the distance the scanner stands away from it. A guest scanning a table tent is holding the phone 20 to 30 cm away, so 2.5 to 3 cm square is comfortable and anything under 2 cm starts failing on older phone cameras.

Two things eat that margin without you noticing:

A logo in the middle. It covers modules the scanner needs. PixlQR encodes at the highest error-correction level, which is what makes a centre logo survivable, but it is a budget you can overspend.
A long destination URL in link mode. More characters means a denser grid and smaller modules at the same printed size. A dynamic code sidesteps this — the encoded short link is the same short length no matter how long the real menu URL is.

What do the scan numbers actually tell a restaurant?

More than most operators expect, because a menu code is scanned at a specific moment: someone has sat down and wants to read the menu.

Be clear about what a scan is not. It is not a cover, not a table, and not a sale. A table of four might produce one scan or four; a table that took the paper menu produces none. Scans measure interest in reading the menu, and they are useful because that number moves in patterns you can act on — not because it approximates covers served.

Scan times map your service. The shape of a Friday against a Tuesday, when the second sitting really starts, whether the pre-theatre rush is real.
Comparing table tents against the window card tells you whether passers-by are reading the menu before deciding — a different question from how busy you were.
A sudden flat line usually means a physical problem. A tent knocked behind the condiments, a card that went out with the recycling, a new varnish that kills the contrast.

PixlQR keeps 180 days of individual scan records on every plan including free, then keeps the daily totals indefinitely. A free account shows total scans, unique scans and the timeline across those 180 days, which is what the three points above actually need. The breakdowns by country and device, the live map and CSV export are Plus features, and everything is unlocked during your first 7 days. There is more on reading these numbers in how to track QR code scans.

What about guests who do not want to use a phone?

Keep paper menus. This is worth stating plainly because the QR-only dining room made a lot of people miserable and some of them are your regulars.

A QR menu is best understood as a fast path for the people who prefer it and a way to keep the menu current, not as a replacement for a physical menu. Guests without a smartphone, with a flat battery, with poor eyesight, or simply without the patience should be able to ask for a card and get one without it being awkward. Accessibility obligations for restaurants vary by country and sometimes by city, so check what applies where you trade rather than assuming a QR-only room is fine.

A sensible setup for most restaurants

If you want the short version, this is what works for the majority of independent places:

One dynamic code, in link mode if you already have a mobile menu page and hosted mode if you do not.

Three or four codes if you want to compare places — dining room, bar, window, takeaway counter. Not one per table; that is forty rows to read instead of one number.

Printed 2.5 to 3 cm square, dark on light, matte not glossy, and scanned from the actual printed proof before the full run goes to press.

Paper menus kept, because a QR menu is a fast path for the guests who want one, not a replacement for the guests who do not.

That is the whole job. The builder below makes the code — paste your menu link and you will see it appear. Keeping it carries it into a free account, where you can swap the menu whenever the prices change without touching the tents.

Frequently asked questions

Do guests need an app to scan it? Almost certainly not. Most current iPhone and Android phones read QR codes straight from the camera app — point it at the code and tap the banner that appears. Android is the less predictable half, because the camera app varies by manufacturer, so a small number of guests will need Google Lens or the shortcut in their notification shade.

Can I have a different code for each table? You can, and it is the only way to compare scan activity between areas of the room — the same logic as one code per placement for agencies. Be realistic about the cost: forty tables is forty dynamic codes, which is a Plus plan sized accordingly, and forty rows to read instead of one number. Most restaurants get what they need from three or four codes — dining room, bar, window, takeaway counter.

Will the menu page show my branding? Your restaurant name, tagline and logo, yes. On the free plan a "Powered by PixlQR" line also appears at the bottom of the hosted page; removing it is a Plus feature. If you are putting the code on a table in a room you have designed carefully, budget for that.

Does the hosted page translate my menu? No, and this is worth being precise about. The page furniture — buttons, labels, prompts — appears in 7 languages and follows the guest's phone. Your dish names and descriptions appear exactly as you wrote them. If you need a genuinely bilingual menu, upload a bilingual PDF or run a second code pointing at a translated page.

My menu PDF is bigger than 5 MB. What now? Either compress it, which is usually easy because menu PDFs are typically oversized photographs, or use link mode and host the file on your own site, or upgrade to Plus for a 50 MB limit. Free accounts cap uploads at 5 MB across every file type.

Can I change the menu without reprinting the tents? Yes, on either kind of code, as long as the address stays the same. In link mode you update the page on your own site and the code needs no attention at all — that works with a static code too. In hosted mode you upload the new PDF and the printed code serves it immediately. What needs a dynamic code is changing where the code points, not what the menu says.