The code is the easy part; hosting is the real work
A PDF QR code encodes a URL. That is the whole mechanism — QR codes cannot contain a file, and any tool claiming to "put your PDF in a QR code" is hosting it somewhere and encoding the link. The maximum a QR code holds is about 2,953 bytes, which is roughly a thousandth of a modest PDF.
So the decisions that matter are not about the code at all. They are about where the file lives, how big it is, and what happens on a phone when the link opens.
File size is the thing that ruins these
Someone scanning a menu code on a restaurant terrace is on mobile data, possibly on a congested cell, and will wait perhaps four seconds before giving up.
| PDF size | Time on 4G (~15 Mbps) | Realistic outcome |
|---|---|---|
| 500 KB | Under 1 second | Opens immediately |
| 2 MB | 2–3 seconds | Acceptable |
| 10 MB | 8–10 seconds | Most users abandon |
| 40 MB | Over 30 seconds | Effectively broken |
Design-agency PDFs routinely arrive at 30–80 MB because every image is at 300 dpi CMYK for print. That file is correct for the printer and unusable on a phone.
Export a screen version separately. In most PDF tools this is an "optimised" or "smallest file size" export; in Acrobat it is Save As Other → Optimised PDF. Downsample images to 150 dpi, convert to RGB, subset fonts, and remove print marks. A 40 MB menu typically comes out under 2 MB with no visible loss on a phone screen.
Then check what you exported. A "screen optimised" preset that leaves a 12 MB file has not solved the problem.
Inline viewing versus forced download
When the phone requests your PDF, the server sends a Content-Disposition header that decides what happens next:
Content-Disposition: inline; filename="menu.pdf" → opens in the browser
Content-Disposition: attachment; filename="menu.pdf" → downloads to Files
For a QR code you want inline, essentially always. A customer scanning a table code wants to read the menu, not find a downloaded file in a folder they never open. attachment is the right choice only for things people genuinely need to keep — a warranty, a certificate, a form to complete.
Many hosting services, particularly file-sharing platforms, force attachment or interpose a preview page with a download button. That extra tap costs you a meaningful share of scans. Serving the file from your own domain gives you control over this header; most sharing services do not.
Where to host it
Your own domain is the best option when available. You control the header, the URL is stable and readable, the destination is recognisable to a cautious user, and you can update the file in place while keeping the same URL. Use a short, permanent path — yoursite.com/menu.pdf — so the code stays small and the file can be replaced without reprinting anything.
Cloud storage (Drive, Dropbox, OneDrive) works but adds friction: long URLs that force a denser code, a preview interstitial before the document, and occasionally a sign-in prompt if sharing permissions are set wrong. If you use it, set the link to "anyone with the link can view" and test in a private browsing window while signed out — the most common failure is a link that works perfectly for the person who created it and prompts everyone else to request access.
Document platforms (Issuu, Scribd and similar) give you a reader interface and analytics but wrap the document in their own branding and often push app installs.
Whatever you choose, ask one question: if this service shuts down or changes its sharing rules, how many printed items become dead? For a table card reprinted monthly, the risk is trivial. For a code on packaging or a permanent sign, host it yourself.
How phones actually render PDFs
iOS opens PDFs inline in Safari with a competent built-in viewer — pinch to zoom, scroll, share. It handles multi-page documents well.
Android is less consistent. Chrome may render it inline, hand it to Google Drive's viewer, or download it depending on the device and installed apps. Some manufacturer browsers download by default regardless of your header.
Both share the same fundamental problem: a PDF laid out for A4 is painful on a 6-inch screen. The user gets a full page scaled to fit, with type at four or five points, and has to pinch and pan around a fixed layout that does not reflow.
If more than a handful of people will read the document on a phone, the honest answer is that it should be a web page rather than a PDF. A responsive page reflows, is searchable, is accessible to screen readers, loads in a fraction of the time, and can be updated without re-exporting anything. Restaurants in particular default to PDF menus out of habit and would serve customers better with an HTML page.
Where a PDF is genuinely right: documents that must preserve exact layout (certificates, plans, forms), documents intended for printing, and documents that must remain usable offline once downloaded.
Making the file updatable
The strongest pattern for anything printed is a stable URL with swappable content. Point the code at yoursite.com/menu and configure the server to serve the current file at that path. When the menu changes, replace the file; every printed code keeps working.
The mistake is encoding a versioned URL — yoursite.com/menu-autumn-2026-v3-final.pdf — which is both long and guaranteed to be wrong within months.
Watch caching if you do this. Browsers and CDNs may hold an old copy of a PDF for days. Set a short Cache-Control max-age on the file, or use a rewrite rule that serves the versioned file behind the stable path.
Accessibility
A scanned or image-only PDF is invisible to screen readers and to search. If your document was produced by scanning paper, run OCR over it. If it was exported from a design tool, check that the text is real text — try selecting a word in a PDF viewer; if you cannot, neither can assistive technology.
Tagged PDFs with a proper reading order, alternative text on images and real headings are meaningfully better for disabled users, and for public sector organisations in the UK and EU this is a legal requirement rather than a nicety.
Where PDF codes work well
- Restaurant and bar menus, where the layout is doing real work and the file is small
- Product manuals and assembly instructions on packaging, saving a booklet in every box
- Safety data sheets and compliance documents on equipment and containers
- Exhibition catalogues and programmes
- Property brochures on for-sale boards
- Conference handouts — one code on a slide replaces a stack of printed decks
- Forms that genuinely need to be printed and completed by hand
Frequently asked questions
Can a QR code contain the actual PDF file?
No. A QR code holds at most about 2,953 bytes — a fraction of any real document. Every "PDF QR code" is a link to a hosted file, so where you host it and how large it is are what determine whether it works.
How big should the PDF be?
Under 2 MB for anything scanned on mobile data. Export a screen-optimised version at 150 dpi in RGB rather than serving the print-ready file, which is often 20–40 times larger for no visible benefit on a phone.
Why does my PDF download instead of opening?
The server is sending Content-Disposition: attachment, or the hosting service forces a download or preview page. Serving from your own domain lets you set inline so the document opens directly in the browser.
Can I update the PDF without reprinting the code?
Yes, if the code points at a stable path such as yoursite.com/menu and you replace the file behind it. Encoding a versioned filename removes that option. Watch browser and CDN caching, which can serve an old copy for days.
Should I use a PDF or a web page?
A web page, in most cases where people will read it on a phone. PDFs have fixed layouts that do not reflow, load slowly, and are poor for screen readers. Choose PDF when exact layout matters, when the document will be printed, or when it must work offline after download.
Will it work without internet?
No — the scan resolves a URL, so the file has to be fetched. Nothing about a PDF code works offline unless the user has previously downloaded the file.
Can I see how many people opened it?
Only if you host it yourself and read your server logs, or route the code through a redirect you control. A direct link to a file on a third-party service gives you nothing unless that service provides its own analytics.