How to make a QR code for a PDF

Can a QR code hold a PDF?

A QR code cannot hold a PDF. It stores a few hundred characters and a PDF is hundreds of thousands, so what the code actually holds is a link to a file hosted somewhere else. That makes this a hosting question wearing a QR costume, and every way it goes wrong is a hosting problem rather than a code problem.

Once that is clear the whole task reorders itself. The code takes a minute. Deciding where the file lives, and whether that address survives, is the part worth thinking about.

Where the file lives is the real decision

Whatever you encode has to still resolve the day somebody scans it, which may be a year after printing. Three common choices, with their actual failure modes.

Your own website. Best case. You control the address, it is short, and you can replace the file in place. If you have a site, put the PDF on it.

Google Drive, Dropbox, OneDrive. Workable and by far the most common. Two cautions: the addresses are long, which makes the symbol denser and harder to print small, and access depends on a sharing setting that a colleague can change months later without knowing it is load-bearing for printed material.

Whatever the design tool gave you. Worst case, and the one that produces the most complaints. A file hosted inside a design or presentation tool often sits behind a temporary or account-scoped address that was never meant to be printed on anything.

Long addresses make worse codes

This is the part nobody mentions and it decides whether the code is printable. A QR code is a grid, and every extra character adds modules. A cloud sharing address of 90 or 120 characters produces a much denser symbol than a short link of 30, and at a fixed printed size denser means each module is narrower.

Below roughly 0.4mm per module a phone camera starts to struggle. So a long address on a business card or a menu corner is not merely inelegant, it is the difference between a code that scans and one that does not. Our size calculator works from the real symbol version rather than a rule of thumb.

Updating the document without reprinting

This is the argument for not encoding the file address at all.

Documents get replaced. A menu changes with the season, a price list changes with the year, a form is superseded, a typo is found. When the file changes, most hosting gives the new version a new address, and a code encoding the old one is now pointing at a document you have withdrawn, or at nothing.

Encode a short link that redirects to the file instead. Replace the document, re-aim the redirect, and every code already printed follows within about a minute. This is the same argument as dynamic versus static, and PDFs are where it bites soonest, because documents are revised far more often than posters are reprinted.

It also fixes the sharing-setting problem. If access breaks, you repair the destination rather than the printed material.

When it works for you and not for them

Nearly always the file rather than the code. In rough order of how often we see it:

The link needs an account, so a stranger gets a sign-in screen rather than the document. The file is large and gives up on a slow mobile connection. The host serves it in a way that makes the phone try to save rather than display it. Or the sharing permission has quietly reverted.

The test that catches all four takes a minute: open the encoded address on a phone that has never seen the file, signed out, on mobile data rather than the office wifi. That is the condition the person holding your flyer is actually in.