Should a restaurant menu QR be static or dynamic?

Static is often enough when the QR points to a stable URL you control and only the menu content changes. Dynamic is useful when the encoded destination itself may change or you want hosted scan analytics.

Should a QR menu link to a PDF?

A well-designed mobile-friendly PDF can work. A responsive web menu is usually easier to navigate and update. If you use a PDF, keep the URL stable so replacing the file does not break printed QRs.

What size should a restaurant menu QR be?

Around 30–50 mm is a useful table-use starting range, but actual size depends on scan distance, density, finish and placement. Test the final physical piece.

Should every table have a different QR?

Only if table identity or table-level attribution provides real value. For simple menu access, one shared QR is easier to operate.

Can I change the menu without changing the QR?

Yes if the QR points to a stable URL whose content you control, or if it uses an editable dynamic redirect.

Is a QR menu the same as QR ordering?

No. A menu QR simply routes to menu information. Table ordering can require POS, cart, payment and table-token functionality that a QR generator alone does not provide.

Can I track menu QR scans?

Yes with an analytics-enabled dynamic QR. Treat scans as menu access/attention, not automatically as orders or revenue.

Restaurant Menu QR Code: Static vs Dynamic, PDF vs Web & Print Guide (2026)

On this page

The QR itself is rarely the hard part.

The hard part is choosing an architecture that still works after:

the menu changes;
a PDF filename changes;
the restaurant switches ordering platforms;
lunch and dinner use different menus;
a table tent gets laminated;
glare appears under dining-room lights;
a multi-location brand accidentally sends one store's customers to another store's review/menu page.

That is why “static vs dynamic” is not the first question.

The first question is:

“What URL or content layer will remain stable even when the menu changes?”

In many restaurants, a free static QR is completely sufficient.

In others, an editable dynamic route is worth paying for.

This guide explains the difference without pretending every menu needs a subscription.

Quick recommendation

For most restaurants:

use a mobile-friendly web menu as the default destination;
a PDF can work when it is properly designed for phones, but should not be the automatic first choice;
if the menu stays at a stable URL you control, a static QR can remain perfectly useful even while prices and dishes change;
use an editable dynamic QR when the encoded destination itself may change — for example when switching menu/ordering providers;
for table use, start around 30–50 mm depending on distance, density, layout and finish, then test the actual physical piece;
use upright table tents when practical instead of tiny flat stickers;
avoid strong gloss/reflection across the QR;
use separate QR records by placement or location only when the analytics are worth the operational complexity;
test the real dining-room journey: scan → menu loads → diner can actually read and use it.

The most important correction to generic QR advice is:

A changing menu does not automatically require a dynamic QR. A changing encoded URL is what creates the strongest case for dynamic routing.

Suppose your QR encodes:

https://restaurant.com/menu

You control that page.

Today the page shows:

summer menu

Next month you replace the page content with:

fall menu

The QR does not need to change.

The encoded URL stayed the same.

That means a free static QR can support an endlessly changing menu as long as the URL remains stable.

This is a crucial distinction because many QR articles say:

“Menus change, therefore use dynamic QR.”

That is incomplete.

The more accurate rule is:

menu CONTENT changes
+
same stable URL
→ static QR can be enough

versus:

encoded menu URL changes
→ dynamic QR or your own redirect layer becomes useful

This one distinction can save restaurants from paying for infrastructure they do not need.

What should a restaurant QR link to?

A phone menu should behave like a phone page, not like a desktop brochure squeezed onto a small screen.

A useful mobile menu should make it easy to:

choose a section;
read item names and prices;
understand dietary labels;
see current availability if the site supports it;
navigate back without losing place;
change language where relevant.

The QR does not need to open a complex ordering app if the restaurant only wants to show the menu.

Use the simplest destination that completes the dining job.

PDF is not automatically wrong.

It is just a different format with trade-offs.

PDF can be reasonable when:

the menu is short;
typography remains legible on a phone;
the file is lightweight;
the URL can remain stable;
the restaurant already maintains the menu as a PDF;
no interactive ordering or navigation is needed.

A mobile web page is usually stronger when:

menus are long;
customers need categories/navigation;
accessibility matters;
the restaurant updates items often;
mobile readability is important;
links, ordering or booking are included.

A bad PDF forces the diner to:

open
→ pinch
→ zoom
→ drag
→ lose place

That is unnecessary friction.

A good responsive page can present the same content at readable size immediately.

The PDF filename trap

A static QR becomes fragile when it directly encodes a disposable file path such as:

restaurant.com/files/menu-summer-2026-v4-final.pdf

Then the restaurant uploads:

menu-fall-2026.pdf

and deletes the old file.

The printed QR now points to a dead URL.

Better architectures:

Stable URL

restaurant.com/menu

and the page links/embeds the current file.

Stable PDF route

restaurant.com/current-menu.pdf

where the server replaces the file behind the same route.

Editable redirect

printed QR
→ managed redirect
→ current PDF/page

The best solution is often URL architecture, not the QR product.

Use static when:

you control a stable menu URL;
no hosted QR analytics are needed;
you are comfortable managing the page yourself;
the QR should have the fewest provider dependencies.

Architecture:

printed QR
→ restaurant.com/menu

The menu can change every day.

The QR does not care as long as the URL remains the same.

This can be the best solution for a restaurant with a competent website.

Dynamic becomes valuable when the first URL needs to stay fixed while the destination behind it may change.

Examples:

Switching ordering platforms

2026
QR → ordering-platform-A

2027
same QR → ordering-platform-B

Seasonal destinations

summer
QR → summer-menu

holiday
same QR → holiday-menu

Temporary outage

If the normal destination fails, an editable QR can be repointed to a fallback page.

Multi-stage rollout

A restaurant launching before its final menu site is ready could initially route to a temporary page, then change the destination later.

OwnQR currently offers a US$15 one-time dynamic QR option and a US$39 five-code pack. No recurring subscription is required for those one-time plans. OwnQR also offers an optional monthly plan.

Hosted redirects still depend on OwnQR's service and current Terms.

If a printed static QR must be redirected to a new destination, see how to change a QR code destination after printing.

The better long-term restaurant strategy: own the stable URL

For many restaurants, the most durable architecture is:

printed static QR
→ restaurant.com/menu

Then the restaurant controls:

restaurant.com/menu
→ whatever current menu system it wants

This provides flexibility without making a third-party QR redirect the first dependency.

Benefits:

brand-owned URL;
easier migration;
no QR subscription required;
website analytics can still measure page visits;
menu provider can change behind the route.

Trade-off:

the restaurant must maintain the domain, hosting and redirect/page configuration.

This is often a stronger long-term answer than simply choosing “dynamic” by default.

One QR for every table, or one QR per table?

This is an operational decision.

One shared QR

Every table uses the same code.

Advantages:

easiest to manage;
same print artwork;
fewer QR records;
simple replacement.

Best when:

you only need menu access;
table-level analytics are unnecessary.

Separate QR per table

Each table has its own QR record.

Potential benefits:

placement/table scan counts;
table-specific ordering if your destination system supports it;
source attribution.

Trade-offs:

many more records;
more mapping risk;
easier to print/place the wrong code;
OwnQR itself does not become a restaurant ordering system merely because each table has a unique QR.

If table identity is required by a POS/order platform, that platform must actually support the parameter/workflow.

Do not create unique QR codes merely because uniqueness sounds sophisticated.

One QR per placement can be useful

A simpler measurement strategy is to separate by placement, not every table.

Example:

DINING-TENT
WINDOW
TAKEAWAY
RECEIPT
PATIO

All can point to the same menu.

Then you can compare which physical placements get scans.

That helps answer:

do window scans happen after hours?
are receipt QRs actually used?
does the patio need a larger sign?
are flat table stickers ignored compared with upright tents?

This is more actionable than one giant combined scan count.

These are not the same product.

Job:

show information.

Destination:

menu web page;
PDF;
category page.

Ordering QR

Job:

identify table/customer and start a transaction.

That can require:

table token;
cart;
item availability;
payment;
POS integration;
kitchen routing.

OwnQR should not claim those capabilities.

A QR generator can produce the routing code, but it is not automatically the ordering system behind it.

Also keep review intent separate.

A menu QR should not suddenly become:

scan menu
→ leave Google review

unless the diner deliberately chooses that action through the destination.

Use a separate Google Review QR placement after the customer experience, such as:

receipt;
checkout card;
exit counter;
follow-up message.

Different QR jobs should have different calls to action.

Restaurant scanning usually happens around:

20–50 cm

depending on where the code sits.

A practical starting range is often:

30–50 mm

for upright table tents or menu cards, with larger sizes for more distant placements.

But the correct size depends on:

QR density;
print quality;
glare;
scan angle;
table layout;
user posture.

Use the minimum QR code size guide rather than treating one measurement as universal.

For broader print-quality guidance on contrast, glare and quiet zone, see the QR code print best practices guide.

Why upright table tents can outperform flat stickers

A flat sticker creates a specific physical interaction:

phone camera
directly above table
→ phone/body casts shadow

It can also be covered by:

plates;
glasses;
menus;
napkins;
food spills.

An upright table tent can:

face the diner;
reduce phone shadow;
keep the QR visible;
allow a larger code and CTA.

Flat stickers can still work well, especially on clean uncluttered surfaces. The point is to test the actual restaurant geometry.

Gloss, acrylic and restaurant lighting

Restaurant finishes create unusual glare.

A QR that works in an office may fail when:

laminated;
placed under a pendant light;
printed behind acrylic;
viewed at an angle;
covered by fingerprints/cleaning residue.

Matte finishes are often more forgiving.

If you use acrylic or gloss for brand reasons, test it in the real dining room at service time.

Do not approve the print because it scanned under daylight beside the printer.

What should the call to action say?

A restaurant QR should be obvious.

Good:

Scan for menu
View menu
Scan for drinks
Scan for lunch menu

Avoid vague copy such as:

Scan me
Discover
Tap into the experience

when the actual action is simply reading the menu.

Clear language reduces uncertainty and speeds the customer journey.

For critical access, consider printing a short fallback:

restaurant.com/menu

This helps when:

a phone camera fails;
a diner prefers typing;
accessibility needs differ;
the QR is viewed in a photograph.

It also reinforces the restaurant's own domain rather than making the QR the only path to the menu.

Accessibility: the destination matters more than the QR

A QR can scan perfectly and still create a poor experience.

The menu destination should consider:

readable font sizes;
text contrast;
zoom behavior;
logical headings;
alt text where images convey menu information;
screen-reader usability;
clear allergen/dietary information where appropriate.

A scanned PDF image of a printed menu may be visually attractive but inaccessible.

The QR is not an accessibility feature by itself.

It is only the doorway.

Multi-location restaurants

Never assume one review/menu destination fits every location.

For menus:

shared menu can be fine if menus are identical;
location-specific pricing/items require location-specific destinations.

For Google reviews:

each location should use its own Business Profile review destination.

Name QR records clearly:

VANCOUVER-MENU-TENT
RICHMOND-MENU-TENT
BURNABY-MENU-TENT

Do not risk sending Richmond customers to Vancouver's menu/review page.

What does scan analytics actually tell you?

A QR scan can tell you that someone interacted with the code.

It does not automatically tell you:

they read the whole menu;
they ordered;
they spent money;
they liked the meal.

A useful funnel is:

QR scan
→ menu page load
→ category/item interaction
→ order/checkout (if system supports it)

OwnQR's scan analytics can help measure the first step.

Your website/POS/order platform must measure the downstream steps.

Do not call QR scan count “restaurant revenue.”

Diagnose the layer.

Can phone detect QR?
        |
       YES
        |
Does URL open?
        |
       YES
        |
Does menu destination work?

Potential failures:

menu file deleted;
hosting outage;
ordering platform down;
wrong redirect;
expired domain;
network issue.

If the QR is editable and the normal menu system is unavailable, repointing to a fallback page can be operationally useful.

If the QR is static to a URL you control, you may still be able to update that page or redirect it.

Provider shutdown risk

Restaurant QR codes may remain printed for months or years.

If a dynamic QR uses a provider-owned redirect hostname, the provider is part of the menu infrastructure.

Before printing at scale, ask:

who controls the encoded hostname?
what happens if the QR plan ends?
what happens if the provider closes?
can the mapping be exported?
can the restaurant use its own domain instead?

See what happens when a QR provider shuts down and Do QR codes expire?.

The restaurant pre-print acceptance test

Destination

mobile-friendly;
correct current menu;
no login;
loads quickly;
exact location/menu;
fallback URL works.

Physical print

correct QR record;
adequate size;
quiet zone;
strong contrast;
final material;
final laminate/acrylic/finish.

Dining-room test

Test at:

actual table;
actual seating distance;
actual lighting;
phone held naturally;
iPhone;
Android.

Journey

Do not stop when the browser opens.

Confirm:

menu is readable without excessive zoom;
sections are navigable;
pricing is clear;
order/booking links work if included;
diner can return to the menu easily.

What current Google top results already do well

Current high-ranking restaurant QR pages already cover:

dynamic updates;
static-vs-dynamic;
PDF-vs-web;
table size;
glare/shadow;
scan analytics;
editable menu links.

OwnQR must therefore do more than repeat “menus change.”

OwnQR information gains

Separates changing menu content from changing encoded URL.
Shows why a stable restaurant-owned URL can make a static QR fully sufficient.
Introduces the stable PDF route strategy rather than only saying “never use PDFs.”
Separates menu QR, ordering QR and review QR into different jobs.
Adds one-per-table vs one-per-placement operational economics.
Adds multi-location naming/routing discipline.
Adds accessibility requirements for the destination, not the QR image.
Models scan analytics as the first step in a restaurant funnel rather than revenue.
Adds a fallback during menu-provider outage.
Requires a real dining-room proof under final lighting and finish.

Those are the minimum information-gain requirements for this owner.

First-party evidence requirement

Before publication:

Test A — static stable URL

Create:

restaurant.com/menu

Generate a static QR, update page content, prove the same printed QR still opens the updated menu.

Test B — editable destination

Use a real OwnQR dynamic test:

destination A
→ same printed QR
→ destination B

Test C — physical restaurant proof

Print on:

matte card;
actual table tent or sticker;
optional acrylic/gloss variant.

Test:

real lighting;
upright vs flat placement where relevant;
iPhone + Android.

No synthetic restaurant screenshots.

The bottom line

A restaurant menu QR should be treated as part of the menu infrastructure.

The strongest architecture is often:

restaurant-owned stable URL
→ current menu

with a static QR.

Use a hosted editable QR when the encoded destination itself may change or when scan analytics/rapid repointing justify the extra layer.

Then size it for the real table, choose a finish that does not create glare, label the action clearly, and test the entire dining-room journey before printing every table.

Methodology and benchmark sources

Reviewed: September 4, 2026.

Current SERP benchmark included:

QRCode.io — dynamic menu, PDF warning, table size/glare and scan analytics;
DirQR — editable restaurant menu routing;
current restaurant/menu QR generators and print guides.

OwnQR's information-gain requirement is the stable-URL/static strategy plus operational restaurant-specific testing and routing discipline.

Create a QR code See OwnQR pricing

Restaurant Menu QR Code Generator