PDF QR codes — how to print a QR that opens a PDF

A PDF QR code is the small printed square that opens a PDF on whichever phone scans it — the menu, the manual, the conference handout, the real-estate flyer's full spec sheet. It looks like one decision (generate a code, print it) and turns out to be three: where the PDF lives, what URL the QR actually encodes, and how big the PDF gets to be before the scanner's phone gives up on it. Get any of those three wrong and the QR scans fine but the document never loads — which is the silent failure mode nobody catches until the print run is already shipped.

This post is the version we tell people who message us asking which Drive folder to dump the file into and whether they need a paid host. The short answer is: don't encode the document host's URL into the QR, encode a redirect on a domain you control, and treat the PDF as a thing you'll want to swap, compress, or replace without ever touching the printed code again. Long answer below — with the file-size math that matters for mobile, the three honest hosting choices, what dynamic redirects buy you over baking the URL into the pixels, and a calculator that tells you whether your draft PDF will actually open on hotel WiFi.

A PDF QR code is two products glued together#

The QR pattern and the document behind it are different problems. The pattern is the easy part — any encoder turns a URL into a printable QR; the open QR designer does it in three clicks without an account. The document side is where most PDF QR projects quietly break.

A PDF QR code has four moving pieces between the camera and the reader's eyes:

1. The encoded URL inside the printed pattern.
2. The hop — DNS, the redirect server, the rule mapping that short URL to a current PDF location.
3. The PDF host — Drive, Dropbox, your own domain, an S3 bucket, the document CMS.
4. The PDF file itself — its bytes on the wire, its first-byte latency, its mobile-renderable cover page.

Most "how to make a PDF QR code" guides cover piece one in detail and treat pieces two through four as someone else's problem. The result is QR codes that work on the printer's desk and stall in the hotel-lobby WiFi six weeks later. Each of those four pieces has a separate failure mode, and dynamic redirects only insure you against the second one.

The diagram is the whole post in one image — the rest is just unpacking why each arrow matters and what breaks when you skip the middle.

Don't encode the PDF host's URL into the QR#

The reflex move for someone making their first PDF QR is to upload the file to Drive, copy the share link, paste it into a QR generator, hit download, and print. It works on the printer's desk. It rarely survives a year.

What goes wrong, in roughly the order it goes wrong:

• The host's share URL changes. Drive reorganises share URLs every couple of years. Dropbox does. Box does. S3 buckets get renamed. The QR encodes a URL that's now a 404 and nothing on the printed code can be edited.
• The PDF needs to be replaced. Typo on page two. New seasonal menu. Updated event schedule. Re-uploading to the same host gives you a new file URL; the QR keeps pointing at the old, now-deleted one.
• The host disables public sharing. A workspace admin tightens permissions, the share link expires, the public option gets removed for a domain. Every printed QR goes dark in the same week.
• The host serves the file slower than the scanner will wait. Drive's free-tier serving latency on a cold-cache PDF can stretch past five seconds on a flaky connection. The reader gives up. You never hear about it.

A dynamic PDF QR fixes the first three by encoding a URL on a domain you control — go.yourbrand.com/d/spring — which redirects to whichever host currently holds the PDF. Change hosts, swap files, fix typos, all without touching the printed pattern. The mechanic is the same one the what is a dynamic QR code explainer walks through for URL types in general, and PDFs are a textbook case for it because the document is even more likely to change than the URL of a landing page.

The fourth — host latency — is a separate problem that the redirect can't solve, only mitigate. Cover it in the file-size section below.

The three honest hosting choices#

Once you've decided to put a redirect in front of the host, the question becomes which host. Three real options, each with a different failure mode.

Google Drive. Fast to set up, free up to a real-world threshold, useful when the PDF only needs to exist for a small audience. The catch is that Drive's "share link" doesn't serve the PDF — it serves a viewer page that loads the PDF inside an iframe. Mobile Safari handles it acceptably; Android Chrome's behaviour varies. The cold-cache first-byte is slow because Drive doesn't aggressively cache for unauthenticated viewers. Good for the QR on the conference badge holder that 60 people might scan; not the QR on the box of 50,000 product cartons.

Dropbox. Same shape as Drive — fast setup, free tier, viewer page in front of the file. Dropbox's ?dl=1 URL parameter forces a download instead of a viewer, which is closer to what you want for a PDF QR, but mobile browsers handle download-prompts inconsistently and some readers will see a "Download?" prompt that interrupts the flow. Better than Drive for one-off PDF distribution; still not great for printed-at-scale QRs.

Your own domain. Slower to set up. Pays back the moment a PDF QR ships in print at any volume. Host the PDF on a CDN (Cloudflare, BunnyCDN, the cheapest tier of any commercial CDN — $5/mo covers gigabytes of bandwidth at low traffic). Set the Content-Type to application/pdf and the Content-Disposition to inline and mobile browsers open the PDF in their native viewer instead of prompting a download. First-byte is fast, the URL is stable forever, no workspace admin can break it, the redirect server in front gets per-scan analytics, and you can swap the PDF file behind the same URL without touching anything else.

The general principle, and the same one that shows up across QR types in the adding QR codes to a website breakdown, is that anywhere the QR will end up in print or in long-running circulation, the host needs to be one you can replace without breaking the encoded URL. Drive and Dropbox are convenience hosts; your own domain is the real answer.

File size — the part nobody warns you about#

A PDF QR scans instantly. The PDF behind it does not. The bridge between "scan succeeded" and "reader saw the document" is a download, and that download happens on whatever connection the reader's phone has at scan time — which is rarely WiFi, often a tired hotel signal, sometimes 5G, occasionally the conference's overloaded shared SSID. The file-size decision you make at design time is the one most papers, brochures, and reports get wrong, because the designer is on fibre and the reader is not.

Working numbers for first-byte plus download on a modern mobile network, for a typical PDF:

• 5 MB PDF on 5G: about 1.2 seconds. Effectively instant.
• 5 MB PDF on 4G: about 3 seconds. Tolerable; readers don't give up.
• 5 MB PDF on hotel WiFi: 6 to 12 seconds. Borderline. Half your readers wait, half close the tab.
• 15 MB PDF on hotel WiFi: 25 seconds and up. Almost everyone closes the tab.
• 40 MB PDF on conference WiFi: never finishes during the session.

The math gets brutal fast. A glossy 24-page brochure exported at print resolution from InDesign is comfortably 30-50 MB; the same brochure with images downsampled to 150 DPI and JBIG2 compression on text is 4-6 MB and visually identical on a phone screen. The compression step takes 30 seconds in Acrobat or any free PDF compressor. Skipping it because "it's just a PDF" is the most common reason real-world PDF QR campaigns underperform.

A 4 MB PDF on a domain you control beats a 30 MB PDF on Drive every time. The QR scanned in both cases; only one of them loaded.

The other variable is first-byte latency — the time between the phone's request and the first byte of the PDF arriving. This is mostly the host's problem, not the file's. A cold-cache Drive PDF can take 2 seconds of first-byte even before download starts. A Cloudflare-cached PDF on your own domain is typically under 200 ms. That gap is invisible until the connection is bad, at which point it turns "felt slow" into "didn't load".

The PDF QR file-size calculator#

Plug in your draft PDF size and the connection your readers will likely have. The widget surfaces the first-byte estimate, the full-download estimate, and a blunt verdict on whether the PDF will actually open at scan time.

The defaults describe a typical mid-tier scenario — 8 MB PDF, 4G connection. Drop the size to 4 MB and even hotel WiFi clears comfortably. Push it to 25 MB and only the 5G readers ever see the document. Reader-wait threshold of about 6 seconds is the working number across the mobile UX studies; past that, abandonment rises steeply.

Where PDF QR codes earn their keep#

The use cases where a PDF QR pays back its setup cost cluster around documents that are too big for a landing page and too important for the reader to never see them. Six patterns we see most often:

Restaurant and bar menus. A PDF menu beats an HTML menu only if the restaurant already has a designer-made PDF and doesn't want to recreate it on the web. The QR on the table tent goes to the dynamic short URL; the kitchen can swap the PDF for next week's specials without reprinting the tent. The on-screen render trick that matters here is to make page one of the PDF read as a menu cover, not a logo splash — the reader is on a phone, not a desktop, and a 200 KB cover page that takes 1.5 seconds to render reads as broken even though the rest of the PDF loaded fine.

Product manuals and quick-start guides. A QR on the box, on the product itself, on the unboxing card. The PDF lives at a stable URL on your domain; the redirect lets you ship a v2 manual six months in without recalling product. The use case mirrors what the QR codes for product packaging post covers for landing-page destinations, except the document side is where the PDF-specific concerns sit.

Conference handouts and badge inserts. A QR on every attendee badge that goes to the conference's PDF programme. The PDF can update through the event (schedule slips, speaker changes) without anyone reprinting badges. File-size matters most here — conference WiFi is the worst connection your QR will ever encounter, and most conference PDFs ship at full print quality because the designer never compressed them.

Real-estate flyers. The QR on the yard sign or the printed flyer goes to a PDF spec sheet, floor plan, or full listing pack. The redirect lets you update the document as the listing changes (price reductions, new photos, sold status), and the per-scan log tells the agent which listings actually get the supplementary download. The full pattern carries across to the QR codes for real estate listings workflow, where the PDF QR is one piece of a larger per-property short-link setup.

Tradeshow handouts. A QR on the leave-behind one-pager that goes to the full PDF deck, whitepaper, or capability statement. The reader takes the small card home, scans it the next day, and the PDF arrives without them having to keep track of a fat brochure. The conversion math is the same one the QR codes for tradeshow booths post breaks down — the QR is the lead-capture surface, the PDF is the qualifier.

Annual reports, whitepapers, research notes. A QR in the article, on the back of the report cover, on the conference invite. The PDF is the substance; the QR is the access path. The QR codes in print magazines attribution stack applies here verbatim — per-issue short links, UTMs forwarded, scan-to-download tracked at the redirect.

What the redirect buys beyond editing#

The edit-without-reprint case is the obvious one. The redirect does three more things people don't ask for and quietly benefit from:

• Per-scan analytics. Every scan is a request to the redirect. Timestamp, country, device class, referrer where available. You finally know which printed code actually got used. The shape is the same one the platform analytics docs describe for any short link; the PDF case is just a redirect that points at a PDF instead of an HTML page.
• Soft access control. A redirect server can decide who gets the PDF — by time of day (the conference QR returns the after-hours PDF after 6 pm), by region (different PDFs by country), or by request count (lock the URL after the print run has been consumed). None of that's possible if the QR encodes the PDF host's URL directly.
• Migration insurance. The PDF host can change without breaking the printed QR. Move from Drive to S3, switch CDNs, change domains — the redirect rule updates and every printed QR keeps resolving. The same DNS-escape-hatch principle the owning your link infrastructure breakdown lays out at a higher level applies in miniature here.

The static alternative — encoding the PDF host's URL directly into the QR — is the worst of all worlds. It binds you to one host forever, gives you no analytics, no access control, no migration path. The static vs dynamic QR codes post covers the general case; for PDFs it's especially one-sided, because the document is even more likely to change than a landing page.

Production checklist before printing#

Six things to verify before sending the QR to print, in order of how badly each one breaks the campaign if you skip it.

1. The QR encodes a redirect on a domain you control, not the PDF host's URL. The single most important check. If the encoded URL contains "drive.google.com" or "dropbox.com", stop and route through a redirect.
2. The PDF is under 5 MB for mobile-network use. Compress, downsample images to 150 DPI, run JBIG2 on text. Anything over 10 MB needs a strong reason.
3. Page one is the document, not a logo splash. Mobile readers see page one full-screen for the first few seconds. Make it useful.
4. Test the scan on three real phones. Two iOS, one Android, ideally one older device. Indoor lighting. The lab works; the lobby is the test.
5. The Content-Type is application/pdf and Content-Disposition is inline. Default for most hosts; worth verifying via curl. Wrong values trigger download prompts on mobile browsers and break the flow.
6. Test the full scan-to-open path under your worst-case connection. Tether your phone to a slow hotspot or use the browser's network-throttling. Conference WiFi is what you're simulating.

The reason real-world PDF QR projects underperform isn't usually the QR — the pattern part is the easy part. It's items 2, 3, and 6 above, which the designer and the print buyer between them rarely test before the print run goes out. The scan-side troubleshooting list lives in QR code not scanning — six fixes; the open-side concerns above are specific to the PDF case.

Sourcesshow citations

• ISO/IEC 18004:2024 — QR code bar code symbology specification. https://www.iso.org/standard/83389.html
• Adobe — PDF Reference and Adobe Acrobat documentation, including compression and accessibility guidance. https://www.adobe.com/devnet/pdf/pdf_reference.html
• MDN — Content-Type and Content-Disposition HTTP headers, including the inline vs attachment distinction that controls mobile open behaviour. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
• MDN — HTTP redirects (301, 302, 307), the mechanic behind the redirect step in front of the PDF host. https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
• Google — Drive sharing and file access documentation, on viewer-page behaviour and link types. https://support.google.com/drive/answer/2494822
• Dropbox — sharing API and direct-download (?dl=1) parameter docs. https://developers.dropbox.com/dbx-share-link
• Cloudflare — cache control and origin-fetch documentation for static asset hosting. https://developers.cloudflare.com/cache/

Can I edit the PDF after the QR is printed?

Yes, if the QR encodes a redirect on a domain you control. Replace the PDF on the host (or repoint the redirect at a different host entirely) and every printed QR starts serving the new file on the next scan. The printed pattern never has to change. If the QR encodes the PDF host's URL directly, the answer is no — the original URL is welded into the pixels.

How big should the PDF be for mobile readers?

Under 5 MB is the safe zone for the connections readers actually have at scan time. 8-10 MB is the upper bound for use cases where readers will likely be on 4G or better. Past 15 MB you're betting on 5G or strong WiFi, which most scenarios don't deliver. Compress with image downsampling to 150 DPI and JBIG2 on text — the visual quality on a phone screen is unchanged.

Which host is best for PDF QR codes?

Your own domain on a CDN ($5/mo at low volume) for anything printed at scale or expected to last more than a few months. Google Drive or Dropbox are fine for one-off internal handouts where setup speed matters more than the URL being stable. The redirect in front of the host is what matters most — it lets you change hosts later without reprinting.

Do PDF QR codes work without an internet connection?

No. Unlike vCard or text-payload QR codes, where the data is baked into the printed pattern, a PDF QR encodes a URL — the phone has to fetch the document over the network. If you genuinely need offline-capable scan-to-document, the only option is a smaller payload that fits in the QR itself (text, vCard, calendar event), not a PDF.

How do I track scans plus PDF opens separately?

Two layers. Layer one is the redirect server, which logs every scan. Layer two is the PDF host or a wrapper page in front of the PDF, which logs the actual document open. The gap between them (scans that didn't result in opens) is your file-size and host-latency problem made visible. Most platforms surface layer one out of the box; layer two needs a small landing page or a CDN log that you can analyse.

Should I use a static QR if the PDF will never change?

Probably not. Even "permanent" PDFs eventually get a typo fix, a brand refresh, or a host migration. The marginal cost of using a redirect is near zero; the upside is the option to make any of those changes without reprinting. Static is defensible only if the PDF is on a domain you fully control, the URL will provably never change, and you don't want scan analytics.

Will mobile browsers open the PDF inline or force a download?

Depends on the `Content-Type` and `Content-Disposition` headers the host serves. `Content-Type: application/pdf` with `Content-Disposition: inline` gives you the native viewer in iOS Safari and most Android browsers. `Content-Disposition: attachment` triggers a download prompt that interrupts the flow. Default CDN config is usually inline; Drive and Dropbox often add chrome that gets in the way.