The difference, in one paragraph
A QR code is a picture of some data. In a static code, that data is the destination itself -- the full URL of your menu, encoded directly into the black and white pattern. In a dynamic code, the data is a short redirect address owned by the platform, which forwards to wherever your menu currently lives.
Everything else follows from that. A static code cannot be re-pointed, because re-pointing it would require changing the pattern, and the pattern is already printed on two hundred table tents. A dynamic code can be re-pointed as often as you like, because the pattern never encoded the destination in the first place.
What actually changes on a restaurant menu
It is easy to assume the menu is stable. Then you list what moved in the last twelve months.
- A supplier raised a price and three dishes went up with it.
- The summer menu replaced the winter one, then replaced it back.
- Two dishes were dropped because they never sold.
- A dish was renamed after the chef changed the recipe.
- The venue added a second menu for brunch.
- The website moved and the old menu URL stopped resolving.
Only the last of those requires a new code with a static setup, but it is the one that silently breaks everything. A static code pointing at a URL you no longer control is a dead square on every table, and you will find out from a guest.
The reprint maths
This is the argument, and it is worth doing with your own numbers rather than taking anyone's word for it.
- Count the surfaces carrying a code: tables, bar, window, takeaway counter, print sheets.
- Price one full replacement: design time, printing, laminating or mounting.
- Add the labour: someone walks the floor and swaps every one, during a shift you are paying for.
- Multiply by how many times a year the destination would need to change.
For a forty-cover restaurant with laminated table tents, a full replacement is rarely a trivial number, and the labour line is usually the one people forget. Whatever the total, that is the annual cost of choosing static -- not a one-off.
The counter-argument is that static codes are free to generate. That is true and it is the wrong comparison: the subscription buys the ability not to reprint, so the honest comparison is subscription against reprint cost, not subscription against zero.
The part nobody mentions: dynamic codes scan better
A QR code's pattern gets denser as the encoded data gets longer. More data means more modules -- the small squares that make up the pattern -- packed into the same physical area.
A static code carrying a long menu URL, complete with a path and any tracking parameters, produces a dense pattern. A dynamic code carrying a short redirect produces a sparse one. At A4 poster size the difference does not matter. At the 4 to 5cm of a table tent, in a dining room lit for atmosphere rather than for cameras, it does: a sparser pattern focuses faster, tolerates more smudging, and works from further away.
This is the argument that survives even if you genuinely never change your menu. The print guide covers the sizing side of the same problem.
What you give up with static
| Capability | Static | Dynamic |
|---|---|---|
| Change the menu without reprinting | No | Yes |
| Scan counts and timing | No | Yes |
| Seasonal or time-based destinations | No | Yes |
| Fix a broken link after printing | No | Yes |
| Works if you stop paying a platform | Yes | Depends on the platform |
The last row is the honest cost of dynamic, and it deserves attention before you print. A dynamic code depends on someone continuing to run the redirect. If that provider disappears, or you leave and they do not let you keep the code, the printed square stops working.
Who owns the redirect
This is the question that decides how much the convenience of a dynamic code actually costs you, and almost nobody asks it before printing.
A dynamic code encodes a domain. Whose domain it encodes determines who controls your printed codes for as long as they exist.
| The code encodes | If you change provider | If the provider disappears |
|---|---|---|
| The provider's short domain | Reprint everything | Reprint everything |
| Your own domain | Repoint your own redirect | Repoint your own redirect |
| A subdomain the provider hosts for you | Depends entirely on the contract — ask | Depends on whether you can take the DNS |
The middle row is the position worth being in, and it is available more often than people realise. If the code points at a URL on a domain you own, the pattern is fixed but the destination behind your own address is permanently yours. You get the benefit of a dynamic code without handing anyone a hostage.
Where that is not offered, the mitigation is to know the answer in advance rather than to discover it during a migration. A provider who cannot say plainly what happens to your printed codes on cancellation is asking you to bet a print run on their retention rate.
One practical note on scan reliability: a redirect adds a hop, and on a poor connection a hop is a fraction of a second. It is not perceptible next to loading the menu itself, and it is not a reason to choose static. Redirect latency is a real number and a rounding error compared with a PDF.
When static is genuinely the right choice
There are cases, and they are narrower than the free-generator marketing suggests.
- A one-off event with a destination that will not exist afterwards anyway -- a wedding, a pop-up, a single market stall.
- A code encoding something that is not a URL at all: wifi credentials, a phone number, a plain text note. There is nothing to re-point.
- A code printed on something disposable, where the print run is consumed faster than the menu changes -- a paper placemat, a takeaway bag.
Notice what these have in common: the printed object is cheaper than the menu behind it, or shorter-lived. A table tent is neither.
If you already printed a static code
This is recoverable, and the recovery is worth doing before the next menu change rather than during it.
- Find out exactly what the printed code encodes. Scan one with a reader that shows the raw URL rather than opening it.
- If it points at a domain you control, put a redirect at that URL to your new menu. The old printed codes keep working permanently.
- If it points at a domain you do not control -- a free generator's short link, or a previous agency's site -- you cannot redirect it. Plan the reprint.
- Generate the replacement as a dynamic code, so this is the last time.
- Replace in one pass rather than gradually, or you will run two menus at once and hear about it.
The second step is the one people miss. A static code pointing at your own domain is only half-static in practice: the pattern is fixed, but the destination behind your own URL is still yours to change. It is the codes pointing at somebody else's short domain that are genuinely stuck.
For the wider set of decisions this sits inside, see the complete guide to QR code menus.