If you run a restaurant and your QR sticker on the table still routes guests to a PDF, this post is for you. There is no part of the experience that PDF wins on mobile. We did a small workflow test against five independent restaurant QR codes in May 2026: four of them opened a PDF, none had a tap-to-call number, and none had a print stylesheet for the kitchen (S-301, S-302, S-305).
This is the launch field note for our 10-row Restaurant QR Menu Mobile Audit. Below: the rows, why each row matters, and how to fix the most common failure on each.
TLDR (4 sentences)
A QR menu that opens a PDF on a phone fails most diners — they pinch, squint, and ask the server for a paper menu (S-001, S-002). The fix is a clean static HTML menu page, hosted at a stable URL, with body text at 17px, allergen icons that have real alt text, a tel: link in the header, and a print stylesheet for the kitchen. None of this requires a POS upgrade or a $200/month SaaS — but most independents don’t ship it because there’s no obvious editor for non-technical owners. Use the audit on this page to find your current failure modes; then fix them this weekend with the no-app weekend conversion guide.
Why this matters
The pain is documented across at least three independent source types:
- An Axios Columbus reader survey reported diners saying “showing me an 8.5-by-11 inch PDF menu on my phone screen is not the solution” (S-001, 2023-04, accessed 2026-05-25).
- A Reddit r/unpopularopinion thread describes the typical QR experience as “a PDF… pinch and scroll and squint” (S-002, 2024).
- Web Content Accessibility Guidelines 2.2 SC 1.4.4 (Resize Text) and SC 1.4.10 (Reflow) are standards that PDF menus routinely fail (S-007, S-008).
These are different sources making the same point: PDFs on phones are not a usable menu surface. The good news is the alternative — a static HTML menu — is a five-row Astro template plus a stable URL.
Audit rows
Run each row against your current QR menu. One point per pass.
Row 01 — Does the menu open without forcing a PDF download?
A QR sticker should route to an HTML page, not a Content-Type: application/pdf blob. On iOS the PDF will display inline; on Android many devices force a download dialog. In either case the page never paints any of your branding before the PDF finishes downloading.
Pass: https://yourdomain.com/menu returns HTML.
Fail: the URL ends in .pdf or your server sets Content-Disposition: attachment.
Fix: publish the menu as a static page (Astro, Eleventy, plain HTML on Vercel, even a Notion page). Update the QR’s destination URL if you used a dynamic QR (S-024). If your QR is static and printed onto stickers, this is the moment to migrate to a dynamic QR so future updates don’t require a sticker reprint.
Row 02 — Is body text ≥16px after default zoom?
Most PDFs are sized for paper (8.5×11 in or A4). On a 375px-wide phone, that means body copy renders at around 8–10px. WCAG 2.2 SC 1.4.4 recommends content scales to 200% without loss, and SC 1.4.10 requires content reflow at the 320px viewport (S-008). PDFs satisfy neither.
Pass: every line of body copy is ≥16px on a 375px viewport. Use Safari’s responsive design mode to verify.
Fail: prices are in 7pt and require pinch-to-zoom.
Fix: if you’re stuck with a PDF this week, at minimum split it into landscape two-up pages and bump the body font to 14pt. The long-term fix is HTML.
Row 03 — LCP under 2.5s on a throttled 4G connection?
Largest Contentful Paint is one of Google’s Core Web Vitals. The “good” threshold is under 2.5s (S-015). PDF menus typically have an LCP of 6–9s because the LCP element is the PDF itself.
Pass: Lighthouse mobile LCP < 2.5s (slow-4G throttle).
Fail: LCP is the PDF, > 5s.
Fix: static HTML pages routinely hit sub-1s LCP. Inline critical CSS, lazy-load any item photos, and avoid web fonts above the fold if you can. (This site itself runs that playbook — see how this audit was built.)
Row 04 — Can a guest read prices without pinch-zooming?
Prices are the most-scanned element on a menu. If they’re in a small right-hand column or set in a different font weight at a smaller size, they fail.
Pass: prices render at body size or larger, with at least 12px of horizontal padding from the item name.
Fail: prices in 7pt right column.
Fix: in HTML, lay out items as a two-column flex with the item on the left and the price right-aligned, both at the same body size. On narrow viewports, drop to a single column with the price on its own line.
Row 05 — Allergen tags machine-readable (icons + alt text)?
If you ship allergen icons as PNGs without alt text, screen readers see nothing. This is the most common accessibility failure on independent menus — in our five-restaurant sample, zero had alt text on allergen icons (S-304).
Pass: <img alt="contains peanuts" src="/icons/peanut.svg"> or similar.
Fail: icons are part of a single image of the menu, no alt text at all.
Fix: see the allergen labelling post. Use SVG icons with descriptive alt text and a visible legend at the bottom of the menu.
Row 06 — Can a single menu item be linked individually?
If your menu is one big PDF, you can’t link to “the burrata” from a Google review reply. With HTML you get #flatbread for free.
Pass: every item has an id.
Fail: PDF — no fragments.
Fix: generate IDs from the item name slug at build time.
Row 07 — Can an owner update a single price in under 5 minutes?
In our timing test of three competing self-serve menu builders, item-price updates took 6m, 9m, and 14m respectively (S-303). For a PDF workflow (re-export from Word + re-upload + sometimes reprint the QR), the median is more like 15–30 minutes.
Pass: inline edit, autosaves, QR stays the same.
Fail: the owner uses Word + Google Drive + a manual upload.
Fix: an inline editor (this is, frankly, the actual product TealStag is building).
Row 08 — Does the menu degrade gracefully on spotty Wi-Fi?
HTML pages can be cached, can show text before images, can lazy-load below-the-fold content. PDFs either fully render or they don’t.
Pass: the menu text is visible within 1s on slow-3G, with images filling in after.
Fail: PDF stays blank until fully loaded.
Fix: static HTML; consider a service worker if you have one menu page you serve a lot.
Row 09 — Is the restaurant phone number tap-to-call visible?
tel: links are free and have a 44×44px minimum tap target. In our five-restaurant sample, zero menus had a real tel: link; three had the phone number baked into the menu image (S-302).
Pass: <a href="tel:+15551234567">Call us</a> in the header or footer.
Fail: phone number is in a PNG of the header.
Fix: add a header strip with the phone number as a tel: link and the restaurant address as a geo: link if you want extras.
Row 10 — Is there a print stylesheet for the kitchen?
The kitchen still needs a printable version — for the prep counter, for a new server, for the chalkboard reference. A print stylesheet (@media print) takes 30 minutes to ship and saves the owner from maintaining a duplicate Word doc.
Pass: /menu?print=1 prints clean A4 with prices on the right.
Fail: the owner keeps a separate Word doc for kitchen printouts.
Fix: add a @media print block that hides the header/footer, sets background to white, and uses a two-column layout.
Common mistakes
- Putting the menu behind a “View menu” interstitial. Every extra tap is a 7-10% drop-off (and you can’t recover it once they ask for paper).
- Using a Wix-style “Drag your PDF here” widget. It’s still serving a PDF; you just hid the URL.
- Updating the QR sticker each time you raise a price. Use a dynamic QR (S-024) and change only the destination URL.
- Translating allergen names with machine translation. “Shellfish” can map to crustáceos or mariscos in Spanish depending on dialect, and they refer to different things. Get a human to review at least the allergen line.
- Forgetting hreflang for bilingual menus. Without it, Google can pick the wrong language version for an Italian tourist’s search.
FAQ
Do I need a website for this?
No. You can host a static HTML menu on Vercel, Netlify, or even GitHub Pages for $0. The audit applies to whichever URL your QR points at.
Will a static HTML menu hurt SEO compared to a PDF?
HTML is dramatically better for SEO than a PDF — Google indexes the body content, can show featured snippets, can rank individual items. PDFs are still indexed but with much less context (S-016).
What if I already pay for Toast or BentoBox?
Then most of this audit is solved for you — check that your existing menu page actually passes rows 01-04 in your live URL, because some POS-bundled menu pages still serve a PDF download for the “printable menu” link. See the Toast vs BentoBox vs DIY comparison.
Is this audit a tool or a checklist?
A checklist. The interactive editor is coming later. The audit is the methodology — same one our editor will run automatically once it ships.
If your menu fails any of rows 1–4, the fastest fix is the no-app weekend conversion guide. If you fail rows 5 or 9, the allergen labelling post and QR mistakes teardown walk through the specifics.