A restaurant menu QR code is not a design object. It is a bridge between a hungry customer and a page that must load before they lose interest. Most failed menus fail for a boring reason: the code points at a PDF that downloads instead of opens, or at a desktop page that needs pinch-zoom to read a price. The square scans fine; the destination is the problem. This guide covers the destination, the code, print sizes and the update routine that saves reprints.
Part of the free QR code generator guide.
Choose the destination before the code
Three options exist, and they are not equal. A mobile web page is the best default: text stays crisp, prices are easy to update, search engines can read it, and customers can jump to a section. A PDF is acceptable for a short, stable menu. A photo of a printed menu is the weakest: it cannot reflow, blurs when zoomed, and a screen reader cannot read it.
The test is simple. Open the link on a phone using mobile data, not office WiFi. Time how long it takes to show prices, and read the cheapest and most expensive item without zooming. If the page forces a download, opens a Drive preview toolbar, or shows a cookie wall before the food, fix the destination first.
- Mobile page: one column, text-based, sections for starters, mains, drinks and allergens.
- PDF: selectable text, one or two pages, under about 2 MB, stable URL on your own domain.
- Drive or Dropbox: only if anyone with the link can view; preview chrome gets in the way.
- Image-only menu: avoid it; it is a picture of a menu, not a menu.
Build a menu page that works on a phone
Keep the page brutally simple: restaurant name, a one-line description, then menu sections. Use real text for dish names and prices. Group items so a customer can find a vegetarian dish, a gluten-free option or a drink without scrolling through everything. State allergens where you can and tell customers to inform staff of serious allergies.
Set the page to load fast on a mid-range Android: compressed images, no autoplay video, no blocking web font, no email pop-up before the menu. A menu is not a lead magnet. Keep the font readable and test on a flaky connection.
If you must use a PDF
Export from the original design file. Use selectable text, embed the fonts, and name the file lunch-menu-october.pdf. Host it on your own domain and link directly. Test on an iPhone and an Android; some browsers open PDFs, others download them. Print a short URL under the code as a second route. A two-page PDF is fine; a 20-page drinks book is not a menu link.
Generate and size the code
Shorten the link before encoding it. A clean address such as https://example.com/menu produces a sparse pattern that scans at 3–4 cm. A booking URL with tracking parameters can run past 100 characters and produce a dense grid that needs a larger print. If you need a short link, use one on your own domain that you control. Avoid a free shortener you do not administer; if it disappears, every printed code dies with it.
Generate a 2048px PNG for table tents, counter cards and window signs, and 512px only for small cards viewed at arm’s length. Keep black on white with the four-module quiet zone intact. Do not place the code over a food photo, dark brand colour or patterned tablecloth. Matte lamination beats gloss because it does not throw a ceiling light into the camera. The sizing rules are in the QR code print size guide.
Placement: table, counter, window
Put the code where a seated customer can scan it without getting up, and a second where takeaway customers wait. Table tents should sit flat, not inside a curved holder that distorts the pattern. Counter cards need a stand that stops them sliding. Window decals need exterior-grade material out of direct sun, because fading kills contrast.
| Placement | Viewing distance | Minimum size | Material and notes |
|---|---|---|---|
| Table tent | 40–60 cm | 4–6 cm | Matte laminated card, flat base, one per table |
| Counter card | 50–80 cm | 5–8 cm | Rigid stand, wipeable, near the till or pickup point |
| Window or door | 1.5–3 m | 15–30 cm | Exterior-grade vinyl, shaded from direct sun, 2048px |
| Bill folder | 30–40 cm | 3–4 cm | Matte card, paired with a payment prompt |
| Takeaway bag | 40–60 cm | 4–6 cm | Matte sticker, placed on a flat panel, not a fold |
Label the code with its job: “Menu” is enough. If you run separate lunch and dinner pages, label them clearly and keep the codes physically separate. Two unlabelled codes side by side force the customer to guess, and guessing at a table is how a menu QR code gets ignored. If both menus live on one page with tabs, one code is simpler and easier to maintain.
Update the menu without reprinting
A static QR code cannot be edited after printing, but the page behind it can. That suits most restaurants: encode a stable URL you control, then change prices, mark items as sold out and swap the lunch PDF at that URL. The printed code keeps working because the destination has not moved.
If you need to change the destination itself, you have two options. Reprint the code, which is cheap for a table tent and expensive for a window decal, or use a dynamic QR code that routes through a provider. Dynamic codes allow editing and scan counts, but they depend on a subscription; stop paying and the printed code stops working. For a single restaurant with a stable page, a static code paired with a page you control is simpler and has no recurring cost. The trade-offs are compared in static vs dynamic QR codes.
Test the scan before the lunch rush
Print one table tent and one counter card at 100% scale. Disable “fit to page” in the printer dialog, because it shrinks the pattern by a few percent and can eat the quiet zone. Scan both with two phones at the real distance, in daylight and pendant light. Open the menu over mobile data, not restaurant WiFi, and check the load time. Try an older phone with a weaker camera. If the code scans but the PDF downloads, the problem is the destination, not the print.
Do this before a busy service, not during one. A code that fails at 12:30 on a Saturday is a queue of customers holding phones while a server tries to explain. Keep one printed test card behind the till with the date on the back. When the menu changes, test again; a new PDF can break a link that worked last month. Most restaurant failures are destination problems: a moved file, a permission change or a page that no longer exists.
Two worked setups
Example 1 — 40-cover neighbourhood restaurant, Bengaluru. The restaurant builds a one-page menu at https://example.com/menu with sections for small plates, mains, breads, desserts and drinks. Prices are text, not images, and the page loads quickly over mobile data on a mid-range Android. The code is generated at 2048px and printed at 5 cm on matte laminated table tents, one per table, with a second 6 cm card at the pickup counter. The line above the code reads “Scan for the menu.” The manager updates the page when a dish sells out and changes prices there, never on the printed card. A test scan is repeated after every menu edit.
Example 2 — 12-seat bakery, Pune. The bakery has a single-page PDF at https://example.com/bakery-menu.pdf, exported from the original design file with selectable text and a file size under 2 MB. The code is printed at 6 cm on an A5 counter card and at 4 cm on takeaway bags. Because some Android browsers download PDFs instead of opening them, the card also prints the short URL in 14-point type underneath. The owner tests the link on an iPhone and a budget Android after each seasonal change, and keeps the previous PDF at the same URL until the new one works.
Five mistakes that ruin a menu code
- Encoding a login-only file. Set sharing so anyone with the link can view, then test signed out.
- Printing too small. A dense 120-character URL at 2.5 cm fails on older phones. Shorten it or print at 5 cm.
- Using curved or glossy stock. Reflections and distortion break the pattern. Use flat matte material.
- Letting the destination die. Replacing menu-final-v3.pdf breaks the old link. Keep stable URLs.
- Skipping the mobile test. A page that looks fine on a laptop can be unreadable on a phone.