How to Create a Wi-Fi QR Code for Guests

This is non-negotiable. A WiFi QR makes the encoded password trivially extractable by anyone who can decode a QR — which, in 2026, is anyone with a phone. If the QR encodes your primary business network credentials, you've handed admin-network access to every person who scans the code, every photo of the code on Instagram, every screenshot in a guest's camera roll.

A separate guest network with its own SSID and password, isolated from internal systems, is the right architecture for any QR-based WiFi sharing.

What "isolated" means. The guest network should not have route access to your POS, inventory database, employee workstations, security cameras, or admin panels. Most modern routers (Ubiquiti, Aruba, ASUS, Netgear, TP-Link prosumer line) handle this via VLAN isolation in the guest network configuration. Enable it.

Bandwidth control. Cap guest network bandwidth to avoid one heavy user (4K video stream, large file download) degrading the connection for your POS or VoIP. 10–25 Mbps per device is a typical cap for a cafe or hotel; higher for premium hospitality.

Captive portal vs open join. A captive portal (the splash page with terms and email capture) layers on top of the WiFi QR — the guest scans, joins the network, then sees the portal on their first HTTP request. Hospitality and retail commonly run both. The QR removes the password-typing friction; the portal handles the legal terms and email capture.

Password discipline. Rotate the guest password on a defined schedule — 30 days for high-traffic venues, 90 days for low-traffic offices. The password lives on a printed code; treating it as static-forever invites long-tail security incidents (former employee shares the password publicly, photo of the QR ends up on a competitor's recon list).

Audit trail. Most guest network controllers log the MAC addresses that join. Keep the logs; they're sometimes needed for incident response. The QR code security risks article covers the broader attack surface for QR-based credential sharing.

The T field determines which authentication method the phone uses to join. Get it wrong and the join fails silently on some devices, even when the password is correct.

WPA / WPA2 — the safe default for most deployments. Use T:WPA (no version suffix) for any network running WPA, WPA2, or WPA2/WPA3 transition mode. iOS and Android camera apps treat WPA as the generic value and handshake on whichever protocol the router actually offers. This is what 95%+ of small-business WiFi QRs should use.

WPA3 — the spec-compliant value vs the practical value. The official spec for WPA3 personal authentication is T:SAE (Simultaneous Authentication of Equals). The catch: most QR generators emit T:WPA even on pure-WPA3 networks, because iOS and most Android builds accept WPA as a wildcard. A handful of strict parsers (some Linux WiFi managers, certain corporate device builds) reject WPA on a pure-WPA3 network and require SAE explicitly.

If your network is mixed WPA2/WPA3 (the default on most modern routers), use WPA. If your network is pure WPA3 with no WPA2 fallback, you have a choice — emit WPA and accept the rare edge-case failure on strict parsers, or emit SAE and accept that older devices may not recognize the value at all. The pragmatic call for hospitality is WPA with WPA3 transition mode enabled on the router.

WEP — replace your router. T:WEP is supported by the format but WEP itself is cryptographically broken — has been since 2004. If your router still uses WEP, the right fix is replacing the router, not generating a QR.

Open networks — use nopass. T:nopass for open networks with no password. The P field is omitted or empty. Captive portals layer on top of nopass networks transparently.

Mixed-mode pitfalls. If your router is configured for "WPA/WPA2 mixed" but is actually running WPA only (some legacy enterprise gear), T:WPA works but T:WPA2 may fail on iOS. When in doubt, use the unsuffixed T:WPA.

The S and P fields look simple — paste the SSID and password and you're done — but five subtle traps cause the majority of WiFi QR failures we see in real deployments.

SSID case sensitivity. "CafeWifi" and "cafewifi" are different networks. Copy the SSID from the router admin panel or the back-of-router sticker, not from memory. A capitalization mismatch produces a silent join failure — the phone reads the QR, parses the SSID, looks for that exact network name, and fails to find it.

Special-character escaping. The WIFI: format reserves five characters: backslash (\), semicolon (;), comma (,), colon (:), and double-quote ("). If any of these appear in your SSID or password, they must be escaped with a leading backslash.

The most common gotcha: SSIDs containing semicolons (rare but possible) or passwords containing semicolons (more common in long passphrase generators). Without escaping, the parser treats the semicolon as a field separator and truncates the password mid-string.

Hospitality example. A hotel password set to Welcome;2026! and encoded without escaping produces WIFI:T:WPA;S:HotelGuest;P:Welcome;2026!;;. The parser reads the password as Welcome and joins fail on every device. The fix: encode as P:Welcome\;2026!. Reputable generators handle this automatically; check by decoding the QR with a debug tool before printing at scale.

Password length and Unicode. WPA2 passwords are 8–63 ASCII characters or 64 hex digits. Unicode characters (emoji, accented characters, non-Latin scripts) in passwords work on most modern hardware but cause edge-case failures on older devices. Stick to printable ASCII for any QR-distributed password.

SSID Unicode and emoji. Some venues use emoji SSIDs ("☕ Coffee Bar"). The format supports them, iOS handles them gracefully, Android handling varies by manufacturer. Test on your audience's typical device before committing.

Hidden networks. If the SSID isn't broadcast, set H:true. Most generators expose this as a checkbox. Without the flag set, the phone may scan for the SSID and fail to find it (because it isn't broadcasting), producing a silent join failure even when all other fields are correct.

Trailing whitespace. A trailing space in the SSID or password (easy to introduce when copy-pasting from a CRM) is invisible in the form but breaks the join. Trim before encoding.

Test before scale-printing. Decode the QR with a debug tool (or a phone) and visually inspect the raw string. The minute cost of decoding once saves the reprint cost of 1,000 hotel room cards with a broken QR.

The static-vs-dynamic decision for WiFi QRs comes down to a single variable: how often does the password change?

Static is the right default for most WiFi QRs. The credentials are encoded directly into the QR pattern. No vendor server, no subscription, no internet required for the scan to work — which is the whole point of WiFi QRs (the scanning phone often has no internet until it joins the network you're sharing). When the password rotates, you regenerate the QR and reprint.

Static breaks down at high rotation cadence. A cafe rotating its guest password monthly across 12 table tents = 144 reprints per year. A 200-room hotel rotating quarterly = 800 reprints per year. At that volume, the print cost and operational coordination start to dominate.

Dynamic QR codes solve the rotation problem. A dynamic WiFi QR encodes a redirect URL rather than the credentials directly. The vendor server resolves the redirect to a credential payload, which the phone parses and uses to join.

The catch: dynamic WiFi QRs require the scanning phone to have internet access to hit the redirect server. For a hotel guest with no cellular signal, the dynamic QR fails — they need WiFi to scan the WiFi-join QR, which they can't get without joining the WiFi. Static handles this case; dynamic doesn't.

The hybrid pattern that actually works. Print a static QR with the current password for the offline-first scan, and post a separate dynamic QR (or short URL) on your website for guests who already have cellular and want the current credentials without checking signage. The static handles arrival; the dynamic handles in-stay updates.

Vendor lock-in considerations. A dynamic WiFi QR stops working if the vendor cancels the redirect or shuts down. For hospitality with long-life printed assets (room cards, table tents that last 1–3 years), static avoids the dependency. For high-rotation venues willing to accept the dependency, dynamic saves the reprint cost.

EZQR's $5/month Lite plan supports both — static for the always-works deployment and dynamic for high-rotation guest networks. The dynamic vs static guide covers the full trade-off matrix.

WiFi QR scanning splits cleanly across three device tiers.

Native camera scan — works out of the box. iOS 11+ (iPhone 5s and newer, shipping since 2017), Android 9+ on Google Pixel and Samsung Galaxy, Android 10+ on most other manufacturers. The user opens the camera app, points at the QR, taps the "Join NetworkName" notification. No app install, no third-party software.

This covers approximately 95% of phones in active use in 2026 (US/EU markets). For hospitality with international audiences, the coverage drops slightly — China-market phones (Huawei post-GMS, Xiaomi older builds) sometimes require an app for WiFi QR specifically while supporting URL QRs natively.

App-required tier. Older Android (8 and earlier), some China-market phones without Google Mobile Services, certain rugged industrial phones. The user needs Google Lens, the Samsung Camera app's QR mode, or a third-party scanner (Trend Micro QR Scanner, Kaspersky QR Scanner). Penetration of these phones in mainstream hospitality audiences is under 5%; for retail with broader demographics, plan for 5–10%.

The fallback that handles both. Print the password as readable text below or beside the QR. The fast scanners hit the QR; the older devices type the password. The cost is two extra lines of print; the benefit is zero excluded customers.

Captive portal interaction. A guest scans the QR, joins the network, and on their first HTTP request sees the captive portal. iOS auto-opens the portal in the camera-app's web view; Android (on most builds) opens it in the default browser. Both flows complete the portal terms acceptance and proceed to internet access.

Mac and Windows scanning. macOS Sonoma+ scans QRs through the camera or screenshot. Windows 11 supports QR scanning through the Camera app. WiFi-join via QR is iOS/Android territory; desktop scans of WiFi QRs require manual SSID/password entry.

The 10:1 sizing rule applies the same way it does for any QR: code width = scanning distance / 10. WiFi QRs are scanned at predictable distances in well-defined contexts, which makes sizing tractable.

Reception desks and check-in counters. Guests scan at 30–50 cm reach. Minimum QR size 5 cm × 5 cm; comfortable 6–7 cm. The QR is large enough to scan from a phone held at arm's length without the guest leaning over the counter.

Hotel room cards. Scanned at 20–30 cm on a bedside table. Minimum 4 cm × 4 cm; comfortable 5 cm. The card is itself small (typically 9 × 5 cm), so the QR plus the brand assets and the scan-prompt text use most of the card real estate.

Cafe and restaurant table tents. Scanned at 30–60 cm seated. Minimum 4 cm × 4 cm; comfortable 5–6 cm. Multi-purpose tents (WiFi + menu + review) should use separate QRs per job rather than a single QR linking to a hub — per-job QRs convert at 2–3× the rate of shared navigation pages.

Wall signs near seating areas or lobbies. Scanned at 1–2 m. 10–15 cm minimum; 15–20 cm comfortable. Hospitality wall signs benefit from oversizing because the lighting is often lower than office spaces. See the size guide for the full distance formula.

Print quality matters more than for typical QRs. A WiFi QR has higher per-scan stakes than a menu QR — a failed scan means the guest gives up and asks the front desk, which defeats the purpose. Use matte lamination (glare-free), 300 DPI minimum print resolution, and substrate appropriate for the placement (waterproof for poolside, durable for high-touch reception counters).

The password as fallback text. Print "WiFi: NetworkName / Password: NetworkPassword" below or beside the QR in legible 10–12pt type. Three benefits: older phones that can't scan WiFi QRs work, the visual reassurance that the QR is "real" (some guests don't trust QR codes), and accessibility for guests with vision impairments using OCR rather than camera scan.

Adjacent CTA copy. "Scan to connect to WiFi — no app needed" outperforms a naked QR by 2–3× in hospitality client deployments. The CTA reduces the moment-of-decision friction that kills QR conversion. The QR code best practices guide covers the CTA-copy patterns that consistently outperform.

When deployed WiFi QRs fail, the failure is almost always one of seven causes. Run this checklist before suspecting the QR generator or the QR itself.

1. Encryption type mismatch. The QR encodes T:WPA2 but the router runs WPA3 only. Phone reads the QR, attempts WPA2 handshake, fails. Fix: change T to WPA (the wildcard) or SAE (the spec-correct WPA3 value). Verify in router admin panel which encryption is actually active.

2. SSID case mismatch. The QR encodes S:CafeWiFi but the router broadcasts S:cafewifi. The phone parses the QR, looks for the exact SSID, fails to find it. Fix: copy the SSID character-for-character from the router admin panel.

3. Hidden network flag missing. The router has SSID broadcast disabled, but the QR omits H:true. The phone parses the credentials, scans for the SSID in the broadcast list, fails. Fix: regenerate with the hidden network checkbox enabled.

4. Special character not escaped. The password contains a semicolon, comma, or backslash, and the QR encodes without escaping. The parser truncates the password at the unescaped delimiter. Fix: regenerate with proper escaping or change the password to plain ASCII without reserved characters.

5. Password changed at the router but the QR wasn't regenerated. Common in venues where IT and front-of-house operate separately. The router admin rotated the password Tuesday, the printed QR still encodes the Monday password. Fix: regenerate the QR and reprint. This is the case where dynamic QRs earn their subscription cost.

6. Trailing whitespace. An invisible space after the SSID or password in the generator form survives into the QR, breaks the join. Fix: regenerate with trimmed input.

7. Captive portal blocking the join detection. The phone joins the network, but the captive portal redirect intercepts the connectivity-check request, and iOS shows the network as "no internet" temporarily. Most current iOS builds handle this gracefully; older builds may show a "Failed to join" error that's actually a portal-detection issue, not a credential issue. Fix: configure the captive portal to allow the iOS/Android connectivity-check endpoints.

Diagnostic shortcut. Decode the QR with a debug tool (most QR generators expose this) or scan with the Trend Micro QR scanner app, which shows the raw decoded string. Compare the parsed string field-by-field against your router config. The mismatch surfaces immediately. The why QR code expired article covers adjacent failure patterns; the QR code stopped working guide covers the broader failure-mode taxonomy.