How to Make a WiFi QR Code That Actually Connects a Phone

A WiFi QR code is not magic and it is not a link. It is a short line of text, drawn as a square of black and white modules, that tells a phone the exact name of a network, how that network is secured, and the password to join it. When a camera decodes that text, the operating system recognizes the format and offers a one tap "Join Network" prompt. No typing, no reading a password off the router.

This works because the text follows a tiny, fixed grammar that both iOS and Android agreed to support years ago. Get the grammar right and the connection is instant. Get one field wrong, most often the security type, and the phone either fails silently or joins with the wrong settings.

This post covers the exact payload a WiFi QR code carries, what each field means, how phones parse it from the camera, and the one security fact that decides whether a QR code is the right way to share your network.

What a WiFi QR code actually contains

Open a WiFi QR code in a plain reader that shows raw text instead of acting on it, and you see something like this:

WIFI:S:CoffeeBarGuest;T:WPA;P:latte12345;H:false;;

That is the whole thing. It starts with the scheme WIFI:, then a set of fields separated by semicolons, and it ends with two semicolons. There is no server, no URL, no account. Each field is a letter, a colon, and a value:

• S is the SSID, the network name exactly as it is broadcast.
• T is the authentication type: WPA, WEP, or nopass for an open network.
• P is the password.
• H marks whether the network is hidden (true) or broadcast normally (false).

The trailing double semicolon is the terminator, and leaving it off is a common reason a code fails to parse on stricter readers.

The fields inside the payload

The SSID field looks simple, but it is where most codes break. The name has to match the broadcast name byte for byte, including capitalization and spaces. "Coffee Bar" and "coffee bar" are two different networks to a phone. If the name contains a character the format uses as structure, a semicolon, comma, colon, backslash, or double quote, that character has to be escaped with a backslash. A network named "Tom;Jerry" has to be written as Tom\;Jerry, or the reader treats the semicolon as the end of the field.

The password field follows the same escaping rule. A password like pa;ss,word needs both the semicolon and the comma escaped, which is the single biggest argument for generating the code with a tool instead of typing the string yourself.

The hidden flag matters more than people expect. A hidden network does not broadcast its name, so the phone cannot confirm the SSID exists by listening. Setting H:true tells the operating system to actively probe for that exact name. Leave H:false on a genuinely hidden network and some phones show the prompt, then quietly fail because they never find the network they were told is being broadcast.

Why the encryption type has to be exact

The T field decides whether the join succeeds, and it is the one people get wrong. It has three valid values, and each changes how the phone attempts the handshake.

WPA covers WPA, WPA2, and WPA3, which is nearly every secured home and business network built in the last fifteen years. The phone treats the P field as a passphrase and runs the standard four way handshake. T:WPA is correct even if the router is actually running WPA2 or WPA3, because the phone negotiates the exact version with the access point.

WEP is the old, broken standard from the early 2000s. If a network is genuinely WEP, the T field has to say WEP, because the key is applied differently than a WPA passphrase, and T:WPA on a WEP network makes the handshake fail. You should not be running WEP at all, but if you inherit one, the field has to be honest about it.

nopass is for open networks with no password. The P field is ignored or left empty, and the phone joins without a key. This is the right value for an open guest network or a captive portal that authenticates later in the browser.

The failure mode is quiet. A wrong T value rarely produces a clear error. The phone shows the join prompt, tries the handshake, then sits on "unable to join" or connects without an IP address. Because the code scanned fine, the person blames the phone rather than the one wrong word in the payload.

How a phone reads the code without an app

Both major mobile platforms parse the WIFI: scheme at the operating system level, which is why a WiFi QR code works from the built in camera with nothing installed.

On iOS, the camera app recognizes the WIFI: prefix as it decodes the square and surfaces a "Join Network" banner at the top of the screen. Tapping it hands the parsed SSID, security type, and password to WiFi settings, which runs the connection.

On Android, the same thing happens through Google Play Services and the system camera, and there is a dedicated scan option under the WiFi settings menu. Because the parsing lives in the operating system, the same square works in any camera, which beats a link to a web page that displays the password.

Error correction and how big to print it

A QR code carries more than its raw data. Part of every code is redundancy, called error correction, that lets a reader reconstruct the content even when part of the square is damaged. The standard defines four levels: L recovers about seven percent of damage, M about fifteen percent, Q about twenty five percent, and H about thirty percent. Higher correction costs modules, so a level H code is denser than the same data at level L. For a printed card that will get handled, level M or Q is a sensible balance.

Print size follows the amount of data and the scanning distance. A short open network payload encodes into a small code that stays readable at two centimeters square. A long WPA password with escaped characters produces a denser code that needs roughly three to four centimeters square to stay reliable. A rule of thumb is that a code should be scannable from about ten times its width, so a three centimeter code reads comfortably from about thirty centimeters. Leave a quiet zone, the blank margin around the square, of at least four modules, or readers struggle to find the code's edges.

When a WiFi QR code is the wrong tool

The convenience of a WiFi QR code comes from one fact that is also its biggest limitation: the password is stored in the code as plain text. Anyone who scans the square, or photographs it and decodes it later, has the password in readable form. There is no encryption, no expiry, and no way to revoke one person's access short of changing the password for everyone. That tradeoff is fine, even ideal, for a home guest network or a cafe where the password is already on a chalkboard. It is the wrong tool in a few cases.

Enterprise networks that use 802.1X with a RADIUS server do not fit the format at all. Those networks authenticate each user with their own credentials or a certificate, not a shared passphrase, and the WIFI: grammar has no field for a username, an EAP method, or a certificate. A QR code cannot express that login, so it cannot connect a phone to a corporate or campus network running 802.1X.

Any network where the password is meant to stay secret is a poor match. If you would not write the password on a whiteboard in the room, do not put it on a QR code taped to the wall, because the code is the password. Networks that rotate their password often are a weak fit too, since every change means reprinting every code. A guest network's code can live on a card for a year; a key that changes weekly is out of date almost as soon as it is printed.

Why generating it in the browser matters

A WiFi QR code encodes a live credential, so where the code is built is a real privacy question. Many online generators send the network name and password to a server to render the image, which means the exact thing you are trying to share privately has traveled to a third party and may sit in a log.

A browser based generator avoids that. The SSID and password you type stay in the page, and the encoding runs as script on your own device, turning the payload into a grid of modules and drawing that grid to an image without a network request carrying the credential. You can confirm this by opening the browser's developer tools, watching the network tab, and generating a code: no request leaves with your password in it. For a home network, that is the difference between a password that stayed on your laptop and one posted to a stranger's server.

How the ReezoAI generator builds the code

The WiFi QR code generator on this site builds the code entirely in the browser. You enter the network name, choose the security type from WPA, WEP, or open, type the password, and mark whether the network is hidden. The tool assembles the WIFI: payload for you, including escaping any special characters in the name or password so the string parses correctly on strict readers.

From that payload the tool encodes the QR grid on your device and renders it as an image you can download and print or display on a screen for someone to scan. Because the assembly and encoding happen locally, the SSID and password never leave the page, and the generated code keeps a wear tolerant error correction level and a quiet zone so cameras lock onto the square quickly.

If you are making a card for a person rather than a network, the mechanics of embedding contact details are worth a read in the companion post on a vCard QR code for business cards.

The summary

A WiFi QR code is a short tagged string, WIFI:S:name;T:WPA;P:password;H:false;;, drawn as a scannable square. The SSID has to match the broadcast name exactly, special characters have to be escaped, and the security type has to be honest, because a wrong type fails quietly. iOS and Android parse the format at the operating system level, so any camera can offer a one tap join.

The code is only as private as the place it is printed, since the password rides inside it as plain text. That makes it a great fit for a home or cafe guest network and the wrong fit for an 802.1X enterprise network or any password that has to stay secret. Building the code in the browser keeps that password on your own device, which is the sensible default when the thing you are encoding is a key to your network.