Both work. That is the honest starting point — a PDF menu behind a QR code is not broken, and plenty of restaurants run one for years. But the two options fail in different ways, and the failure modes are what should decide it.
How each one behaves on a phone
A PDF is a fixed page. The phone downloads it and opens it in a viewer. It looks exactly like the printed menu, because it usually is the printed menu.
A web page reflows. Text resizes to fit the screen, sections can collapse, and it loads progressively.
| Web page | ||
|---|---|---|
| Looks like the print menu | Yes, exactly | Only if you design it that way |
| Reading on a phone | Pinch and zoom, constantly | Fits the screen |
| Load time | Whole file before anything shows | Text appears almost immediately |
| Cost to make | Free, you already have it | Free to cheap |
| Updating a price | Re-export, re-upload | Edit and save |
| Findable on Google | Poorly | Yes |
| Works for screen readers | Often not at all | Yes, if built properly |
The pinch-and-zoom problem
This is the real cost of a PDF, and it is worse than it sounds. An A4 menu on a 6-inch screen is unreadable at full width, so every customer starts by zooming in, then drags around the page to read sections, losing their place each time they zoom out to navigate.
They will do it. It is not fatal. But it is a small irritation applied to every single customer, at the start of their meal, before they have ordered — which is the worst possible moment to make somebody work.
Where PDFs genuinely win
- A visually designed menu where the layout is part of the brand and reflowing it would ruin it
- You already have the print file and need something working this afternoon
- A menu that never changes — a fixed tasting menu, a set list
- No one available to edit a website, and the menu changes rarely enough that re-exporting is fine
If that is your situation, use a PDF and stop worrying about it.
Where a web page wins
- Prices or dishes change often. Editing a page beats re-exporting and re-uploading a file, every time.
- You want to be found. A web menu can appear in Google results for your dishes; a PDF effectively cannot.
- Long menus. Sections and anchors beat scrolling a zoomed-in image.
- Photos. Loading them on demand beats a 15 MB PDF.
- Accessibility. A screen reader can read a web menu. Most PDFs, particularly exported ones, are opaque to it.
Two things that ruin either option
File size. A menu exported at print resolution can be 10-20 MB. On a slow connection that is a blank screen for thirty seconds and a customer who gives up. Export at screen resolution — under 2 MB, ideally under 1 MB.
Google Drive links. Very common, and a bad idea. Drive shows an interstitial preview page, sometimes asks for a sign-in, and behaves differently across phones. If you must host a PDF somewhere free, at least test the exact link on a phone that is not signed into your Google account.
The middle path most restaurants should take
Point the QR code at a short, permanent URL on your own domain — something like yourrestaurant.com/menu.
Then put whatever you like behind it. A PDF today, a web page next year, and the printed codes never change because they were never carrying the menu — only its address. That is the same principle behind why static codes are enough.
Without your own domain, the free alternatives in rough order of preference: a simple website builder page, a public Notion page, a Google Sites page. All are editable and all avoid the Drive interstitial.
Whichever you choose
- Test on a real phone, on mobile data, not office Wi-Fi
- Check it on an older Android, not just a new iPhone
- Make sure no login is ever required
- Keep the URL short so the QR pattern stays sparse
- Print the code at 4-5 cm for a table, and read the sign guide for placement
Make the menu code once the link is settled.