Should a QR code menu link to a PDF or a web page?

A web page. PDFs force a diner to pinch-zoom on a phone, often download before displaying, and don't reflow to fit a small screen. A plain mobile-responsive HTML page loads faster, scrolls naturally, and is far easier to update than replacing a PDF file on every table's code.

Does the QR code itself need to be dynamic to update prices?

No. If the code encodes a URL and the page at that URL is what changes, the code never needs to change — only the web page's content does. This is the single most common mistake: restaurants regenerate the QR code every time a price changes, when only the destination page needed editing.

What size should a table-tent QR code print at?

At normal reading distance (30-40 cm), 3-4 cm square is enough for a short menu URL at error-correction level M. Add a small margin of quiet zone (white space) around it — camera autofocus struggles when the code runs edge-to-edge with other print elements.

Do diners actually prefer QR menus over paper?

It's mixed, and skews by age and party type — solo diners and younger customers scan readily, larger groups and diners without a phone handy often ask for a paper backup. Restaurants that removed paper menus entirely have frequently reintroduced a laminated backup after complaints; a QR menu works best as an addition, not a replacement, for at least the first year.

Guide

How to Make a QR Code Menu for Your Restaurant Table

The code is the easy 5%. The menu it points to is the part that decides whether anyone can actually order.

By Buğra SözeriPublished September 25, 2026

A QR code menu has two completely separate halves: the small square that gets scanned, and the web page it points to. Most of what makes a QR menu succeed or fail lives in the second half, which is also the half most restaurants get wrong — treating the code as the whole solution and the destination as an afterthought.

Link to a web page, never a PDF

The single biggest usability mistake is encoding a link to a static PDF of the old printed menu. PDFs are built for a full page, not a phone screen: text starts tiny, a diner has to pinch-zoom to read each section, and some phones download the file instead of opening it inline, adding a step before anyone can even see the menu. A plain, mobile-responsive HTML page — even a very simple one — reflows to fit any screen width and opens instantly in the browser the QR scan already triggered.

Let the code stay put; let the page change

This is the mental model that saves the most reprinting cost. A QR codethat encodes a URL doesn’t encode the menu’s content — it encodes the address where that content lives. Change a price, add a seasonal item, or 86 something that ran out, and none of it touches the code at all, because the code was never holding the menu’s text in the first place. The table tents printed on day one keep working indefinitely as long as the web page at that URL keeps existing at that address.

Change needed	Reprint the code?
Update a price	No — edit the page
Add or remove a dish	No — edit the page
Move to a new domain entirely	Yes — the URL itself changed
Rebrand the restaurant name	Only if the domain changes with it

See our guide on static vs dynamic QR codes for when it’s actually worth paying for a redirect service instead of a plain static link — for most single- location restaurants, a static code pointed at a stable menu URL is simpler and free.

Size, placement, and error correction

At the distance a seated diner reads a table tent (roughly 30-40 cm), a code around 3-4 cm square is comfortably scannable at error-correction level M — plenty of margin for a short menu URL. Keep a clear quiet zone of white space around the code; laminating it flush against text or a logo is a common cause of failed scans, because the camera’s finder pattern needs contrast-clean space to lock onto. If the table tent might be laminated and wiped down repeatedly, error-correction level Q or H adds resilience against scratches and glare on the laminate.

Keep a paper backup for now

Full digital-only rollouts have a consistent failure mode: the diner without a smartphone, with a dead battery, or in a large group sharing one phone. Restaurants that dropped paper menus entirely have frequently walked it back after complaints. A QR menu works best as the default, with a small stack of laminated paper menus available on request — it costs almost nothing to keep and removes the single biggest source of friction with the format.

The short version

Point the code at a fast, mobile-friendly web page — not a PDF. Treat the code and the page as separate concerns so price changes never require new printing. Size the code for table-reading distance with a real quiet zone around it. And keep a handful of paper menus on hand until QR adoption is universal enough that nobody needs to ask for one.

Frequently asked questions

Should a QR code menu link to a PDF or a web page?: A web page. PDFs force a diner to pinch-zoom on a phone, often download before displaying, and don't reflow to fit a small screen. A plain mobile-responsive HTML page loads faster, scrolls naturally, and is far easier to update than replacing a PDF file on every table's code.
Does the QR code itself need to be dynamic to update prices?: No. If the code encodes a URL and the page at that URL is what changes, the code never needs to change — only the web page's content does. This is the single most common mistake: restaurants regenerate the QR code every time a price changes, when only the destination page needed editing.
What size should a table-tent QR code print at?: At normal reading distance (30-40 cm), 3-4 cm square is enough for a short menu URL at error-correction level M. Add a small margin of quiet zone (white space) around it — camera autofocus struggles when the code runs edge-to-edge with other print elements.
Do diners actually prefer QR menus over paper?: It's mixed, and skews by age and party type — solo diners and younger customers scan readily, larger groups and diners without a phone handy often ask for a paper backup. Restaurants that removed paper menus entirely have frequently reintroduced a laminated backup after complaints; a QR menu works best as an addition, not a replacement, for at least the first year.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

ISO/IEC 18004:2024 — QR Code bar code symbology specification — Governs the symbol's error-correction levels and data capacity, directly relevant to how much a menu code can encode before needing a URL instead(as of 2026-09-25)
Web.dev — Core Web Vitals — Google's guidance on load-speed metrics; a menu page a diner scans on a phone lives or dies on these thresholds(as of 2026-09-25)
W3C Web Content Accessibility Guidelines (WCAG) 2.2 — Accessibility standard relevant to menu pages that must remain usable at small phone screen sizes and under poor lighting(as of 2026-09-25)