Skip to content

Guides

How to make QR codes for restaurant tables

A menu code is one URL printed forty times. A table code is forty different URLs printed once each, because the table number rides inside the link so the kitchen knows where the order goes. That turns the job from 'make a QR code' into 'make a batch from a list', and the list is where the mistakes hide.

The five-minute version

  1. Get the per-table URL pattern from your ordering or payment platform. It usually looks like order.platform.com/yourcafe?table=12.
  2. Make a spreadsheet: one row per table, a label column (Table 12) and a url column built by formula from the number.
  3. Generate static codes from the CSV as a print sheet, each code captioned with its table number in large type.
  4. Laminate matte, put each tent on its table, and scan every one from the chair to confirm the number on screen matches the number on the tent.
  5. Keep the CSV. A lost or replaced tent is one row regenerated, identical to the original.

Menu code or table code? They are different jobs

The menu guide covers the simpler case: the code opens your menu, the URL is the same on every table, and one code serves the room. The moment guests can order or pay from the table, the platform needs to know which table, and the only place that information can live is in the URL itself. Table 12’s code is no longer interchangeable with table 7’s.

This changes the failure mode. A menu code that is wrong does not scan. A table code that is wrong scans perfectly, takes the order, and sends it to the wrong table, and nobody finds out until the food arrives. So the work is not about making the codes scannable; it is about making sure the number printed on the tent and the number encoded in the pattern are the same thing, on every table, after every reprint.

Whose URL goes in the code

The URL is almost always the ordering platform’s, not yours, because the platform runs the ordering and the table parameter has to reach its servers. Encode that URL directly as a static code: the platform is a dependency you have already chosen, your orders run through it whether or not there is a QR code involved, so the code adds no new point of failure.

The packaging guide says never to encode a domain you do not own, and this is the one place in the cluster that rule bends. It bends for a reason: the rule exists to stop you adding a landlord. An ordering platform is a landlord you have already signed with. A QR vendor’s dynamic redirect sitting in front of that URL would be a second landlord, with a second plan that can lapse, and that one you should still refuse.

If you have a website, there is a cheap upgrade. Give each table a short path on your own domain, yourcafe.com/t/12, and have it redirect to the platform URL for that table. The printed code now encodes an address you control, and the day you switch ordering platforms you change forty redirects and reprint nothing. It also makes the code smaller: a 22-character URL is a sparse code that scans easily at table-tent size, where a long platform URL with a venue slug and a token can push the pattern dense enough to matter at 3 cm. Worth doing if a site exists; not worth delaying launch for if one does not.

Why static, specifically here

Table tents are the textbook victim of the dynamic-code trap, and the restaurant version is worse than most because the codes are laminated, there are dozens of them, and they fail during service. The mechanics are in the expiry guide and the trade-offs in static vs dynamic; the short form is that a dynamic code is a vendor’s redirect, and when the free tier ends or the card expires, every table goes dark at once.

The usual argument for dynamic codes, scan analytics, is also weakest here. Your ordering platform already tells you which table ordered what and when. A QR vendor’s dashboard counting scans per table is a worse copy of data you already have.

The spreadsheet

Two columns are enough. The label is what gets printed under the code; the URL is what gets encoded. Build the URL from the number by formula so the two can never drift:

  • label: Table 1, Table 2 … plus the places that are not tables but still take orders: Bar 1, Patio 4, Counter.
  • url: ="https://order.platform.com/yourcafe?table="&A2 or, with your own redirects, ="https://yourcafe.com/t/"&A2.
  • Use the platform’s exact table identifier, not your friendly name. If the platform calls the patio tables P1 to P6, the URL has to say P4 even if the tent says Patio 4.
  • Add a handful of spare numbers now. Tables get added, split and pushed together; a spare tent in the drawer beats a one-off code made in a hurry on a Friday evening.

The bulk-from-spreadsheet guide covers the CSV mapping, the ZIP-versus-sheet choice and the pre-print checks in general. For tables, choose the print sheet: the codes are the printed thing, and a sheet with captions is what you cut and laminate.

Sizes that scan from a chair

  • Distance. A seated guest scans from 25 to 40 cm, so by the distance-over-ten rule the code wants to be 3 to 4 cm across. Never below 2 cm. The print-size guide has the full table.
  • Caption. The table number goes next to the code in type large enough to read standing up. It is the only way a server can check a tent against its table without scanning it, and it is the fallback for the guest whose camera will not cooperate: “Table 12 · scan to order, or tell us your table number.”
  • Both faces. On a two-sided tent, the code and the number go on both sides. A tent turned the wrong way round is the commonest reason a table “has no code”.
  • Matte, not gloss. Gloss lamination under evening downlights is glare, one of the six causes in the not-scanning guide. Ask the print shop for matte, and test the laminated copy, not the paper proof.
  • Plain code. Logos and brand colours cost error-correction headroom, and a laminated tent that gets wiped forty times a day will pick up scuffs. Spend the headroom on scuffs.

Before the first service

  • Sit at every table and scan its tent. Confirm the table number the platform shows on screen matches the number on the tent. This is the only check that catches a swapped row.
  • Do it in evening lighting, from a seated position, on a cheap phone, after lamination.
  • Check the URL opens in the browser without demanding an app install. If the platform’s link insists on an app, raise it with the platform, not the code.
  • Keep the CSV and the export together, dated. A replaced tent is one row regenerated, and because the code is static the new print is pixel-identical to the one it replaces.
  • Keep a paper menu and the phrase “or just tell us your table” in reach. The code is a shortcut, not the only door.