How to Make a QR Code for a Restaurant Menu

Plenty of restaurants swapped the laminated menu for a small square on the table, and most of the setup was guesswork. Owners treat the QR code as if it were the menu, when it is only a pointer to one. Get the pointer and the printing right and the code works for years without a second thought. Get them wrong and every table turns into a support ticket: guests squinting, rescanning, or flagging a server because the square did nothing.

A menu QR code is two decisions stacked on top of each other. Where the menu lives, and what the code encodes to reach it. Neither of those has anything to do with the black-and-white pattern itself, which is the part people spend the most time worrying about.

This post covers hosting the menu, the static versus dynamic choice that trips up most owners, how to print a code that survives a real table, and the cases where a QR menu is the wrong call.

What a menu QR code actually holds

A QR code is an encoded string of text. For a menu, that string is a web address and nothing else. The pattern does not hold your dishes, your prices, or a PDF. It holds a line like https://yourplace.com/menu, drawn as modules a camera can read. When a guest points a phone at it, the camera decodes the string, recognizes it as a URL, and offers to open it in the browser. The menu is then fetched over the internet the same way any web page loads.

That split is the whole idea. The code's only job is to carry a short, correct address. Everything a guest actually reads lives somewhere else, at that address. Once you see it that way, the order of operations is obvious: publish the menu first, get its final URL, then generate a code that points at it. Building the code before the menu exists is how people end up with a square that points nowhere.

Host the menu before you make the code

The menu needs a home on the public internet. There are two common shapes for that home.

The first is a web page. This is a page on your own site or a simple hosted page somewhere. It reflows to fit a phone screen, it is fast to load, and you can edit a price in seconds. For most restaurants this is the better long-term option because updates are painless.

The second is a hosted PDF. This is your existing menu design saved as a single PDF file, uploaded to a public URL. It keeps your exact layout and fonts, which matters if the menu is heavily designed. The tradeoff is that a PDF does not reflow, so guests pinch and zoom on a phone.

If your menu only exists as photos, as separate image files, or as design exports, combine them into one file before you host anything. Turning a set of menu pages or a scanned sheet into a single document is a quick pass through a tool like JPG to PDF, and the result is one clean link you can host and aim the code at.

Whatever you host, the address has to be public. Test it in a private browser window on your phone with wifi turned off, so you are seeing what a stranger sees. If it loads with no login and no app prompt, it is ready. If it asks anyone to sign in first, it is not a menu link yet.

Static versus dynamic: the choice that matters

There are two kinds of menu QR code, and the difference is not something you can see. It is what the code points at.

A static QR code encodes the destination directly. The URL is baked into the pattern. Scanning it sends the phone straight to your menu with nothing in between. A static code never expires, needs no account, and costs nothing to keep alive. Its one limit is that you cannot change where it points after printing, because the address is in the ink. If the URL itself changes, you print a new code.

A dynamic QR code encodes a short redirect URL owned by a service. Scanning it lands on that service, which forwards the phone to whatever destination you have set. You can edit that destination later without reprinting, and the service logs every scan: time, rough location, device type. That flexibility is a subscription. Stop paying and the redirect stops working, which takes every printed code down with it. The redirect also means each guest passes through a third party on the way to your soup.

Here is the part most owners miss. You almost never need a dynamic code for a menu, because a static code pointing at a stable URL is already editable where it counts. Change the dishes, adjust the prices, swap the entire PDF sitting at that address, and the printed code keeps working untouched. The URL stays the same while the content behind it changes. You only reach for a dynamic code when the destination address itself has to move, or when scan analytics are worth a recurring bill and an extra hop in the path. For a table tent, static is the safe default and the cheaper one.

Printing a code that survives a table

A menu code lives in a rough spot. It sits in a table tent under warm light, gets handled, gets spilled on, and sometimes gets laminated. Codes that look perfect on a screen fail here for physical reasons, so a handful of print rules keep the scan rate high.

Size comes first. Print the code at least 2 to 3 cm on a side for something a guest holds, and larger for a code read across a table. The working rule is a ratio: scanning distance should be no more than about ten times the code's width. A 3 cm code reads comfortably at arm's length. Shrink it to squeeze onto a crowded card and phones start missing it.

Contrast is not optional. Use dark modules on a light background. Cameras read the code by the contrast between the dark and light cells, and dark-on-light is what every scanner is tuned for. Reversing it, or picking a low-contrast pair like navy on black or pale yellow on white, drops the read rate hard. If you want to brand the code with color, keep the modules dark and the background pale.

The quiet zone is the blank margin around the code, and it is not decoration. It is the frame that tells the camera where the code ends and the table begins. The standard is a clear border about four modules wide. Crop it tight against text or a printed border and scans slow down or fail outright. Leave the whitespace alone.

Error correction is your insurance. QR codes carry built-in redundancy so a damaged code still decodes. The standard defines four levels, L, M, Q, and H, recovering roughly 7, 15, 25, and 30 percent of the code. For a table tent, print at Q or H. The higher setting survives a coffee ring, a greasy fingerprint, a scratch, or the glare bouncing off a laminate sheet, all of which are ordinary wear on a restaurant table. The cost is a denser pattern, which is exactly why size and quiet zone matter more once you turn correction up.

Format matters at the print stage too. Export from a vector file whenever the printer accepts one, so the code stays sharp at any size instead of turning fuzzy when scaled. The choice between a vector file and a high-resolution raster has real consequences for a printed code, and it is worth reading PNG, SVG, or PDF for a printed QR code before you send the artwork off.

None of this replaces a test. Before you print a hundred tents, print one and scan it with a cheap phone, an old phone, in dim light, from across the table. If the worst phone in the building reads it, the code is finished.

When a QR menu is the wrong call

A QR menu is a convenience, and there are ways to turn it into an obstacle.

Do not bury the menu behind an app install. If scanning sends a guest to an app store instead of the menu, most people set the phone back down. The menu has to open in the browser the phone already has, with no download in the way.

Do not route through a tracking redirect you do not actually use. Every hop between the scan and the menu is another point of failure and another second of loading. Unless scan analytics genuinely earn their keep, point the code straight at the menu and skip the middle layer.

Do not point at a file that needs a login. A menu locked behind a sign-in wall, a shared-drive permission, or an account is not a menu anyone can read. The link has to be public and anonymous, full stop.

Do not throw away the paper entirely, either. Some guests have no phone, a dead battery, or a cracked camera. Keeping a couple of printed menus at the host stand costs nothing and covers the gap. The square on the table should never be the only way in.

How the ReezoAI QR code generator handles it

The QR code generator on this site makes static codes, which is exactly what a restaurant menu wants. You paste your hosted menu URL and the tool encodes that address directly into the pattern. There is no redirect and no account in the path, so the code never expires and nothing sits between the guest and the menu.

The controls line up with the print rules above. You set the error correction level, so a menu tent can go out at a high setting that shrugs off a smudge or a glare. You control the quiet-zone margin, so the code keeps the frame it needs to scan. And you export as PNG for a fast proof, or as SVG or PDF for the print shop, so the code holds its edges at whatever size the table card calls for. The code is generated in the browser, so your menu URL and the finished artwork stay on your own device.

The short version

A restaurant menu QR code is a small pointer to a menu that lives somewhere else. Host the menu first, as a web page or a public PDF, confirm it opens with no login and no app, then encode that URL into the code.

For a table tent a static code is almost always the right call. It never expires, costs nothing, and stays editable where it matters, because you change the menu at the URL rather than reprinting the code. Print it dark on light, at a genuine size, with the quiet zone intact and error correction set high, then scan a test copy on the worst phone you can find before you commit to the full run.