QR Code for a Menu

Point a code at your menu page and print it on a table tent, a window sticker or the bottom of a receipt. The whole appeal over a laminated paper menu is that this one can change without anyone touching the table.

QR Code Name

Content

Colors

Eye & Dot

Rounded · Rounded

Frames

None

Preview

Logo (optional)

Size: 300px

200px600px

Download

Point at a page, not a raw PDF, where you can

A hosted web page loads faster on restaurant Wi-Fi or patchy mobile signal, resizes properly on a small screen, and does not force a download before anyone can read it — a PDF opened in a phone browser often does exactly that. If your menu genuinely only exists as a PDF, encoding that link directly is still far better than nothing, but hosting even a plain HTML version is worth the half hour it takes.

Whichever you use, check the destination on the cheapest phone you can find, on mobile data, before the table tents go to print. A menu that needs pinching to zoom is the single most common complaint about QR menus, and it is a page problem, not a code problem.

This is what a dynamic code is actually for

A menu changes more often than almost anything else you would put a code on: seasonal items, price updates, an ingredient going out of stock. Save this code here as a dynamic one and the destination becomes something you edit in a dashboard — the table tents printed this month keep working after next month's menu update, because the printed pattern never encoded the menu itself, only a redirect to wherever it lives now.

The alternative — a static code baked with this week's menu URL — is fine if your menu page's address genuinely never changes. It is a bad trade if a redesign or a new POS system ever changes the URL, because every printed copy breaks at once with no way to fix it short of reprinting the whole run.

What gets encoded

https://example-restaurant.com/menu

A standard https link to wherever the menu lives — a web page or a hosted PDF. Saved as a dynamic code, the printed pattern encodes a redirect instead, so the destination stays editable.

Host the menu as a web page rather than a PDF when you can — it loads faster and resizes better.
Save the code as dynamic so a price or menu change does not strand every table tent already printed.
Test the destination on a real phone over mobile data before the print run goes out.

Questions

Should I link to a PDF or a web page for my menu?

A web page, if you can host one — it loads faster on weak signal and resizes correctly on a phone screen, where a PDF often forces a download or opens too small to read without zooming. A PDF is a reasonable fallback if a web page is not an option.

What happens if my menu prices change after I print the codes?

If the code is saved as a dynamic one, nothing — you update the destination in your dashboard and every already-printed code starts pointing at the new page immediately. If it is a static code encoding a page whose content you can already edit yourself, that also works, since the URL never changed. It only breaks if the menu's own web address changes.

Can one code work for lunch and dinner menus?

Yes, if the destination page itself switches content by time of day, or links out to both. The code only needs to reach a page; what that page shows is entirely up to you and can change without touching the code.

Read next

QR Code Menus for Restaurants: Setup, Pitfalls, and Best Practices

Need a different kind of code? All nine types are on the CQRG generator.