How to Make a QR Code for a PDF

Start with the thing nobody says out loud: a QR code cannot contain a PDF.

A QR code stores a few hundred characters at most. The largest version holds around 3 KB of raw data, and that is with error correction turned down to a level you would never print. A one-page PDF is a hundred times that. There is no encoding trick, no compression setting, and no premium tier that changes this.

So every product advertising a "PDF QR code" is doing the same thing: hosting your file somewhere and putting a link to it in the code. That is fine. It is the only way it can work. But it reframes the question usefully, because the decision is not how do I put a PDF in a QR code. It is who holds the file, and can I change it later.

The four places a PDF can live

Your own website. Upload to /files/menu.pdf and point the code there. Free if you already have hosting, and the URL is yours forever. The catch is that you now maintain it, and a site migration that changes URLs breaks every printed code silently.

Google Drive or Dropbox. Free and instant. The viewer wraps your document in a file-sharing interface with sign-in prompts and download buttons, sharing permissions drift over time, and a printed code that shows "Request access" is worse than no code. Fine for internal use, poor for anything printed for the public.

A QR service that hosts the file. Upload, get a code, done. Nothing to maintain and no page to build. The thing to check is whether the file can be replaced later without a new code, because that is the entire advantage and not every service offers it.

A static code with the URL baked in. Works, but the destination can never change. Only sensible when the document genuinely never will.

The decision that matters: static or dynamic

Both look identical. The difference is in what was encoded.

A static code has the destination in the pattern itself. Change the URL and you change the pattern, which means reprinting everything.

A dynamic code encodes a short link you control. The printed pattern is fixed, the destination is a setting. (Full comparison here.)

For a PDF, dynamic wins almost every time, because documents get revised. The price list changes quarterly. The instruction sheet gets a correction. The programme loses a speaker the night before. If the code is static, each of those is a print run.

How to make one

1. Upload the PDF. Most documents are well under the limits: a text-first PDF is usually under 1 MB, a brochure with photography is 3 to 15 MB.
2. Point a dynamic code at it. The code encodes a short link to the hosted file.
3. Style and download. SVG or PDF for print, PNG for screens.
4. Test on a real phone before the print run, at the distance and lighting the code will actually live in.

How big can a PDF be

Worth knowing where real documents fall, because the limits are rarely the constraint people expect.

One large-corpus study of PDFs found a mean size of about 70 MB against a median near 10 MB, which tells you the distribution is dominated by a small number of enormous unoptimised files. Design against the median and your own use case, not the average.

If your PDF is genuinely huge, the usual culprit is uncompressed images. Exporting at 150 DPI instead of 300 typically cuts a photo-heavy document by more than half, and nobody reading on a phone can tell.

What the person scanning experiences

The PDF opens in the phone's built-in viewer. No app, no download step, no page to load first. They can pinch to zoom, scroll, and save or share it from there.

Two honest limitations. A dense multi-column layout designed for A3 is hard work on a 6-inch screen, so if the document will mostly be read on phones, export a phone-shaped version. And a PDF is a document, not an interface: no forms, no ordering, no interactivity beyond links inside the file.

Replacing the document later

This is the payoff, and the step people get wrong.

Replace the file in place. The link stays the same, so every code already printed serves the new version. That is what makes a dynamic code worth using.

Do not upload the new version as a separate file and point a new code at it. That creates a new link, and everything already printed still points at the old document. The distinction matters most in exactly the situation where it is easiest to miss: you are in a hurry, the document changed, and uploading feels like the obvious move.

Where a PDF QR code earns its keep

• Price lists and catalogs. The list changes every quarter; the code on the folder does not have to.
• Event programmes. A speaker drops out and the printed programmes are already stacked at the door.
• Instructions and manuals. A code on the box pointing at the current guide rather than whichever shipped that year.
• Spec sheets, certificates and lab results. Attach compliance documents to the physical thing they describe.
• Restaurant menus. Common enough to deserve its own guide.

Things worth checking before you commit

• Does the code expire? Many free generators stop redirecting when a trial ends, which turns every printed document into a dead end. SunriseQR codes never expire, on any plan.
• Can you replace the file? If not, you have an expensive static code.
• Can you see scans? Scan tracking tells you whether anyone opened the document, and from where.
• Does the viewer add friction? Sign-in walls and download prompts between a scan and the document lose people.

Try it

Upload a PDF and get a QR code. The next version of the document goes behind the same code.