QR codes aren't dead — here's what they're good for.

For most of the 2010s, QR codes were a running joke. A punchline in startup decks. The thing a marketing team slapped on a billboard without asking anyone if billboards are places you scan things. There's a famous genre of photo: a QR code on a subway ad, placed somewhere the train moves past at 40 miles an hour, and you're supposed to pull out your phone, launch a third-party scanner app, hold it still, and point it at a moving object. The codes were pointing to websites that then didn't load because the subway has no signal.

And then, quietly, around 2019–2020, QR codes became useful. No ceremony, no announcement. They just started working — and the use cases finally made sense for the thing they actually are, which is a way to put a URL (or a string) into a camera without typing it.

The long mockery

It's worth naming why QR codes were mocked, because it clarifies what changed. The mockery had three components:

The friction was absurd. You needed a dedicated scanner app. The app was usually bundled with ads. You had to know to launch it. Then you had to point your camera, wait for focus, hope the ambient light was decent. The whole interaction took 8–15 seconds when a typed URL took 5.

The use cases were bad. Billboards. Subway ads. Printed magazines. In every one of those cases, either the context didn't support the interaction (you can't scan a moving billboard) or the destination didn't benefit from it (a magazine ad could just list a URL — you're already sitting still holding text).

The destination was usually disappointing. The scan would take you to the company's homepage, not to the campaign-specific landing page you actually needed. Scanning it contributed nothing the URL couldn't have.

QR codes weren't wrong. They were deployed in contexts that didn't need them, for jobs other tools did better.

Why it quietly changed

Two things happened. Both iOS (11, 2017) and Android (8, via Google Lens and eventually built into the camera) added native QR code detection. You could point your phone's camera app at a code and get a tappable notification. No scanner app. No extra step.

The friction dropped from 15 seconds to under 3. Suddenly the interaction was fast enough to be worth it — but only for situations where typing the URL would be worse. The use cases that survived the redesign all share that property: the URL is long, ugly, context-specific, or otherwise unreasonable to type.

WiFi sharing

The killer app, and the one that most convinced me. Modern phones can read a WiFi QR code (a specific string format starting with WIFI:) and offer to join the network automatically. You don't type the password. You don't fumble with the weird special character the café owner insisted on.

For a coffee shop, a conference venue, or a rental property, a printed QR code by the door solves a problem nothing else solves. There's no app involved. The credentials never leave the phone. It works offline — the QR literally contains the password, so the connection happens before any network is needed.

This is the case where QR codes are clearly the best tool. Typing a 20-character WPA password is genuinely miserable, and voice-dictating it is worse. Nothing else does this job.

Menus and ordering

Restaurants went all-in on QR menus during the pandemic, and many stuck with them. Opinion is divided — some find it convenient, some hate holding a phone during dinner. But the underlying reason it works, when it works, is that updating a printed menu is expensive and slow. A QR code pointing at a web page means the menu can change hourly. The daily specials are real. Dietary filters are clickable. You can see food photos without the menu being awkward to hold.

It fails when the web page is badly designed (too many popups, slow to load, requires an account), or when the restaurant is the kind where reading a menu on a phone is at odds with the ambience. Paper menus aren't extinct, and probably shouldn't be. But for casual places, QR menus are solving a real logistical problem, not a made-up one.

Payments

In China, almost all consumer payments run through WeChat Pay or Alipay, which use QR codes as the exchange mechanism. Either you scan the merchant's code, or they scan yours. It works because it's decoupled from having a chip reader or an NFC terminal — any phone with a camera is a payment device, any piece of printed paper is a merchant terminal.

The Western adoption has been slower (we have Apple Pay, Google Pay, contactless cards) but QR-based payment keeps creeping in at the edges — Venmo, Cash App, PayPal all support scan-to-pay, and it turns out to be genuinely useful when you're standing next to someone and want to send them $20 for the brunch bill.

Event tickets and check-ins

Printed or on-phone QR tickets are the default for concerts, conferences, flights, and most other events. The alternatives (typed codes, physical wristbands, staff matching names against a list) are all slower or less reliable. A scanner at the door reads a QR in under a second.

The legitimate use case here is uniqueness at a venue. Every ticket has a different code, each code is checked once, and that's it. It's not about linking to a web page — the code itself is the credential. This is QR doing what it does best: being a machine-readable string that's also printable.

Connecting print to web

Business cards. Product packaging. Museum placards. Restaurant table tents with a "review us" link. In each case, you have a printed artifact that wants to link to a digital one, and the URL would be too long or too ugly to be worth typing.

Two notes on doing this well:

• Put the URL next to the QR code as fallback text. Shorter is better, even if it means using a URL shortener. Not everyone will scan.
• Use a context-specific landing page, not your homepage. The whole point is that the code can be specific. If the scan lands on the same page as your main navigation, you've wasted it.

When not to use one

QR codes are the wrong tool when:

The destination is trivial enough to type. "yourcompany.com" on a billboard beats a QR code every time. Typing 14 characters beats a 3-second scan.

The scanner can't reasonably hold still. Moving vehicles, digital screens that rotate every 10 seconds, codes placed above a person's reach. If the scan can't happen, the code is a waste of ink.

The user won't have internet. If the scan leads to a web page and the venue has no signal, you've built a useless loop. Offline-first fallbacks (the WiFi format being the obvious example) avoid this, but most QR codes today still just contain URLs.

As a tracking mechanism without disclosure. Many campaigns use QR codes with tracking parameters to measure print-to-digital conversion. That's fine if you're transparent about it. It's not fine if you're using the indirection to avoid users noticing that their click got attributed.

Making your own

Making a QR code is technically simple — the encoding algorithm is well-documented and every major language has libraries. The design choices that matter:

• Error correction level. Most generators default to M (about 15% recovery). For printed QRs that might get creased, stained, or have a logo overlaid, use H (30%). This trades off against code density — higher error correction means a denser grid.
• Margin (quiet zone). QR scanners need empty space around the code to find it. The spec says 4 modules minimum. Don't crop it tight.
• Contrast. Dark on light is what scanners expect. Inverted codes mostly work on modern scanners but still fail on some older ones. If reliability matters, stay classic.
• Size. A QR code needs to be at least 2 cm square for typical phone-camera distance (~30 cm). For billboards or other far-distance scans, scale up proportionally.

If you want one now, you can make it here — WiFi, contacts, URLs, plain text, and a few other data types, all client-side. Your password never leaves your browser.