Make a Wi-Fi, contact or link QR code, and check it before you print it

Static, which is a decision rather than a limitation

There are two kinds of QR code and the distinction is not cosmetic. A static code contains the thing itself: the URL, the Wi-Fi record, the contact card. A dynamic code contains a short link belonging to a provider, which redirects to wherever the provider currently says.

Dynamic codes buy you two features — the destination can be changed after printing, and every scan can be counted — and they cost you something that is rarely spelled out on the page selling them. Every scan now passes through a third party, who sees it, and who decides whether the code keeps working. When that provider changes its pricing, sunsets a product or goes out of business, the sticker on the window stops working and there is nothing to be done about it. This has happened repeatedly and at scale.

A code generated here is finished the moment you download it. There is no redirect, no counter, no account and no relationship: appvau.lt is not involved in a single scan. What can still break is whatever the code points at — a link can 404, a password can be changed, a phone number can be reassigned — and no generator on either side of the distinction can help with that.

Why the payload is shown before anything is encoded

A QR symbol is opaque to the person who made it. You cannot look at the pattern and see that the URL is missing its scheme, that the SSID has a trailing space copied in from a label, or that the phone number lacks a country code. The failure is always discovered later, by somebody holding a phone in front of something already printed.

So this tool shows the exact canonical string first — the one that goes into the symbol, in the format a scanner parses. A Wi-Fi record for a guest network looks like this:

WIFI:T:WPA;S:Studio Guest;P:weeknight-parcel-7;;

That format is not a convention this site invented; it is the record iOS has read since version 11 and Android since 10. Seeing it is the one moment a human can catch an error, which is why it is a step rather than a detail hidden behind an advanced toggle.

The same step is where the warnings appear. A Wi-Fi record triggers one every time, because the password is inside the symbol in clear text and a photograph of the code taken from across a room recovers it. A phone number without a country code triggers one. An address without a scheme triggers one and is corrected in front of you rather than silently.

The verification, and what it does and does not prove

After encoding, the tool renders the PNG, rasterises the SVG, and reads both back with a decoder that knows nothing about the encoder that produced them. It locates the symbol the way a camera would — thresholding to black and white, finding the ink, measuring the module pitch from the finder pattern — reads the format information, undoes the mask, de-interleaves the data blocks, and then recomputes the Reed–Solomon error-correction codewords from the data it recovered and requires them to be byte-identical to the ones in the symbol.

That last step is stronger than "it decoded". It says the redundancy is correct as well as the data, so a reader working from a scuffed or partly-obscured copy still has the margin the chosen level promises. Only if both files pass does either download unlock.

It proves the files are correct. It does not prove that your camera, at your print size, on your surface, under your lighting, will read them. Nothing on this side can establish that, and the honest instruction is the old one: print it at the real size and scan it with the phone it is meant for, before ordering five hundred.

The check earns its place for a reason worth stating. Building this tool surfaced an error in the error-correction block table for level H, which would have produced symbols that were structurally valid and completely undecodable at the highest redundancy setting. Nothing about the image would have looked wrong. The decoder found it in the first test run.

Error correction is not a licence to cover the middle

Every QR symbol carries redundant codewords so that a damaged reader can still recover the data. The four levels recover roughly ~7% at L, ~15% at M, ~25% at Q, ~30% at H.

Those percentages are why designers put logos in the middle of codes, and it is a bad habit dressed up as a feature. Redundancy is there to survive damage that happens after printing — scuffing, a fold, a coffee ring, poor light. Spending it in advance on decoration means the code starts its life with no margin, and it is the ones that get handled that need margin most.

A higher level also makes the symbol denser for the same content, because the redundancy has to go somewhere. A version-1 symbol holds 17 bytes at level L and 7 at level H — the same 21-by-21 grid, less than half the payload. Denser means a larger physical print to stay readable, so "use H for safety" frequently produces a code that scans worse.

Level M is the right default. Go to Q or H when the code will be printed small, on a curved surface, or somewhere it will be touched.

The whole table is published as JSON at qr.json, for every version from 1 to 40, alongside the numeric and alphanumeric capacities and the payload formats with worked examples. It is generated rather than typed for a reason worth repeating: writing the block structure down a second time is precisely how a wrong number survives.

PNG or SVG, and why the pixel pitch matters

Both are produced, both are free, and neither carries a watermark. Take the SVG for anything going to print or into a design file: it is a vector with an integer view box and a single path, so it scales from a business card to a poster with no blurring and opens cleanly in Illustrator, Figma, Inkscape and page-layout software. Take the PNG for a document, a slide, a message or a web page, where a fixed raster is simpler to place.

The PNG's size is rounded down so that every module is a whole number of pixels. This sounds pedantic and is not: a 29-module symbol rendered into exactly 500 pixels gives 17.24 pixels per module, and that quarter-pixel remainder lands as a grey edge along every module boundary. Cameras cope with it most of the time, which is worse than never coping, because it fails on the one print that mattered.

The four-module quiet zone around the symbol is part of the symbol, not a margin. It is a requirement of ISO/IEC 18004 and the single commonest reason a hand-cropped code will not scan. Do not trim it, do not place the code flush against a coloured block, and do not let a layout tool crop it to the ink bounds.

Encoding, character sets and the ECI question

The encoder picks the tightest mode the content allows: numeric for digits, alphanumeric for the restricted uppercase set, and byte mode for everything else. A capacity table for the symbol it chose, at every level, is shown before you generate.

When the payload contains non-ASCII characters — an accented network name, a name in Cyrillic or Japanese — the encoder writes an ECI header declaring UTF-8. That is the correct declaration and it is also the thing old scanners are most likely to mishandle, so it is added only when the bytes actually require it, and the receipt says when it was. A pure-ASCII payload carries no ECI header and behaves identically in every reader ever built.

Nothing on this page reaches the network. The encoder, the renderer and the decoder that checks the result are all JavaScript running in this tab, and the modules under /js/tools/ contain no request-making code at all. Disconnect after the page has loaded and every part of it still works — which, for a tool you are about to hand your Wi-Fi password to, is the property worth checking rather than believing.