A PDF QR code is only as good as the file behind it

Start by asking what the PDF is for, because that answer decides almost everything else. A restaurant menu needs to open fast, read well on a small screen, and change when dishes or prices change. A product manual needs to stay accurate for the life of the product, and a reader may return to it months after buying. A price list needs a single, trustworthy version, so that no one orders from last season's prices. A conference handout may only need to live for a weekend, but it still needs to open without a login wall or a confusing download step. Write that purpose down in one sentence before you generate the code, and test the final result against it: does this scan give the reader the right document, quickly, on a phone, today and after the next update?

The first practical choice is between encoding the PDF itself and linking to a hosted PDF. A QR code cannot comfortably hold a whole PDF file. Codes are designed for short payloads such as links and contact records, and a long payload makes the pattern dense, slow to scan, and fragile at print size. The standard approach is therefore a link code: the code holds a short web address, and that address opens the PDF. That is also what makes the code maintainable, because the address can stay the same while the file behind it changes, provided you use a dynamic code. A static code locks in the exact address it was printed with, so moving the file to a new address breaks every printed copy. A dynamic code points to a destination you can update, which is the difference between fixing a price list in an afternoon and reprinting a whole batch of posters. For the wider comparison, see static versus dynamic QR codes, and for the edit workflow, see how to edit a QR code after printing.

Where to host the PDF

Host the PDF at a stable, public address that you control, and keep the address short. Your own website, a dedicated landing page, or a file host you manage are all workable, provided the link is unlikely to move, expire, or gain a login requirement later. Avoid addresses that depend on a temporary share link, a personal drive folder with changing permissions, or a shortener you do not control, because any of those can break the printed code without warning. Use a clean file name and a stable folder, for example a documents or menus folder on your own domain, and avoid spaces, special characters, and version numbers in the public address if you plan to replace the file in place. A version number in the address forces a new address for every update, which defeats the point of a stable code.

Check how the PDF opens, not just whether the link works. On most phones, a PDF link opens in the browser or in a viewer, and the reader should see the first page without an extra download step, a sign-in prompt, or a warning about an unsafe file. Test the link on both major phone platforms, on a mobile connection rather than only on office Wi-Fi, and from the printed code rather than only from a typed address. If the host forces a download instead of a preview, a reader on a slow connection may abandon the scan before the file finishes. If the host adds tracking, advertising, or an interstitial page, the scan feels less trustworthy and the reader may not reach the document at all. The host is part of the user experience, not just a storage choice.

Keep one canonical version of the document. When a menu, catalogue, or price list exists in several places, readers and staff quickly lose track of which copy is current. Name the file clearly in your own records, keep the public address unchanged when you replace the file, and note the effective date inside the PDF itself, on the first page or in the footer, so a reader who prints it or forwards it can tell whether it is current. If an old version must stay available, give it a different address and link to it from the new document, rather than letting two competing versions share the same code. For menus in particular, a short, focused PDF that opens to the current menu will serve readers better than a large, general brochure that buries the menu several pages in.

File size: make it fast before you make it pretty

File size is the most common reason a PDF code disappoints. A PDF built from high-resolution photographs, uncompressed scans, or a full print layout can easily run to many megabytes, and that matters on a phone. Large files take longer to download, use more mobile data, and may stall on a weak signal in a restaurant, a hall, or a shop. Compression exists precisely for this trade-off: it reduces the file while trying to preserve visual quality, and the right setting depends on the document. Text-heavy documents usually compress well without visible loss, while image-heavy documents force a choice between a smaller file and sharper photographs. Adobe's mobile guidance describes this directly, offering high, medium, and low compression, with low compression preserving quality best and high compression giving the smallest file at some cost to quality.

Before you compress, reduce the file at the source. Remove pages the reader does not need, crop photographs to the size they will actually be shown at, and avoid embedding the same large image more than once. A menu does not need print-resolution photographs on every page when it will be read on a phone screen, and a price list does not need scanned images of pages that could be real text. Real text has a second benefit beyond size: it can be searched, selected, and read by accessibility tools, while a scanned image of text cannot, unless the scan has been processed to recognise the text. After compression, open the result on a phone and check the pages that matter most, especially small print, prices, and tables. If a price, an allergen note, or a footnote becomes hard to read, the compression went too far, and a slightly larger file is the better choice.

Set a practical size discipline for your own team, even if you do not publish a number to readers. As a working rule, aim for a file that opens promptly on a mobile connection and feels instant on Wi-Fi, and test it on a real phone rather than judging by the file size alone. Some email and upload services impose their own limits, which is a useful reminder that large files create friction everywhere: one mobile compression guide notes that Gmail caps attachments at 25 megabytes, while many job portals limit uploads to 5 megabytes and some forms demand files under 2 megabytes. Those are other services' limits, not a rule for your PDF, but they illustrate the point that a file that is awkward to send is also awkward to open from a scan. If your PDF is still large after compression, split it: a short menu and a separate detailed catalogue, linked from each other, will both open faster than one combined file.

Replace the file without reprinting the code

Replacing a PDF behind a dynamic code is a small workflow, but it needs a checklist so it does not create a silent error. First, prepare the new file and check it on a phone, including the pages that changed and the pages that did not. Second, replace the file at the same public address, or update the dynamic destination to the new address, and keep the old address working until you are sure the new one is correct. Third, scan a printed copy of the code, not just a screen preview, and confirm that it opens the new version. Fourth, check the effective date inside the document and any printed references to the old version, such as a footer that says the prices apply until a certain date. Finally, tell the people who hand out or display the code, such as front-of-house staff, that the document has changed, so no one keeps directing readers to a cached or printed copy of the old file.

Be careful with caching. A reader's phone or browser may hold an old copy of the PDF for a while after you replace it, and a staff member's phone may do the same. That is normal, but it means your test should include a fresh scan after clearing the cache, or a scan on a phone that has not opened the old file before. If you replace a file frequently, such as a weekly menu, consider adding the effective date to the first page in large type, so a reader who sees a cached copy can spot that it is old. If a change is urgent, such as a price correction or a safety note, do not rely on the code alone: update any printed copies, signs, or staff scripts that repeat the same information, and confirm the correction with the people most likely to act on it.

There are limits to what a dynamic code can fix. It can change the destination, but it cannot fix a PDF that was never designed for a phone, a file that is too large to open on a weak signal, or a document that buries the key information on page twelve. It also cannot fix a broken host, an expired share link, or a permissions change that locks readers out. Those are hosting and document problems, and they need to be solved at the source. A good routine is to re-scan your printed PDF codes on a schedule that matches how often the document changes: weekly for a changing menu, monthly for a price list, and before every event for a conference handout. A code that worked at print time is not guaranteed to work forever, and a short, regular check is far cheaper than discovering a broken code from a customer.

Design the PDF for the phone that will open it

A PDF made for print does not automatically read well on a phone. Wide tables, tiny footnotes, and dense multi-column layouts force the reader to pinch, zoom, and scroll sideways, which is a poor experience after a quick scan. If the PDF will mainly be read on phones, set generous type sizes, keep tables narrow, and put the most important information early. A menu should lead with the dishes and prices, not with a history page. A price list should lead with the current prices and the date they apply from. A manual should lead with the safety notes and the quick-start steps, with detailed reference material later. A short, phone-friendly PDF will be scanned, read, and acted on more often than a long, print-perfect PDF that no one finishes.

Keep the code itself scannable, because a PDF code is often printed alongside other information. Use a short link behind the code so the pattern stays sparse and the modules stay large, keep the quiet zone clear, and print the code at a size suited to the scanning distance, following the print size guide. If the code sits on a menu board, a poster, or a handout, add a label that says what the scan opens, such as “Scan for the full menu (PDF)” or “Scan for the price list.” Readers are more likely to scan when they know the result, and they are less likely to be annoyed when a PDF opens if they expected it. If the PDF is long, consider linking first to a short landing page that names the document, its date, and its size, with a clear button to open the PDF, rather than opening a large file without warning.

Finally, plan for the end of the document's life. A menu changes with the seasons, a price list expires, and an event handout becomes irrelevant after the event. Decide in advance what the code should do when the document is no longer current: point it to the new version, point it to a page that says the document has been replaced, or retire the printed material. Leaving a code that opens an outdated price list or a past event programme is worse than having no code at all, because it teaches readers that your codes cannot be trusted. A PDF code earns its place by staying current, opening quickly, and giving the reader exactly the document they expected, in a form they can actually read on the phone in their hand.