You have a PDF — menu, product catalog, manual, spec sheet, price list — and you want people to access it by scanning a QR. Makes sense: PDF is easy to create and everyone can open it. This article shows how to do it right.
But I'll be honest right away: PDF isn't always the best choice for displaying on a phone. I'll explain when to use PDF, when to prefer a web page, and how to make both work well with QR.
How to create a QR for a PDF
The QR doesn't "contain" the PDF — it points to a URL where the PDF is hosted. So the flow is:
- Host the PDF somewhere with a public URL:
- Google Drive (with a public sharing link)
- Dropbox
- Your own site/server
- A QR platform that hosts the file for you (like the Code2Scan PDF type)
- Get the direct URL of the PDF.
- Generate a dynamic QR pointing to that URL.
- Print and distribute.
⚠️ Watch out with Google Drive: the default link opens the Drive interface, not the PDF directly. Use the "publish to web" option or a service that generates a direct link to the file.
Why dynamic is better for PDF
Always use dynamic QR. Reasons:
- Update the PDF without reprinting the QR: menu price changed? Upload the new version, keep the same QR. The 200 printed menus point to the updated PDF.
- Track access: how many opened it, when, from where.
- Switch hosting: moved from Drive to your server? Update the destination in the dashboard.
A static PDF embedded in the QR is a maintenance nightmare. Why dynamic matters.
The problem with PDF on mobile
Here's the uncomfortable truth: PDF is horrible to read on a phone.
- Opens in a separate viewer (slow)
- Tiny text, you need to pinch to read
- Awkward scrolling
- Heavy files (5-20MB) take time to load on cellular
- Not responsive — made for A4 paper, not a 6" screen
Result: customer scans, opens the PDF, sees microscopic text, and gives up in seconds. The PDF abandonment rate on mobile is high.
When PDF makes sense (and when not)
✅ PDF is OK for:
- Manual / technical documentation that the person will download and read later, maybe on a computer
- Spec sheet / certificate that needs to be an "official" document
- Material for download / printing (e-book, form to fill in and print)
- Catalog the customer wants to keep offline
❌ Prefer a web page (not PDF) for:
- Restaurant menu → use a link-in-bio or menu page. Loads fast, responsive, easy to update.
- Product catalog for selling → a page with photos and a buy/WhatsApp button converts much more
- Price list → a simple HTML page is more readable
- Anything the customer views quickly and acts on
The rule: if the person is going to consume it right now, on the phone, a web page wins. If they're going to download and keep it, PDF works.
How to optimize if you do use PDF
If PDF really is the choice:
- Compress the file — use compression tools to get it under 2-3MB. A 15MB PDF on cellular is guaranteed abandonment.
- Suitable format — if possible, generate the PDF in a more "vertical/mobile" format instead of A4 landscape.
- Light first page — put the essentials on the first page (which loads first).
- Test on a real phone — not just desktop. See how it opens on a mid-range Android on cellular.
QR size and printing
Same principle as other QRs: reading distance ÷ 10.
- Table/counter (30cm) → minimum 3cm
- Poster/wall (1-2m) → 10-20cm
Full size rule. And always test before printing at scale.
Summary
- A QR for a PDF points to a hosted URL (it doesn't embed the file).
- Use dynamic QR to update the PDF without reprinting.
- Compress the PDF (< 2-3MB).
- For menu, sales catalog, price list → prefer a web page, not PDF.
- PDF works well for manual, spec sheet, download material.
Create your PDF QR — with hosting and updates without reprinting.