PDF menu vs QR menu: why a PDF behind a QR code falls short
A QR code that opens a PDF menu looks like a digital menu, but to the guest it is the same paper menu on a small screen. This article shows what actually happens on the phone, what you lose in Google, price changes and guest data, and how to move to a real web menu in one afternoon.
In short
- A PDF is made for print. On a phone guests zoom, scroll sideways and wait for the file to download.
- Google can index PDFs, but it needs a special parser to read the text, while HTML is plain text. A menu as a web page is easier to find and to read.
- Every price change in a PDF means a new file, a new upload and the risk that guests see the old version.
- A web menu gives photos, allergens, languages, sold-out switches and statistics, and it is the way into online ordering.
- Switching is easy: photograph or upload your PDF and import it with AI, then check and correct it. See how the Menuto QR menu works.
What a guest sees when a QR code opens a PDF menu
The guest scans the code and the phone downloads a file. On a weak signal in a cellar, on a terrace or in a mountain hotel, that can mean several seconds of a blank screen. Then a page laid out for an A4 sheet opens, and the text is so small that zooming is the only option.
A zoomed PDF runs off the screen, so the guest drags left and right to read the line with the price. With a multi-page menu they scroll to find a category. This is not a rare annoyance, it is everyday life in every venue that uploads its menu as a file.
A designer PDF with high-resolution photos is heavy. A scanned or photographed menu is just a picture: the text cannot be selected or searched. And there is one language: if the menu is in Bulgarian, a tourist who relies on automatic translation gets nothing from an image.
Six problems of a PDF menu on a phone
Each one is small. Together they explain why guests fall back on the waiter with the question "what do you have", although you paid for a digital menu that should do that job.
Zooming and draggingReadability
The page is A4, the screen is small. The price sits at the other end of the line.
Downloading a fileSpeed
The file has to arrive before a single line is visible. Heavy files slow things down most on a weak connection.
One languageLanguages
A second language means a second file or text on the same page. Tourists rarely find the right one.
No filters, no searchFinding
Guests cannot look for "gluten free" or see only vegetarian dishes. They can only scroll.
No path to an orderSales
You cannot add a dish to a cart from a PDF. The guest still has to call the waiter.
Another appBehaviour
On some phones the file is offered as a download or opens in another app, and the guest has to return to the browser.
A five-minute test: how your own PDF menu looks
The quickest check is to walk the guest's path. Do not use the phone you uploaded it from, and do not use the venue Wi-Fi, because guests are often on mobile data. Ask someone who does not know the menu to find two things: the price of a dish and the allergen information.
If they cannot do it in half a minute, your guests live the same experience. You do not need to be technical to see the difference: just compare your PDF with the web menu of a venue down the street.
Check it with your own phone
- Scan the table code with a phone on mobile data, not Wi-Fi.
- Time how long it takes until the first readable line.
- Read a dish price without zooming. Can you?
- Search for a dish by a word. Does search work?
- Try to switch the language. Is there a second menu, and is it easy to find?
- Find the allergens of one dish.
- Ask another person to find their favourite dish without any help.
Total7 items
PDF menus, Google and accessibility
Google lists PDF among the file types it supports, but it needs a special parser to extract readable text. HTML, by contrast, is plain text that can be read without extra steps. That does not mean a PDF never shows up in search, only that a web page is the easier and safer route.
The second reason is mobile-first indexing: Google uses the mobile version of a page for indexing and ranking. A page with clear headings, dishes as text and photo descriptions is better prepared than a file with an image. And if the PDF was made from a photo, it contains no text at all.
Accessibility points the same way. A screen reader reads text, not a picture of text. People with weak eyesight increase the font in the browser and a web menu reflows, while a PDF stays the same sheet. If you want to be found when someone searches for a dish or a venue, also read the article on the Google Business Profile.
| - | PDF behind a QR code | Web menu |
|---|---|---|
| Text that can be searched and selected | Only if exported as text, not as an image | Yes |
| Google reads the content | Possible, but with a separate file parser | As a normal page |
| Font size chosen by the guest | No | Yes |
| Screen reader | Depends on the file, often awkward | Headings, lists, photo descriptions |
| Browser page translation | Often does not work | Yes |
| Link to one dish or category | No | Yes |
Prices, sold-out dishes and data
The price of courgettes went up and the chicken ran out at 7 pm. In a PDF that means a new export, a new upload and a check that the QR code still points to the same address. The more steps, the more often it is left "until next week" and the guest sees an old price. In a web menu you change the price or hide the dish in one place and it is live on every code at once.
The other difference is data. A file does not tell you who opened it or how far they got. In a web menu you see which dishes and categories guests view most, and you can decide what to highlight or drop. In Menuto this is the statistics feature.
Allergens are a topic of their own. Information on the 14 allergens has to be available to the guest (Regulation (EU) No 1169/2011), and in a PDF it often hides in a footnote nobody reads. More in the article on allergens on the menu.
What a web menu gives you
- Price or availability changes in seconds, on every code
- Photos, allergens and labels on each dish
- A menu in several languages at one address
- Data: which dishes are viewed most
- A path to ordering at the table or for pickup
What a PDF costs day to day
- A new export and upload for every change
- Old versions lingering in phone caches
- No trace of guest behaviour
- A separate file for each language
- No link to ordering or the till
How to move from a PDF to a web menu
You do not start from zero. Your menu already exists as a PDF or on paper, and Menuto accepts a photo or a PDF and recognises dishes, prices and allergens with AI import. The free plan includes one such import, the paid plans have no limit (see pricing).
Recognition can get a line or a price wrong, so always review the result. The most common slips are a description and a price merged into one line, or a line skipped in an unreadable corner.
After the import you have a structure: categories, dishes, prices. From then on every change takes a minute. The same menu can be shown at the table, on the venue website and in online orders, without redoing it for each place.
- #01
Prepare the file
Take the PDF or photograph the menu on a flat surface in good light. One category per shot gives the cleanest result.
- #02
Import with AI
Upload the photos or the PDF in the import dialog and wait for the list of dishes and prices.
- #03
Review and fix
Compare every price with the original, correct the names and arrange the categories.
- #04
Add photos and allergens
Start with the 5 most ordered dishes, then the rest. See how to photograph food with a phone.
- #05
Switch the QR code
Generate a code for the new menu and replace the old one in the dining room. If you already printed a code that points to your Menuto address, nothing changes.
When a PDF menu is still a good choice
A PDF is not a bad format, it is a bad choice for a menu guests read on a phone. There are cases where it is exactly right.
If you have both, make the main menu a web menu and keep the PDF as an addition clearly marked "for print". More about the QR menu in general in the QR menu guide, and if you also want a venue website, see the article on the restaurant website.
Where a PDF does the job
- For print: the paper menu, the table menu, a poster or a wine list. Export it from the same data.
- Catering and banquet offers: a document with a total and terms that the client reads on a computer or forwards.
- A stopgap: you open tomorrow and have no time to set things up. Replace it within a week.
- A seasonal or event sheet: a New Year menu that is valid for one day and sent by email.
- An archive: past menus for internal reference.
Total5 items
Frequently asked questions about PDF menus
Can I use a QR code that points to a PDF file?
Technically yes, but the guest gets a file, not a menu. If you are short on time, start with a PDF and replace it later. It helps if the QR code points to an address you can later redirect to the web menu, so you do not reprint.
Does Google index PDF menus?
Google supports PDF as a file type, but it needs a special parser to extract the text. If the PDF was made from a photo, there is no text. A menu as a web page with text is the safer option for search.
How big should a menu PDF be?
The smaller the better on a mobile network. But even a small file keeps the A4 sheet format, so size is not the only problem.
How do I change a price in a PDF menu?
Edit the source document, export it again and upload the file in place of the old one. If it does not refresh, phones may show a cached version. In a web menu the change happens in one place.
Can I import a PDF menu into Menuto?
Yes. Menuto accepts a photo or a PDF and recognises dishes, prices and allergens with AI. The result is always reviewed by hand before publishing.
Should I remove the PDF completely?
No. Keep it for print, catering and the archive. Just do not make it the main menu that guests open from the QR code.
How long does the switch take?
For a small menu usually an afternoon: import, checking prices, photos of the key dishes. Start with the most ordered items and add the rest over the next days.