A QR codeA 2D matrix barcode that encodes data in a square grid of black and white modulesA single black or white square in the QR grid. The number of modules per side scales with the QR versionThe size of a QR code, numbered 1 (21×21 modules) through 40 (177×177). Higher versions store more data but require more printed space. Read more →, from 21×21 modules for version 1 up to 177×177 for version 40. Read more →. Read more → on the table tent is just a delivery mechanism. The decision that actually shapes the dining experience is what sits on the other side: a mobile-formatted web menu or a PDF file. Both work, both scan identically, and both look fine on a designer’s mock-up. The split shows up in production. Cellular reception in dim restaurants is unreliable. PDF readers behave differently on iOS and Android. Older guests struggle with pinch-to-zoom. Allergen filters cannot exist inside a static document. This guide compares the two formats across the dimensions that actually matter on a Friday night service, and flags the failure modes each one hides until the wrong evening.
Quick verdict: which to use
Use a PDF menu when:
- The menu changes a few times a year and brand-consistent typography matters more than mobile fit.
- The dining room has reliable Wi-Fi and the file stays under about 1 MB.
- The kitchen wants the on-screen menu to look identical to the printed copy guests still receive.
- Allergen filtering, multilingual switching, and live availability are not part of the experience.
Use a web menu behind a QR code when:
- The menu changes weekly, daily, or by service period.
- Guests scan over cellular and signal strength varies across the room.
- The menu has more than about 30 items, multiple sections, or filterable allergens.
- Accessibility for screen readers and large-print mode matters.
- Multiple languages are needed without producing a separate file per language.
Side-by-side comparison
A short version of the trade-off across the dimensions that show up most often in real deployments.
| Dimension | PDF menu | Web menu (HTML) |
|---|---|---|
| Typical file size | 2-15 MB | 50-300 KB initial render |
| First-paint on weak cellular | Slow; full file must download | Fast; HTML and key text render incrementally |
| Mobile readability | Pinch-to-zoom required on most layouts | Reflow to phone width, native font sizing |
| Update workflow | Replace file, repoint dynamic QR or reprint | Edit CMS or HTML and republish |
| Accessibility | Limited; tagged PDFs are rare in restaurants | Full; semantic HTML works with screen readers |
| Allergen and dietary filters | Not possible inside the file | Trivial with HTML, CSS, and a few buttons |
| Multilingual | Separate file per language | Language switcher on a single page |
| Hosting cost | File on any web host or CDN | Same; HTML pages are smaller than PDFs |
| Design control | Pixel-exact, matches print | Constrained by the device width and CSS |
| Search-engine visibility | Indexed weakly | Indexed cleanly; menu items appear in results |
The pattern is consistent. PDF wins when a printed-page layout is the goal and the restaurant has reliable network conditions. Web wins on every dimension that touches phone behavior, accessibility, or update cadence.
Best choice by scenario
Fine-dining tasting menu that changes weekly. Web menu. The guest expects a daily-updated narrative and the kitchen team needs to edit copy without touching a print file. A small static site with a CMS handles this for far less work than reissuing PDFs.
Pizzeria with a stable 25-item menu and reliable Wi-Fi. PDF menu is acceptable, but a single-page web menu costs almost the same to build and reads better on a phone. Default to web if there is any chance of seasonal updates.
Hotel breakfast room with a fixed continental menu. PDF works well here. The menu rarely changes, the network is reliable, and the layout is a brand asset. Keep the file under 800 KB.
Café with weekly specials, dietary filters, and tourists who read multiple languages. Web menu. Allergen filters and a language switcher are impossible in a PDF without producing dozens of versions. A web menu does this with one source of truth.
Bar with a cocktail list reprinted each season. Either works. The cocktail list is short, the reprints are deliberate, and pinch-to-zoom on a six-cocktail PDF is fine. Use a web menu only if scan analytics or upsell modules are part of the plan.
Food truck with a rotating one-page menu. PDF if the menu format never changes; web if the operator wants to run promotions or capture e-mail signups behind the menu.
Failure modes for each
Every format breaks somewhere. The honest comparison is where, and how often, each one fails in production.
PDF menus, where they fall apart:
- File size on cellular. Designers export print-resolution PDFs that land at 5-15 MB. In a dim basement restaurant with one bar of LTE, the file stalls. Guests see a download progress bar where a menu should be. Some put the phone down, some flag the server. Either way, the QR code experience is dead.
- Pinch-to-zoom on small print. A two-column print layout shrinks to about a third of a phone screen. Guests over fifty pinch, zoom, scroll horizontally, and miss whole sections. Designers test on their own phones and miss this because they know where every dish lives.
- Renderer differences. iOS Safari opens a PDF in a viewer with its own controls. Android Chrome may download the file. Older Android viewers strip embedded fonts. A menu that looks beautiful on the designer’s iPhone can ship as Times New Roman on a guest’s three-year-old Android.
- No allergen filters. A guest with a peanut allergy cannot ask the PDF to hide unsafe items. The server has to take the question. That is fine for a small menu; it is a wait-staff bottleneck for a 90-item bistro.
- Indexing by search engines. Restaurant menus are a high-intent local search query. PDFs are indexed weakly compared with HTML pages, and the items inside a PDF rarely show up as direct snippets.
Web menus, where they fall apart:
- Hosting outages. A PDF on a CDN is one file. A web menu running on a cheap shared host can fail when the database is busy. If every QR code in the dining room points to one URL and that URL returns a 500, every table is blind. Build the page as a static export so it survives database failures, or pick a host with proven uptime.
- Bad mobile design. A web menu produced by a designer who never tested on a real phone is worse than a PDF. Tiny tap targets, hover states that do nothing on touch, slow-loading hero images, and modal pop-ups all kill the moment between scan and read. A simple, server-rendered page beats a designer-driven one if the design ignores phones.
- CMS workflow drift. The kitchen team edits content in a CMS that staff turnover slowly forgets how to use. After a year, prices on the website and prices on the in-house printout diverge. The fix is operational: a single source of truth that drives both, ideally a structured menu file the CMS reads from.
- Third-party widgets. Reservation widgets, ordering platforms, and analytics scripts each add weight and a third-party point of failure. A menu that loaded in 800 ms with the QR code alone can take 6 seconds with three vendor scripts. Each script is one more thing that can go wrong on a guest’s flaky cellular.
- Cookie banners and consent overlays. EU-targeted restaurants must show a cookie banner. A banner that covers half the screen on phones blocks the menu entirely. The fix is to keep the menu page free of any tracking that triggers the banner, or to design the banner so it dismisses with a single tap.
The headline pattern: PDF menus fail predictably (size, zoom, no filters), web menus fail unpredictably (outages, third-party scripts, design errors). Predictable failure is easier to plan around. Unpredictable failure costs more when it hits.
How to implement either
Both paths start with the same QR code. A QR code is a square grid of dark and light modules surrounded by a quiet zoneThe unprinted margin of at least four modules' width that must surround every QR code. Read more →, the blank margin a scanner needs to lock onto the finder patternsThe three large squares in the corners (top-left, top-right, bottom-left) of every QR code. Scanners use them to detect a QR in the camera frame, lock onto it, and determine its orientation. Read more →. What changes between formats is what the QR points at and how the destination is hosted.
PDF menu, minimum viable workflow.
- Export the menu as a web-optimized PDF with embedded fonts. Target under 1 MB.
- Upload to a stable host (an object store like S3, a static site, or the restaurant’s existing website).
- Generate a static QR code pointing to the PDF URL, using the URL-to-PNG generator for a clean print-ready file.
- Print the QR at the size the table tent allows, with a clear quiet zone around the symbol.
- Test the scan on three or four phones, including older Android devices, before any volume printing.
Web menu, minimum viable workflow.
- Build a single-page menu in HTML or a small static site generator. Skip third-party widgets unless they pay for themselves.
- Compress images, defer non-critical scripts, and lazy-load anything below the fold.
- Add semantic markup so screen readers can navigate sections.
- Host on any provider with monitored uptime. A static export removes the database as a failure point.
- Generate the QR code pointing to the menu URL. Use a dynamic QR provider if the URL might change or if scan analytics matter.
- Watch the QR code design best practices for module density, error correctionMathematical redundancy built into every QR code that lets it scan correctly even if part of the matrix is damaged, dirty, smudged, or covered (for example by a logo). Read more →, and contrast.
For the print artwork itself, the URL-to-PNG generator produces a high-resolution PNG ready for table tents, posters, and printed receipts. Restaurants running multiple QR codes (table tent, takeaway flyer, window sticker) often use a restaurant menu generator workflow that bundles design and tracking. For cafés running loyalty alongside the menu, the café loyalty playbook covers the linking patterns.
Frequently asked questions
Should a PDF menu be linked from the homepage too? Yes. Whichever format the QR code points to, the same URL belongs in the website’s main navigation. Some guests do not scan; some prefer the desktop. A single canonical menu URL makes operations simpler and search-engine indexing cleaner.
Can the same QR code show different menus by time of day? Yes, with a dynamic QR. The destination URL is fixed, but the page behind it can detect the time and render breakfast, lunch, or dinner. This works for both web menus and for PDFs swapped on a schedule.
What happens if the Wi-Fi or cellular fails entirely? Neither format works without a network. The fallback is a small printed menu kept behind the bar. Some operators print a four-line “scan here, or ask for a menu” card so guests with no signal know to flag the server.
Are QR-only menus a deterrent for older guests? They can be. Surveys consistently show older guests prefer printed menus when given a choice. The pragmatic answer is a hybrid: QR code on the table tent for guests who scan, printed menus available on request for guests who do not. Hospitality should never depend on the QR alone.
Sources
- Wikipedia — QR code — Background on the QR code format, modules, and error correction relevant to menu deployments.
- National Restaurant Association — Restaurant Technology Landscape Report 2024 — Survey data on customer willingness to access menus via QR codes in limited-service restaurants.
- Wikipedia — Portable Document Format — Reference for the PDF format, its renderers, and accessibility features.