QR code menus: PDF vs a real page, which one customers actually use

Scan the QR code on most tables these days and you land on one of two things. Either a proper menu page that loads fast and reads like it was built for a phone, or a PDF that was designed to be printed on A4, shrunk down, and handed to you as six pages of pinch-and-zoom while your table waits to order.

Both experiences start with the exact same little black-and-white square — same phone, same one-second scan. What splits them is what happens in the three seconds after: one opens a page sized for the screen in your hand, the other opens a document sized for a printer and expects you to zoom and drag your way to the burger on page four. People blame the code. The code did its job perfectly.

Why it matters

QR menus aren't a pandemic leftover that's fading out — adoption kept climbing after 2020 and hospitality is now one of the fastest-moving categories for QR use, with roughly three in four restaurants globally using some form of QR-coded menu. People scan them constantly: menus and product info are consistently the two most common reasons anyone scans a QR code at all.

But adoption and preference are two very different numbers, and the gap between them is the actual story. In a blind survey of US diners, Toast found 81% prefer a physical menu, and only 1% actually chose a QR code as their preferred way to look at one — that number climbs to 90% among diners over 55. A separate widely-cited survey from Technomic found 88% of consumers prefer printed menus over QR-coded ones, even though 60% said they still "liked the idea" of QR menus in principle. People aren't rejecting the concept. They're rejecting the execution.

That distinction matters because it's fixable. And most venues are fixing the wrong half of it.

It's the PDF, not the QR code

When outlets covering the QR-menu backlash went looking for why diners were so annoyed, the answer wasn't really about scanning codes at all. As one piece of reporting on restaurants quietly dropping QR menus put it, menus are often let down by "poorly formatted PDF files that require constant scrolling." Kristen Hawley, of the restaurant-tech newsletter Expedite, has described QR menus as "almost universally disliked" — and the detail in the research backs up exactly why.

Dr Luana Nanu, a hospitality researcher at the University of South Florida, studied what actually happens when a QR menu is hard to use. Her finding, published in the Journal of Hospitality and Tourism Insights, is that a clunky QR experience doesn't just create mild frustration — it creates genuine anger, and that anger is what drives customers away and erodes loyalty, hitting older diners hardest. Participants in her research kept reaching for the same word: useless.

Break down what people are actually annoyed about and it stops looking like a QR-code problem and starts looking like a formatting problem:

• 26% said the menu text was too small or hard to read on their phone
• 20% were frustrated at having to use their phone at all
• 16% blamed unreliable tech — bad wifi, scanning failures

"A QR code is not a strategy. It's a delivery mechanism. Whether it helps you or costs you covers depends entirely on what's sitting on the other end of it."

No study has directly A/B-tested "QR plus PDF" against "QR plus a real page" as two separate conditions — that specific experiment doesn't exist yet. But the pattern in the reporting and the research is consistent enough to draw a straight line: a lot of the anger attributed to QR menus generally is really anger at scrolling and pinching through an unformatted PDF on a five-inch screen.

What a PDF quietly costs you in search

There's a second cost that has nothing to do with how your customer feels in the moment, and everything to do with whether new customers find you at all. 90% of diners research a restaurant online before visiting, and 77% specifically visit the venue's website before dining in or ordering takeaway. If your "menu" is a flat PDF, here's what that does to your visibility.

Google's John Mueller has confirmed that Google does convert PDFs to extract their text for indexing, and there's no dramatic ranking penalty just for being a PDF. But he's also said two things that matter directly here: Google's systems treat PDFs as static documents and re-crawl them far less often than HTML pages, so a menu that changes seasonally goes stale in search results for longer than an equivalent web page would. And when a PDF holds content that actually matters, his explicit advice is to also put that content on a real HTML page — specifically so people don't have to download a file just to see it.

There's a second, softer cost SEO practitioners point to rather than Google itself: a PDF carries none of the structure — headings, individual dish names, sections — that helps a search engine match "vegan pasta [suburb]" or "banh mi near me" to your specific menu. A flat page of text is just a page of text. An HTML page with real headings and dish names gives Google something to actually match against.

Google itself seems to agree the format is the weak link. In 2026, Google Business Profile shipped an experimental AI feature that lets owners upload a photo or PDF of their menu, and Google's own generative AI converts it into a structured menu — recognising headers and prices automatically. It comes with real limits: the whole menu has to fit on one image or page, blurry scans don't parse well, and it's explicitly labelled experimental.

Sit with what that actually means. Google looked at the same PDF-menu problem venues have been living with for years and decided the fix was to build an AI layer that turns the PDF into structured data — on Google's own page, inside Google Business Profile, not on the venue's site. It's a genuinely useful feature. It's also proof that even Google doesn't think a raw PDF is a good enough format to work with as-is; it built the workaround on its own turf rather than assuming the PDF was fine.

It's a reasonable bet that Google's newer AI-driven discovery tools in Maps lean on exactly this kind of structured menu and profile data as matching signals, alongside things like review sentiment and photo quality — though that's an inference from how Google talks about these features generally, not something Google has spelled out feature-by-feature. Either way, the direction is the same: structured beats flat, and a PDF is structurally the flattest format there is.

None of this is an argument that PDFs are always wrong, though. A food truck with one menu that hasn't changed in two years and no ambition to rank for local search has almost nothing to gain from a real menu page — a PDF behind a QR code is cheap, works, and isn't worth the setup time. That's a real, defensible choice, not a shortcut.

Where it stops being fine is anywhere one of two things is true: your menu changes with any regularity — a café's brunch specials that shift with produce, a pub's weekly specials board — or you actually want to be found by people searching for what you serve. A Vietnamese or Thai restaurant where "banh mi [suburb]" or "pad see ew delivery" is a real search pattern is leaving that entire channel on the table if the only thing behind the QR code is a PDF Google barely revisits.

What to skip

A few things not worth your time or money on this specific problem:

• A full QR ordering-and-payment platform, if all you actually need is a menu people can read. One competitor's own marketing estimates put typical costs for that category of tool at roughly $200–500 a month — a lot of overhead if a readable menu page was the actual goal.
• Anyone promising "Menu schema gets you rich snippets." Google's structured-data docs do define Menu, MenuSection and MenuItem types, but Menu isn't currently a standalone rich-result type the way Recipe or FAQ are. Structured markup helps machines understand your menu; it doesn't guarantee a fancy search card.
• A brand-new QR code generator every time you update the menu. The code just points at a URL — change what's behind that URL and the code doesn't need to change with it. That's the whole advantage of a real page over a re-uploaded PDF.

The honest pitch

FastPage is a website builder we built for hospitality specifically, and menus are one of the things it handles as a real page, not a re-hosted file. To be straight about where the line actually sits: FastPage's structured data today includes a menu link on your business's schema markup — it points Google at whichever page you set as your menu — but it doesn't yet mark up individual dishes with their own schema. That's a real gap, not a hidden one, and we're not going to pretend otherwise.

What FastPage does give you is the easy default being the right one. Your menu can be a URL or a PDF through Quick Links either way — we don't lock the option out — but a real, indexable, mobile-formatted page is the path we point you toward, alongside Google Business sync, bookings and socials. Pricing helps too: it undercuts most QR-ordering platforms by a wide margin (pricing).

If your menu barely changes and nobody's searching for your dishes by name, a PDF behind a QR code is a fine, sensible choice. If either of those isn't true for your venue, it's quietly costing you covers you'll never see a number for. Build your site free — no card to start, and a 30-day money-back guarantee if it turns out not to be the right fit.