QR code for PDF: how to replace the file after printing

Where a QR code for PDF files shows up

A PDF is the default container for anything that was designed on a page: a restaurant's seasonal menu, a hardware store's price list, the assembly manual in a flat-pack box, a trade fair brochure, the safety data sheet on a drum of solvent, the programme of a three-day conference. In all of those cases the paper object outlives the file. The menu changes every quarter, the price list every month, the programme the night before the event.

A QR code bridges the two: the printed thing stays, the phone fetches the current document. That only works if the link inside the code keeps pointing at a file that exists. There are three common ways to set that up, and they fail in different ways.

Route one: a PDF on your own website

The simplest option is to upload the file to your site, copy the URL (something like example.com/files/menu-autumn-2026.pdf) and put that URL in a static QR code. It costs nothing and needs no new tool.

It breaks the moment someone touches the file. The marketing colleague uploads "menu-winter-2026.pdf", deletes the old one, and the code on 400 printed table cards now returns a 404. Even a cautious team that keeps the same filename runs into caching, where visitors see the old version for hours. And a long URL makes a dense code: a 60-character path lands around QR version 4 or 5, which prints fine on a poster and less fine on a 2-centimetre sticker.

If you go this route, decide on a stable path such as example.com/menu.pdf and overwrite the file in place, never rename it. Put that rule in writing, because the person who prints the cards is rarely the person who uploads the next menu.

Route two: a cloud share link

The second option is to drop the PDF in Google Drive, Dropbox or a similar service and share the link. Google Drive's help page explains that you can set a file to Anyone with the link or keep it Restricted so only named people open it, and that an expiry date on a link is available only for eligible work or school accounts. Dropbox's help page describes view-only shared links that anyone can preview, with passwords and expiry dates reserved for paid tiers such as Professional, Standard, Advanced and Enterprise. Both checked on 7 October 2026.

Share links are convenient for a one-off and fragile on paper. Permissions get tightened by an admin, the file gets moved to a new folder with a new link, the account that owns the file belongs to someone who leaves. The scanner also lands inside a cloud provider's interface, with its own sign-in prompts and its own privacy policy, rather than on a page you control. And a share link is long, so the printed code is dense.

Cloud links are fine for a document you e-mail. For a code that will sit on a wall for a year, you want something whose link never changes, whatever happens to the file behind it.

Route three: a hosted PDF page behind a dynamic code

The third option separates the printed code from the file. You create a page, upload the PDF to it, and print a dynamic QR code that points at the page. When the document changes, you replace the file on the page; the page address and the code stay the same. EUQR's QR code for PDF page works this way: replace the PDF behind the page and the same printed QR code keeps working.

The page adds controls the raw file cannot have. Visitors can read the PDF in the page, you can add a download button or leave it out, and you can lock the page with a password for a document that is not for everyone, such as a dealer price list. The file sits on EU infrastructure and is only reachable through your page, not indexed as a public download. On EUQR, PDF pages are available on Pro and up, at €9 per month.

The link behind the code is a short qreu.eu address, so the code itself is small enough for a sticker or a business card. The same short link can go into an e-mail signature or a social post, which means one document address everywhere.

Why the replaceable file matters more than it sounds

Consider a bicycle manufacturer that ships an assembly guide as a PDF, with a code printed on the box and on a sticker on the frame. Over the production run, the guide is corrected four times: a torque value, a translation, a new photo of the brake lever, a safety notice. With a file on a website, each correction is a race between the upload and someone renaming it. With a share link, each correction is a check that the link still opens for people outside the company. With a hosted page, each correction is an upload, and every box already in a shop points at the corrected version within seconds.

The same logic applies to a café that reprints its menu card twice a year, a property manager with building rules in the lobby, and a festival whose printed programme is final until the headliner cancels. If the document will ever change, choose the route that lets the document change.

Making the PDF work on a phone

Whatever route you choose, the file arrives on a 6-inch screen over a mobile connection, so build it for that. Keep the file size down: compress images, strip embedded fonts you do not need, and aim for a document that opens in a second rather than a download bar. Put the summary on page one: a menu's categories, a manual's quick start, a programme's timetable. Readers rarely scroll to page nine.

Use a readable font size, at least 11 points, and avoid pages that only work in landscape. Test the code by scanning it on an iPhone and on an Android phone, with the PDF viewer each one opens by default; they differ in how they handle links inside the document and in whether they offer a download.

Accessibility: a PDF is rarely the most accessible format

If the document matters to the public, remember that a PDF is not the best format for everyone. The UK government's guidance on publishing accessible documents, updated 9 October 2025, advises publishing in HTML wherever possible, because PDFs often do not work well with assistive technologies such as screen readers, and states that PDF and PDF/A cannot be made fully accessible to every user of assistive technology. Where you do publish a PDF, it recommends real headings instead of bold text, a logical reading order and no images containing text.

A hosted page helps here too, because the page can carry a short HTML summary and the key facts next to the download, so a visitor with a screen reader is not stuck with the file alone. For businesses in the EU, the European Accessibility Act makes this more than good manners for certain services; our article on the EAA and QR code destinations explains which ones. A restaurant that wants to go further can use a QR menu page instead of a PDF altogether, with text the phone can resize.

Version control for a document behind a code

Treat the PDF like software. Put a version number and a date in the footer of the document, so a support colleague can ask "which version does your sheet show?" and get a useful answer. Keep a changelog of what changed in each upload. Keep the previous version in a folder until the new one has been live for a week. Name one owner of the page, with a shared mailbox rather than a personal login, so the page survives a job change.

If you need to know whether the document is actually read, a dynamic code gives you scan counts per code and per placement, without cookies and without storing raw IP addresses. On EUQR you see country, device, browser and language as aggregated counts, which is enough to learn that the code on the box gets scanned and the one on the invoice does not. Plans and limits are on the pricing page; PDF pages start on Pro, which includes 50 dynamic codes.