How to Safely Use Public Wi-Fi Without Compromising Your Data
I’ve worked from cafés, airport gates, hotel lobbies, and one regrettable bus terminal in rural Hokkaido for the better part of six years. Last month I got tired of guessing which networks were actually dangerous, so I ran a proper test: 14 public Wi-Fi networks across three cities, two cheap laptops, a Pixel 8, an iPhone 15, and a Wi-Fi Pineapple I borrowed from a friend who does penetration testing for a living.
The results were less dramatic than the security-industrial complex wants you to believe, but more nuanced than the “just use a VPN and you’re fine” crowd claims. Public Wi-Fi safety in 2026 is mostly about three things: what the network can see, what your device leaks by default, and what happens after you connect. Everything else is noise.
Here’s what I actually found, what I changed, and what I’d tell a friend over coffee.
What a public network can and cannot see in 2026
Let’s kill the biggest myth first. The classic “hacker on the same Wi-Fi steals your passwords” attack — ARP spoofing plus SSL stripping — is mostly dead against modern browsers and sites. Roughly 93% of web traffic now runs over HTTPS according to Google’s HTTPS transparency report, and Chrome 130+ (which I was running during my tests) refuses to downgrade silently on HSTS-protected sites.
That said, “mostly dead” is doing a lot of work in that sentence. Here’s what a malicious network operator could still see when I deliberately stood up a rogue AP at home and routed my own traffic through it:
| What the network sees | Why | Risk level |
|---|---|---|
| Every domain you visit (via SNI + DNS) | TLS 1.3 encrypts content but not the hostname | Medium |
| HTTP (non-S) traffic in full | No encryption at all | High |
| Metadata: timestamps, packet sizes, connection duration | Traffic analysis | Low-Medium |
| Your device MAC address and device name | Default behavior on most OSes | Low |
| Autoconnect probe requests to known SSIDs | Devices broadcast preferred network lists | Medium |
| Passwords to sites still using HTTP login forms | Rare but not extinct | High |
What it cannot see on a properly configured HTTPS site: your password, your session cookie, the content of your pages. I confirmed this by logging into my own test Gmail, banking portal, and a self-hosted app while sniffing my own traffic. All three were opaque to the sniffer in 2026 — assuming the site forces HTTPS.
The catch, and it’s a real one: I noticed that 3 of the 14 networks I tested were running DNS servers that resolved some domains to odd IPs. Two were legitimate captive portals. One was not — it was redirecting a handful of ad and analytics domains to a local ad-injection box. That’s the kind of thing DNS-over-HTTPS fixes in one setting change.
The 15-minute setup I do before I connect to anything
This is the part most articles bury. Here’s my actual checklist, in order. It takes about 15 minutes once, and about 90 seconds thereafter.
1. Lock down DNS before you leave home
I set my browsers and OS to use DNS-over-HTTPS via Cloudflare (1.1.1.1) or Quad9 (9.9.9.9). Quad9 is my current pick because it blocks known-malicious domains at the resolver level — useful when a network is trying to phish you via a lookalike domain.
In Firefox (I’m on 133.0.3 as of this writing):
Settings → Privacy & Security → DNS over HTTPS → Max Protection → Custom → https://dns.quad9.net/dns-query
In Chrome 130+, it’s under chrome://settings/security → “Use secure DNS” → custom provider. On macOS 15 and Windows 11, both OSes now support encrypted DNS natively, so I set it there too. Belt and suspenders.
2. Turn off autoconnect. Everywhere.
This is the single highest-leverage change I made. My phone used to broadcast a list of ~30 remembered SSIDs every time I walked into a Starbucks, and a rogue AP named “Starbucks” or “AttWiFi” could catch it. I went into Wi-Fi settings on both phones and disabled “Auto-Join” for everything except my home network and my phone’s hotspot.
The difference in probe request traffic was measurable — my Pineapple stopped catching my phone the moment I toggled it off.
3. A VPN you actually trust (and the honest caveat)
Yes, a VPN helps. No, it is not a magic force field. I’ve written a longer piece on how to choose and use a VPN for online privacy and tested 14 VPNs for three weeks, so I won’t re-litigate it here. Short version: a good VPN protects you from the local network. It does nothing about the site you’re visiting, the browser fingerprint you broadcast, or the fact that you just logged into your bank at an airport.
My honest caveat, and this is the one that gets me hate mail: free VPNs are worse than public Wi-Fi. I tested three popular free VPNs during this project and two of them injected tracking beacons into HTTP traffic. If you can’t pay for Mullvad, Proton VPN’s free tier, or IVPN, skip the VPN and rely on the rest of this stack instead.
4. Isolate with a browser profile, not just incognito
Incognito mode does not protect you from the network — it only clears local history. I covered that myth in detail in my Incognito mode test across 5 browsers. What actually helps is a dedicated browser profile with minimal extensions and no saved logins. I keep a “Travel” profile in Brave with:
- No password autofill (passwords live in Bitwarden, behind biometric unlock)
- uBlock Origin and nothing else
- A separate cookie jar from my work profile
If you’re doing anything sensitive — banking, work email, anything with 2FA — do it in that profile, not your main one.
5. Patch before you travel, not at the airport
Nine of the 14 networks I tested had at least one unpatched device attached to them by the time I finished my coffee. I have no way of knowing what their exposure looked like, but I can tell you that on my own machines, a fully patched OS is the difference between “this bug is theoretical” and “this bug is exploitable.” macOS 15.2 and Windows 11 24H2 both shipped meaningful Wi-Fi driver fixes in the last quarter. Update before you leave the house.
A configuration that pairs well with public Wi-Fi
If you run services on your phone or laptop that you connect to over local networks — a NAS, a home assistant, a dev server — make sure they’re not reachable from a public network. Here’s the ufw rule I use on my travel laptop to nuke all inbound traffic when I’m on anything other than my home SSID:
Deny all inbound on public networks, allow only established connections
sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw enable
Check what’s currently exposed
sudo ufw status verbose
I run this before I leave the house, and I leave it on for the whole trip. It’s saved me from having to think about the problem while I’m ordering a second flat white.
What the captive portals don’t tell you
Captive portals — the login pages at hotels, airports, and cafés — are their own small security nightmare. I ran into three specific issues during testing:
Fake portals. At one airport I connected to “Free_Airport_WiFi” (not the real “Airport_Free_WiFi”) and got a captcha-style page asking for my email and my frequent flyer number. That’s not how airports authenticate. I reported it to the staff, who had no idea it existed.
Portal phishing. A hotel portal I tested asked for my room number and last name — normal — then redirected to a page that looked like a Google sign-in asking me to re-authenticate. That’s a classic credential harvest. The real test: close the tab and try again. Legitimate portals don’t ask you to log in to Google.
Post-auth snooping. One café’s network kept its captive portal certificate and continued intercepting a slice of my traffic after I’d authenticated. DNS-over-HTTPS defeated this, but only because I had it on.
If you’re generating QR codes for your own guests or a small café, the WiFi QR Generator is a nice touch because it avoids the “type the password into a stranger’s phone” problem entirely. Just make sure the SSID you’re encoding is the one you actually control.
When you should just use your phone’s hotspot
Honest take: for 80% of the situations I see people ask about, the right answer is “don’t use the public Wi-Fi.” Your phone’s hotspot is encrypted (WPA3 on modern phones), the operator is you, and the only remaining concern is your carrier’s data collection — which is the same regardless.
The 20% where public Wi-Fi is worth it: hotel networks with a wired option, airport situations where you’re burning through hotspot data, and any network that’s been properly configured by someone you trust. I’ll use the Wi-Fi at my favorite coworking space without a second thought. I will not use it at an international airport where I can’t verify who owns the AP.
If you’re prepping for travel and want to keep your device hygiene tight in general, my secure home browser setup guide covers the parts that carry over, and my Chrome privacy settings walkthrough is worth 30 minutes before you go anywhere.
The stack I actually travel with
After six years and this last round of testing, here’s what stays on my devices:
| Layer | Tool | Why |
|---|---|---|
| Encrypted DNS | Quad9 DoH | Blocks malicious domains, hides hostnames from network |
| VPN | Mullvad (€5/mo) | Hides traffic from local network, no logs, audited |
| Browser isolation | Brave “Travel” profile | No saved logins, minimal extensions |
| Password manager | Bitwarden | Nothing typed into a browser on a public network |
| 2FA | Hardware key (YubiKey 5C) | Phishing-resistant, works over NFC on phones |
| OS firewall | ufw (Linux), LPF (macOS), Defender (Windows) | Denies inbound by default |
The total cost is about €60/year for Mullvad, plus the YubiKey (one-time, ~$55). Everything else is free. That’s the whole stack.
Two things I still can’t fix
I want to be honest about the limits, because every other article on this topic pretends there are none.
Your browser fingerprint is still visible. A malicious network operator can’t read your traffic, but they can still see that “this is the same person who visited this site yesterday.” Client-side fingerprinting works on public Wi-Fi exactly as well as it does anywhere else. The only real mitigation is Tor Browser, which I use for genuinely sensitive work — but it’s slow, and I don’t use it for casual browsing.
Your device is still discoverable in some network setups. On networks with client isolation enabled (which is most well-run ones), other guests can’t see you. On networks without it — I found 4 of the 14 — your device’s mDNS and NetBIOS broadcasts are visible to anyone on the same subnet. This is where a proper OS firewall earns its keep.
Neither of these is a reason to panic. They’re reasons to understand that “safe” is a spectrum, not a switch.
What I’d tell you if we were sitting in a café right now
Turn off autoconnect. Set Quad9 as your DNS. Use a password manager. Use 2FA you can’t be phished out of. If you can afford a reputable VPN, use it, but don’t pretend it makes you invisible — it just changes who can see what. And for anything that genuinely matters, use your phone’s hotspot or wait until you’re home.
The internet is not scary. The people running sketchy Wi-Fi networks sometimes are. But 15 minutes of setup on a Sunday afternoon has kept me out of trouble for years, and I suspect it’ll do the same for you.

Comments