An office manager tapes a WiFi card to the reception desk. It works on the desk tablet. It works on her own phone. Then a contractor walks in with a four-year-old Android, holds it up, and nothing happens. Same card, same router, same three feet of air. The reflex is to blame the printout and make it bigger.
Size was not the problem. WiFi codes fail in ways that a plain link code never does, because a WiFi code is attempting something a link code never attempts. This post sits one level under the broad WiFi guide: that one covers making and placing a card, this one covers the cases where the payload itself is what breaks.
A WiFi code is not a link
Scan a poster code and the phone reads a web address and opens a browser. Nothing in that chain is specific to WiFi, or to QR at all. The symbol is a container, the address is the content, and every phone in circulation agrees on what an address means. The mechanics of that container are worth reading separately.
A WiFi code carries no address. It carries a short structured string of labeled fields separated by semicolons, close to WIFI:T:WPA;S:FrontDesk;P:latte1234;; where T is the security type, S is the network name, and P is the password. The camera app decodes the string, recognizes the prefix, and hands the pieces to the operating system, which offers to join. No server is contacted and nothing is fetched, which is also why these keep working when the connection is down, the same property that makes static codes usable offline.
Everything that follows is a case where one of those fields is wrong, missing, or unrepresentable.
The flag that says "this network is invisible"
A hidden network is one the router does not broadcast. Devices scanning the area see nothing, so a phone handed only a name and a password may look, find no such network, and give up before it ever tries the password.
The payload has a field for exactly this: a hidden flag that tells the device to probe for the name directly instead of waiting to see it in a scan. Set it and the join usually proceeds. Leave it off and behavior varies by device and version. Some will still find the network, some will fail with an error that reads like a wrong password, and some will sit on "connecting" until it times out.
Worth saying plainly: hiding a network buys very little security. The name still travels in the clear when devices connect, so treat a hidden SSID as an inconvenience to work around, not a protection to preserve.
The security type has to match what the router runs
The T field describes how the network is protected. Generators typically offer a personal-password option covering the common WPA family, an option for older WEP networks, and an option for open networks with no password at all.
Devices differ in how strictly they read this. Some effectively ignore it and negotiate with the router directly; others take it at face value and fail when it disagrees with reality. A card generated when the router ran WPA2, still on the wall after someone moved the network to WPA3 only, is a card that will work on some phones and not others, with no pattern a guest can see. That inconsistency is the signature of a mismatch rather than a print quality issue, which is a useful thing to know before working through the usual scanning fixes.
The practice that avoids all of this: generate the code from what the router is running today, and regenerate it any time the security settings change.
WPA3, older devices, and transition mode
WPA3 is the newer protection scheme, and support for it depends on the hardware and software on both ends. Older phones, laptops, and especially non-phone devices like printers, streaming boxes, and handheld scanners may not be able to join a WPA3 network at all. No QR code fixes that, because the code is not what is being refused.
This is why routers offer a transition or mixed mode, where WPA2 and WPA3 clients can both connect to the same network name. For a card that strangers will scan, mixed mode is usually the practical setting: you have no idea what walks through the door.
If the network is WPA3 only by policy, expect a share of guest devices to fail and plan a second path for them rather than reprinting the card three times.
Punctuation that quietly corrupts the payload
Semicolons, commas, colons, backslashes, and quotes are structural inside the WiFi string. They separate fields. A password containing one of them has to be escaped with a backslash, or the decoder reads the password as ending early.
The failure is nasty because it is silent. Nothing looks broken. The phone receives a truncated password, sends it, and the router rejects it. The guest sees "incorrect password," the host swears the password is correct, and both are right. A password like Summer;2026 becomes Summer on the wire.
Decent generators escape automatically. Hand-assembled strings and spreadsheet-driven batch jobs are where unescaped punctuation shows up. There is a related quirk with passwords made entirely of hex characters, which some implementations read as raw key material rather than text; generators handle it with quoting, and it is another reason not to build the string by hand.
If the password contains anything other than letters and digits, scan and connect once before printing anything.
Network names that are not plain Latin text
An SSID with Cyrillic, Arabic, Chinese characters, or an emoji can be encoded fine. The symbol carries bytes; the question is what the reading device assumes those bytes mean. Most modern phones assume UTF-8 and get it right. Older or unusual readers may not, and the result is a name full of replacement characters that no longer matches the network being advertised.
This is the general character-set problem that encoding and ECI exists to address, and it is less reliably solved in WiFi payloads than in web addresses. Test on a couple of real devices. If a guest-facing network keeps producing mismatches, renaming it to plain ASCII costs nothing and ends the category.
What a WiFi code cannot express
Corporate networks running 802.1X do not use a shared password. Each person authenticates with their own credentials, often against a certificate, using one of several authentication methods that both sides must agree on. None of that fits in the standard WiFi payload, which has room for a name, a type, a password, and a hidden flag.
That is not something a better generator fixes. Enterprise networks get provisioned through device management profiles instead. If your office runs 802.1X for staff, the QR card belongs on the guest network, which is where you wanted visitors anyway.
Before anything goes to a printer, build the code with a WiFi generator, then test the join on a phone that has never seen the network. Forget the network first if it has, or you will watch a device reconnect from memory and call it a success.
