The rule that sets everything
A QR code scans reliably from about ten times its own width. That is the whole sizing calculation: measure the distance a guest will scan from, divide by ten, and you have the minimum width of the printed square.
It is a minimum rather than a target. Going larger costs nothing but space and buys tolerance for a cheap camera, a shaking hand, and a dim room. Going smaller fails intermittently, which is worse than failing outright because nobody reports it.
Two things change the answer. A denser pattern -- more encoded data -- needs to be bigger to stay readable, which is one of several reasons to use a dynamic code with a short URL. And low light effectively increases the distance, because the camera needs more of the sensor filled before it can resolve the pattern.
Size by placement
| Placement | Scan distance | Minimum code width | Notes |
|---|---|---|---|
| Table tent or table sticker | 30–50cm, seated | 4–5cm / 1.5–2in | The most common case. Do not go below 4cm. |
| Menu card or placemat | 30–40cm | 3–4cm / 1.2–1.6in | Held closer, so slightly smaller is safe. |
| Counter or till card | 50–70cm | 6–7cm / 2.5in | Guests scan standing, often at an angle. |
| Bar back or wall mount | 1–1.5m | 10–15cm / 4–6in | Angle matters more than size here. |
| Window decal, read from outside | 1.5–2m | 15–20cm / 6–8in | Also fights daylight glare and reflection. |
| A-board or poster | 2–3m | 20–30cm / 8–12in | People will not step closer to scan. |
The window row is the one that catches people out. A code sized for a table tent, stuck on the inside of a window, is unscannable from the pavement -- and the pavement is the only place anyone would want to scan it from.
Contrast, colour, and the branded code problem
A camera resolves a QR code by finding contrast between the dark modules and the light background. Anything that reduces that contrast reduces the distance and the angle the code tolerates.
What works
- Dark on light. Near-black on near-white is the safest, and a dark brand colour on a light background is usually fine.
- A logo in the middle. Error correction reconstructs the covered modules, so a centred logo up to roughly 20–30% of the area is normally safe.
- A branded frame around the code, outside the quiet zone.
What fails
- Inverted codes -- light modules on a dark background. Some phones handle it, many do not, and you will not know which your guests have.
- Gradients across the pattern. The contrast is fine at one end of the square and marginal at the other.
- Low-contrast brand palettes: mid-grey on cream photographs beautifully and fails at dinner service.
- Cropping the quiet zone. The clear margin around the code is functional space, not padding, and designers remove it because it looks tidier.
Material and finish
A table tent lives a hard life: spills, wiping, being knocked over, being propped against a candle. The finish matters as much as the print.
- Matte laminate over gloss. Gloss under a ceiling spot produces a reflection exactly where the camera needs to see the pattern, and the guest has to tilt the card to defeat it.
- Rigid over flexible for table tents. A curled card bends the pattern out of plane and the code stops resolving at an angle.
- Waterproof or laminated for anything on a table. Unlaminated card lasts about a fortnight in a working dining room.
- For stickers, check the adhesive against the surface. A sticker peeling at one corner lifts the pattern out of plane.
Set error correction to level M or H when generating. Higher error correction means more of the pattern can be scuffed, smudged, or covered and still resolve -- which is exactly what happens to a card that lives on a table.
The words underneath
A bare square on a restaurant table is ambiguous. It could be the menu, the wifi password, a loyalty scheme, a review request, or a payment link. Guests who have been asked to scan all five are cautious about scanning any of them.
"Scan for our menu" resolves that in four words. Some further detail worth including where there is room:
- Say it opens in the browser. "No app needed" removes the most common hesitation.
- If you have paper menus, say so on the card. It costs nothing and it defuses the objection before a guest has to ask.
- If the menu is available in other languages, a small line saying so is more effective than a flag icon inside the menu that nobody scrolls to find.
Keep the text outside the quiet zone. Typography crowding the code is the single most common print error after cropping the margin.
Files, formats, and DPI
- Export SVG or PDF for anything printed. Vector rescales without softening the module edges, and soft edges are what a camera struggles with.
- If your printer insists on raster, supply PNG at 1000×1000px or larger, at 300dpi minimum for the finished size.
- Never supply JPEG. Its compression puts artefacts exactly on the high-contrast boundaries the scanner reads.
- Never scale up a screenshot of a code. It is the same failure in a different disguise.
Send the printer the vector file and the finished dimensions separately, rather than a pre-sized raster. It removes the step where someone resamples the image to fit the layout.
Test before the print run
One proof, printed at final size on the final material, tested in the real room. This is the cheapest step in the process and the one most often skipped.
- Print one card at final size, on the final stock, with the final finish.
- Put it on a real table, in the position it will actually sit, under evening lighting.
- Scan seated, not leaning over it. The seated distance is the specification.
- Repeat on an iPhone and an Android phone -- camera behaviour differs more than people expect.
- Repeat on the oldest phone anyone on the team owns, and on a cracked screen if you can find one.
- Scan at an angle, from roughly 45 degrees, as a guest across the table would.
- Check the page loads fast enough on the venue's own wifi, which is often worse than mobile data indoors.
If any of those fail, the fix is almost always to make the code bigger or the contrast stronger. Both are free before the print run and expensive after it.
When you will need to reprint
With a dynamic code, almost never for menu reasons. The pattern stays valid while the menu behind it changes, which is the entire point.
You will still reprint for physical reasons: cards get destroyed, the brand changes, or the venue rearranges and the codes end up in the wrong place. Budget for a proportion of table tents being replaced each year regardless -- it is a consumable, not an asset.
The one avoidable reprint is the one caused by the code type. That decision is covered in static vs dynamic QR codes for restaurant menus, and the full sequence from menu to table is in how to create a QR code menu.