A QR code menu that keeps working

There are two kinds of QR code and the difference is invisible on the printed page, which is exactly why this catches people.

• Static. The destination is encoded in the pattern itself. Nothing sits in the middle. It works forever, offline, with no account and no company behind it. The trade is that changing the destination means a new code.
• Dynamic. The pattern encodes a short URL on the provider's domain, which then redirects. You can change the destination, and you get scan statistics. The trade is that the code only works for as long as that provider keeps resolving it.

For a poster you replace monthly, dynamic is a reasonable trade. For something printed onto table talkers, laminated, and expected to last two years, it is a dependency on a third party's business model.

You want the permanence of static and the editability of dynamic, and there is an obvious way to get both that most articles never mention.

1. Pick a URL you control and will not change. A page on your own domain, or a bio page with a fixed address.
2. Generate a static code for it. The destination is now baked into the pattern and depends on nobody.
3. Change the page, never the URL. New menu, seasonal specials, different opening hours: all of it is editing a page, and every printed code follows automatically because it was always pointing here.

You give up the provider's scan statistics, which are worth less than they sound: a count of scans with no idea what anybody did next. A page you control tells you what people actually tapped, which is the more useful number.

Our QR code generator makes static codes, in your browser, with no account. The URL is never sent anywhere because the encoding happens on your device.

A phone, held by somebody who is hungry and slightly annoyed at having to scan something. That is the design brief.

• Not a PDF. A PDF on a phone is pinching and scrolling. A share of people give up and flag down a member of staff, which is the exact outcome the code was meant to prevent.
• The menu first, and nothing above it. No welcome message, no social links, no photo of the building. They are sitting in the building.
• Sections that collapse, or short sections. Scrolling past forty wines to find the puddings is the most common complaint about digital menus.
• Dietary information in text, not icons. Icons need a key, the key is at the bottom, and somebody with a real allergy should not be decoding a legend.
• Then the other things, below the menu. Booking link, opening hours, the wifi password, and the social accounts. All useful, none of it above the food.

Most QR failures are printing failures rather than encoding failures.

1. Leave the quiet zone. The blank margin around the pattern is part of the specification, not whitespace to trim. A code printed hard against a border or a coloured background fails on cheap phone cameras.
2. Dark on light, not the reverse. Inverted codes fail on a meaningful share of scanners. It looks better and it works worse.
3. Big enough for the distance. At least a tenth of the scanning distance. On a table, three centimetres square is the floor and four is comfortable.
4. Vector, not a screenshot. Print from an SVG. A PNG scaled up for a poster produces soft edges, and soft edges are what makes a code fail in low light.
5. Say what it is. "Scan for our menu" under the code. People do not scan unlabelled squares, and a labelled code gets scanned considerably more often.
6. Test it in the room. On a cheap phone, at the actual table, under the actual lighting. Restaurant lighting is dim on purpose and it is the condition nobody tests in.

For the rest of what belongs on the page, the page for local businesses covers opening hours and events, and the QR generator makes the code.