How I set up a PDF QR code for a menu

A PDF QR code should point to a PDF URL. Encoding the file itself into the QR code makes the symbol dense, harder to scan, and painful to update.

The setup I use is simple: upload the PDF, copy the hosted file URL, generate the QR code, print a proof, scan it from a few phones, then keep the source PDF easy to replace.

Why the URL matters

Keep the QR payload short

QR codes get bigger and denser as the encoded data gets longer. DENSO WAVE's QR Code documentation explains that higher versions add more modules, and that capacity depends on data type and error correction level.

For a menu, the right payload is a short HTTPS URL. After the customer scans the code, the browser opens the URL and the PDF downloads or displays. A menu can be 2 pages or 20 pages while the QR code still only carries the URL.

Debugging is easier with a URL-based setup. If a customer says the menu did not open, I can test the URL in a browser, test the QR scan, and test the PDF separately instead of guessing which part failed.

Compress the PDF before printing the code

Mobile speed matters more than print perfection

A giant PDF makes the scan feel broken on a weak connection. Adobe's Acrobat documentation lists the usual file-size cleanup work: downsample images, handle fonts, flatten transparency, discard unused objects, discard private user data, and clean up invalid elements.

For a restaurant menu, I want the file small enough to open quickly on mobile while keeping text readable. I also check that phone numbers, allergens, prices, and specials survive the export. A beautiful menu that opens slowly is still a bad menu.

I prefer real text in the PDF when possible, not one giant image per page. Text stays sharper, file sizes are usually smaller, and customers can zoom without turning the menu into a blur.

Where I host the PDF

The URL should survive the next edit

The best PDF host is the one the business can still control when the menu changes. A random file URL from a designer's folder is risky. A URL owned by the business, the website, or the QR campaign system is easier to maintain.

I also avoid URLs with long tracking junk in the printed code. Long URLs make denser QR codes, and dense codes are less forgiving on small print. If analytics matter, I prefer a short dynamic link that records scans before sending the customer to the current PDF.

The PDF should open without asking the customer to install an app, sign in, or request access. This sounds obvious until someone uploads the menu to a private drive folder and prints 500 table cards. I test in a private browser window before sending anything to print.

What I check inside the PDF

The menu still has to work as a document

A QR code cannot fix a bad PDF. Before generating the code, I check the menu as if I were the customer standing in line. Prices should be readable. Sections should be obvious. Specials should not depend on a tiny image caption. Phone numbers and booking links should be selectable when the PDF supports it.

I look at the first screen on a phone. If the PDF opens zoomed out to a full poster, the customer has to work too hard. A narrow mobile-friendly PDF or a web page is often better, but many restaurants already have a print menu PDF. In that case, compression and layout checks matter.

File names matter too. `menu.pdf` is better than `FINAL_Menu_New_new2.pdf`, and a dated internal source file is better than guessing later. Customers may never see the file name, but the team maintaining the QR code will.

When static is enough

Use static for stable, cheap print

• The PDF URL will not change.
• The menu is seasonal, not weekly.
• The QR code is on cheap print material.
• No one needs scan analytics.

Static works for a quick flyer or a small batch. Generate the code, download the PNG, put it on the print file, and test the proof.

The risk is simple. If the PDF URL changes, the printed static QR code still points to the old URL. A throwaway flyer can survive that mistake. Laminated menus, window decals, and table stands make the same mistake expensive.

Static also works when the menu is hosted at a permanent URL on the business website and the file can be replaced behind that URL. In practice, many businesses change the path every time they upload a new PDF. I ask how updates happen before choosing static.

When I use dynamic

Use dynamic when the printed object needs to last

I use a dynamic QR code when the menu changes often, the code is printed on signs or table tents, or the business wants to track scans. The printed QR points to a stable short link. Behind that link, the PDF can change without changing the printed code.

This is the part that saves money. A price change should mean replacing a file, not reprinting every table card.

Dynamic also helps agencies. One client may need a breakfast menu, lunch menu, seasonal menu, and catering PDF. Keeping each code as a named campaign is cleaner than passing around a folder full of final-final PDFs.

Scan analytics are useful here, but I do not overread them. A scan is not a customer count. One customer can scan twice, staff can test the code, and a table of four may use one phone. The data is still useful for spotting dead signs, popular locations, and print materials that nobody uses.

My print check

Test the printed proof like a customer

• Scan the printed proof, not only the screen preview.
• Try iPhone and Android cameras if the business has both nearby.
• Keep enough white space around the QR code.
• Do not place the code over a photo or textured background.
• Open the PDF on cellular data, not only office Wi-Fi.

If the scan is slow, I shorten the URL, compress the PDF, or switch to a dynamic short link. Then I test again.

The update workflow

Replacing the menu should be boring

The real test comes after the first price change. I want a workflow where someone can upload the new PDF, update the destination if needed, scan the old printed code, and see the new menu. The update should not require opening the design file, ordering a reprint, or searching through old emails.

For teams, I name campaigns by location and menu type: Orchard lunch menu, Downtown drinks menu, Catering PDF. That keeps the dashboard understandable when there are dozens of codes. A vague name like QR 1 is fine on day one and useless three months later.

I keep the old PDF for a short while after replacing it. If someone reports the wrong menu, I can compare the previous file, the new file, and the destination history. Most problems are simple: the wrong PDF was uploaded, the browser cached an old file, or the print proof used a draft QR code.

Once that workflow works, the QR code becomes boring infrastructure. Customers scan, the current menu opens, and menu changes no longer trigger a print panic.