How to Make a QR Code That Actually Scans: URLs, WiFi, Contacts & Text

A QR code is just a way to hand a phone some text without anyone typing it. That text can be a link, a WiFi login, a contact card, or a plain note. The hard part isn't generating the grid — any tool does that in a millisecond. The hard part is making a code that still scans after it's been printed at 2 cm square, scuffed in a shipping box, or covered with a logo. This guide walks through the four things you encode most often, the error-correction tradeoff that nobody explains clearly, and the print details that decide whether your code works at arm's length or only when the phone is touching the paper.

You can follow along with the QR Code Generator — it runs entirely in your browser, so your WiFi password and contact details never leave your machine.

The four payloads you'll actually encode

Most real QR codes fall into one of four buckets, and each has a specific text format the phone expects.

A URL is the simplest: you encode https://example.com/page and the phone offers to open it. Keep it short. A 300-character tracking URL works, but it forces a denser grid that's harder to scan from a distance.

A WiFi credential isn't free text — it's a structured string the camera app knows how to parse. The format is WIFI:T:WPA;S:NetworkName;P:password;;, where T is the security type, S is the SSID, and P is the password. Special characters like ;, ,, :, " and \ have to be escaped, which is exactly the kind of detail a good generator handles for you so you can paste the raw password.

A contact uses the vCard format — a small block of BEGIN:VCARD … END:VCARD text with name, phone, email, organization, and website. One scan drops the whole card into the other person's phone with no typing.

Plain text is the catch-all: a note, a serial number, a short message. The phone just shows it.

A worked example: a URL versus a WiFi string

Say I'm encoding https://toolora.info/qr. That's 23 characters, all alphanumeric. The QR spec packs that into a tiny version-2 grid (25×25 modules), and it scans cleanly from across a room. Now I encode a cafe WiFi login: WIFI:T:WPA;S:Corner Cafe Guest;P:flatwhite2026;;. That's 47 characters, and the structured prefix and escaping push it to a version-3 grid (29×29 modules). Same physical size on paper, but each module is now smaller because there are more of them.

When I first started printing WiFi codes for a friend's cafe, I made the rookie mistake of cramming the full network name, a long auto-generated password, and a "T&C" URL into one code. It came out at version 7 — a dense little maze — and printed at A6 it scanned only when guests held the phone about 10 cm from the laminate. We swapped the random password for a memorable one and dropped the URL, the grid fell back to version 3, and suddenly it scanned from across the table. The lesson stuck: fewer bytes, bigger modules, longer scan distance.

Error correction: L, M, Q, H and what they buy you

Every QR code carries redundant data so it can rebuild itself when part of it is damaged or covered. You pick how much redundancy at generation time, and the four levels recover roughly:

L (Low) — up to about 7% of the code can be damaged
M (Medium) — up to about 15%
Q (Quartile) — up to about 25%
H (High) — up to about 30%

The catch is that this redundancy is extra data, so a higher level means a denser grid for the same content. Encode the same URL at L and at H, and the H version needs more modules — a bigger or finer code.

So the right pick depends on the surface, not your nerves:

L — clean screens and web pages where nothing will ever damage the code, and you want the smallest, densest footprint.
M — the safe default for most printing. Survives smudges and a small logo.
Q — when you're stamping a modest logo in the center, or the code lives on packaging that gets handled.
H — outdoor signs, peel-prone stickers, or codes with a large center logo, where up to a third of the surface might be obscured.

Don't reflexively crank it to H. Higher correction on a long payload produces a code so dense that the module size shrinks below what budget phone cameras resolve — you trade damage-tolerance for unreadability. Match the level to the actual risk.

Why bigger payloads need denser codes

The QR standard defines 40 "versions," from a 21×21 grid up to 177×177. As you add characters, the encoder steps up to the next version that fits, and each step adds rows and columns of modules. At a fixed print size, more modules means each black square is physically smaller. Phone cameras need a minimum module size to lock on — roughly a handful of camera pixels per module — so past a certain density the code simply won't read at normal distance.

This is why a 7,000-character QR is a bad idea even though the spec allows it. The practical ceiling for reliable phone scanning is far lower than the theoretical maximum: keep URLs under about 300 characters and vCards under about 500. If you genuinely need to encode a lot — a long contact card, a paragraph, a signed token — encode a short link instead and let the destination hold the bulk. A URL encoder is handy here for safely building the query string your short link points at before you shrink it.

Print size, quiet zone, and the test that saves a reprint

Two physical details decide real-world scannability.

Size. A QR needs enough physical module size for the camera. For a phone scanned at arm's length, keep the printed code at 2 cm square or larger; for packaging scanned up close, 1.5 cm can work on a flat surface. Avoid folds and seams — a crease through the grid destroys modules. And because most print shops downsample art below 300 DPI, generate at roughly twice your final size and let the printer scale down rather than up.

Quiet zone. A QR needs a margin of empty space around it — the "quiet zone," at least four modules wide — so the scanner can tell where the code ends. Designers love to crowd a code right up against a graphic or color block; that border noise is a common reason a code that looks fine on screen won't scan on paper. Leave the white frame alone.

Then do the one test that matters: render at the actual final size, print one on an office printer, and try to scan it from 30 cm away. If it works there, it'll work in production. If it only scans when the phone is nearly touching it, your code is too small, too dense, or starved of its quiet zone — fix it before the print run, not after 5,000 copies.

Everything stays on your machine

A generator that builds the code locally writes your text straight into the PNG or SVG in the browser — nothing is uploaded, logged, or sent to a server. That matters for WiFi passwords and contact details. Keep in mind, though, that the image is the secret in visual form: a screenshot of a WiFi QR shared in a group chat is the same as posting the password in plain text. For anything private, treat the picture with the same care as the words it encodes. Export PNG for fixed-size printing and platforms that reject vectors, or SVG for signage that has to scale to any size without blur.

Pick the payload, match the error-correction level to the surface, keep the content lean, leave the quiet zone, and run the 30 cm test. That's the whole game.

Made by Toolora · Updated 2026-06-13