Search for “QR menu vs PDF” and you mostly find vendor pages casting the PDF as the villain. The honest version is more useful than that. Plenty of restaurants run a PDF menu on their website with a code on the table pointing at it, and for some of them that is a perfectly reasonable setup. For most it costs something quietly: a few guests who give up while it loads, a price that stayed wrong for three weeks, an allergen question the floor answers from memory. Here is the comparison across eight concrete dimensions, including the cases where the PDF wins.
First, an honest definition
A PDF behind a QR code is a QR menu. Technically, without qualification. The guest points a camera, a link opens, they read the menu on their phone — same gesture, same result. Anyone telling you otherwise is selling something. So the question is not whether to use a QR code; nearly everyone in this debate agrees on the code. The question is what sits on the other end of it: a document built for a sheet of A4, or a web page built for a phone held over a table.
That sounds like hair-splitting until you sit at your own table and try it. A PDF is a fixed layout. It knows nothing about screen width, nothing about the language your guest reads, nothing about the sea bass running out at 20:40. A menu page is structured information — dishes, prices, allergens, availability — rendered for whichever device asks for it. Everything below follows from that single difference.
QR menu vs PDF: eight dimensions, side by side
These are the places the gap shows up during actual service, rather than in a feature table.
- Load time: a print-quality PDF is often several megabytes and downloads in full before anything appears. A menu page shows text first and is readable on weak patio Wi-Fi long before a PDF would finish.
- Readability: a three-column A4 layout on a six-inch screen means pinch, zoom, drag, lose your place. A mobile menu sets type at phone size and puts prices in a column the eye can scan in one pass.
- Updates: changing a PDF means opening the source file, exporting, uploading and swapping the link. Changing a live menu means tapping the price and typing the new one.
- Translations: a PDF is one language, or it is several PDFs behind several codes. On a menu page the guest switches languages themselves — AI translations, hand-tunable string by string, sit on the Premium plan.
- Allergens: in a PDF they are footnote numbers the guest has to decode. On a menu page all 14 EU allergens and dietary badges live on the dish itself, and that is included in the free plan.
- Sold out: a PDF cannot know. On a live menu you mark the dish sold out and it greys out for everyone who has the menu open.
- Analytics: a PDF tells you nothing at all. Scan analytics — how many opened it, roughly where and when — come with Premium.
- Caching: the one nobody warns you about, and the one that deserves its own section.
The caching trap
Replace a PDF with a new version at the same address and a surprising number of guests still get the old one. Phone browsers, mobile networks and any CDN in front of your site cache documents generously; a PDF looks like a static file, so it gets treated like one. Rename the file to force a refresh and you have just broken the code on every table. That is the bind in one line: cache-safe means a new URL, and a new URL means reprinting.
It is also why our QR code contains a permanent short link rather than the menu address itself. Rename the menu, redesign it, move it to a custom domain on Premium — the printed code keeps resolving. Many tools encode the URL directly, which works fine right up until the day the URL changes.
The update cycle is the real cost
Everything above is a symptom. The cause is the length of the loop between deciding to change something and a guest seeing it. With a PDF that loop runs through designer, export, upload and crossed fingers. It costs an hour of somebody's day, so you batch changes — and because you batch them, you stop making the small ones at all. The seasonal dish waits for the next export. The extra eighty cents on the ribeye gets a sticker. Over a year, a menu that is expensive to change becomes a menu nobody changes.
On a live page the loop is seconds long and can be closed from a phone at the pass, mid-service, without asking anyone for a file. That is the difference owners actually feel six months in — not any single feature on a comparison page.
When a PDF is genuinely fine
Honest answer: sometimes it is. If you serve one fixed tasting menu that changes twice a year, beautifully set, in one language, with allergens discussed at the table by a host who briefs every seating — the PDF is barely costing you anything. Same for a wine list a sommelier walks guests through anyway, or a bar with six drinks on it. The PDF's weakness is churn. Where nothing churns, the weakness never surfaces, and you are better off spending the effort somewhere it shows.
The moment to reconsider is when any of these become true: prices move more than twice a year, dishes run out mid-service often enough that staff correct guests verbally, a meaningful share of your guests read another language, or the allergen question at table six takes longer than a sentence to answer.
How the migration actually goes
Moving over is a smaller job than the decision to move. Upload a photo or the PDF of your current menu and the AI extraction drafts the sections, dishes, prices and descriptions from it. You review — this part is worth doing slowly, because even a good draft will occasionally attach the wrong garnish to the wrong plate — then confirm, add the allergen badges, and print one code. Live in minutes, built from the artwork you already have.
Keep the printed menus if you like them; plenty of places run both, paper in the hand and a code on the table for the guest who wants it in their own language. The free plan covers one complete menu with the permanent QR code, allergen tags and instant updates, no credit card, which is enough to test the whole idea on a quiet Tuesday and watch whether your guests actually use it.