linking to files

How to make a QR code link to a PDF

A QR code can't hold a PDF — it holds a link. Here's how to host the file, point a code at it, and dodge the traps that make PDF codes flaky.

The short version: a QR code can’t hold your PDF. It holds a small web address, and the phone fetches the file from there. So the real job isn’t “putting a PDF in a code” — it’s putting the PDF online, copying its link, and turning that link into a code. That’s genuinely all a “PDF QR code” is. Below is how to do it properly, and the handful of traps that quietly make these codes unreliable.

Why the file can’t live inside the code

A QR code is a data container measured in bytes, not a place to embed a document. Its absolute ceiling is about 2,953 bytes — just under 3 KB — and even that only exists at the largest, densest size (Version 40, 177x177 squares) with the lowest error correction, which many scanners can’t read reliably anyway.

At the small, sparse sizes people actually print, capacity is far lower. A Version 1 code (21x21 squares) holds only about 17 bytes of arbitrary data; the higher the error correction, the less it holds (a Version 1 drops to 7 bytes at the top level). A useful PDF — a menu, a brochure, a form — runs from tens of kilobytes to several megabytes. That’s hundreds to thousands of times bigger than anything a code can carry. A near-empty PDF of a few hundred bytes could technically squeak in, but nothing with real content on it. So the file goes online, and the code just points at it.

The method, start to finish

Host the PDF at a public web address. Somewhere anyone can open without logging in — see the next section for where.
Open the link and test it. Paste it into a private/incognito browser window. If it opens the PDF (or downloads it) without asking you to sign in, it’s ready. If it demands a login, the sharing setting is wrong.
Turn that link into a code. Paste it into a generator — you can build a QR code at dottr in your browser — and download the PNG or SVG.
Test the printed code on a real phone, ideally at the size you’ll actually print, before you send it to the printer.

That’s the whole workflow. Everything else is about making it robust.

Where to put the PDF

Your own website or CMS media library. The best option. You get a clean, permanent URL you control (something like yoursite.com/menu.pdf) and predictable behaviour. If you ever update the file, you can overwrite it in place and keep the same address — no reprint.
Cloud storage (Google Drive, Dropbox, OneDrive). Works, with caveats. You must set the file’s sharing to public / anyone with the link — the single most common reason a scanned code lands on a “request access” wall. Note that on work or school OneDrive/SharePoint accounts, an admin may have switched the “anyone with the link” option off entirely.

A normal share link from Drive, Dropbox or OneDrive usually opens a preview page in that service — its app shell wrapped around your file — rather than handing over the raw PDF. Often fine, but it means an extra tap and a long, messy URL. Each provider has a “direct” option, and they’re not equal:

Dropbox is the tidiest: adding ?dl=1 forces a download and ?raw=1 renders the file inline. The dl parameter is documented behaviour, and raw=1 is a long-standing, widely-used option. The catch is traffic limits — free accounts cap at around 20 GB and 100,000 downloads a day, and a busy link can be temporarily disabled for “too much traffic.”
Google Drive has an unofficial direct-download trick (uc?export=download&id=…), but it’s fragile: files over roughly 100 MB return a “can’t scan for viruses” page instead of the file, and Google has already changed these URLs once — downloads now route through drive.usercontent.google.com, which broke older links. Treat it as something that can break without warning.
OneDrive is the least reliable for direct links. On free/personal accounts the old embed-to-download trick no longer works and there’s no native direct-download option at all — links route through a preview page by design.

The honest takeaway: if you want a link that won’t break or throttle, host the file somewhere you control. Cloud storage is the convenient path, not the durable one.

Want to stop people downloading it?

You can, roughly. Giving people “Viewer” access shows the file in the provider’s preview — but by default a viewer can still download, print and copy it. To actually keep them in the preview you have to switch off the extra download/print/copy option (Google Drive) or turn on “block download” for view-only files (OneDrive/SharePoint for Business). Even then it isn’t watertight: behaviour varies by file type and on the mobile apps, and a screenshot captures the content regardless. If it truly must not leak, a PDF behind a link is the wrong container.

Put a short link in front of it

A raw Drive link runs about 80 characters; a modern Dropbox link often tops 100. All those characters force a higher-version, denser code — roughly Version 5-7, so 37-45 squares a side. At a given print size that means smaller squares, which needs a bigger minimum print size, better light, or a closer scan to read reliably.

A short link (~15-25 characters) keeps the code at a low version — around Version 2-3, 25-29 squares — so the squares stay large and it scans with more margin. The difference matters most when the code is printed small, on a card or packaging, or scanned in poor light. If you want the mechanics, how short links work covers it, and what size to print a QR code explains the density-versus-size trade-off in full.

The trade-off is honest: a short link adds a redirect and hides the real destination, so it only keeps working as long as the shortening service stays alive.

Change the PDF later without reprinting

Here’s the quietly useful part. If the printed URL never changes, you can swap the PDF behind it — a new menu, an updated price list — with no reprint. That’s the static vs dynamic idea applied to files.

There are two ways to get it:

Host it at a stable address you control and overwrite the file in place (or add a server-side redirect). The URL stays the same, the document changes.
Point the code at an editable short link and re-aim it whenever you like. This is the one to use when you don’t control the hosting — and it saves you from the common trap where re-uploading to Google Drive or Dropbox mints a brand-new URL, which would otherwise force a reprint.

Just make sure it’s an editable/dynamic redirect, not a permanent shortened URL you can’t re-aim.

Will it open, or download?

Worth flagging because it’s genuinely inconsistent. Whether the PDF opens in the browser or downloads in the background varies by phone, OS and browser. iOS/Safari tends to render PDFs inline; Android often downloads them quietly. It’s also influenced by how the file is served (a “direct download” header can force the download), so modern Android Chrome can render inline too. One more thing: some third-party scanner apps won’t render a PDF at all — tell people to use their normal camera, which is more reliable. If a code “seems not to work,” this behaviour is often why, rather than anything wrong with the code itself.

Keep it light — or skip the PDF

Be honest with yourself about the file. A heavy PDF is slow to open over mobile data, because a viewer generally has to download the whole thing before showing anything. Aim to keep it optimised — under about 5 MB is comfortable on a phone.

And sometimes the better answer is not a PDF at all. A PDF is laid out for paper, so on a phone it forces pinch-zoom and sideways scrolling. Where you can, link a clean, mobile-friendly web page instead — it reflows to the screen and loads progressively. This is exactly the advice in the restaurant QR guide: a web menu beats a desktop PDF menu almost every time.

Making one in dottr

dottr runs entirely in your browser and doesn’t host files — it simply encodes whatever URL you give it. So the flow is: host the PDF elsewhere, then paste its link. In the wallet there’s a Document / PDF preset with a single “Public file link” field, and its hint says exactly what matters: use a public link (Drive set to “anyone with the link”, or Dropbox) and test it in a private window first so you know it opens without a login.

Get the link right and the code follows for free. Generate one here — it’s free, runs entirely in your browser, and nothing you paste ever leaves your device.