Do You Really Need a VPN on Public Wi-Fi?

You have heard the line a hundred times: never use public Wi-Fi without a VPN, or a hacker at the next table will help themselves to your bank password. It shows up in VPN ads, airport posters, and well-meaning security tips from a decade ago. So: do you actually need a VPN on public Wi-Fi in 2026?

The honest answer is that the specific danger that warning was built around — someone silently reading your passwords out of the air at a café — is mostly a 2010s story now. The web changed underneath it. That does not make a VPN pointless on public Wi-Fi, but it does move the reason you might want one somewhere less dramatic than “your bank account is one coffee away from being drained.”

The Threat the Warning Was Built For

Rewind to roughly 2012. A large share of websites still served pages over plain, unencrypted HTTP — including, for a while, the non-login parts of major email and social sites. On an open Wi-Fi network, every device shares the same radio space, so anyone running free packet-capture software nearby could read those pages as they flew past: what you were browsing, form contents, and in the worst cases session cookies that let them log in as you. Tools like Firesheep made the point deliberately easy to demonstrate. In that world, tunneling all your traffic through an encrypted VPN was a genuine fix for a genuine, everyday problem.

Two things happened since. First, the web encrypted itself. According to Firefox Telemetry data published by the nonprofit behind Let’s Encrypt, the share of web page loads using HTTPS went from under 30% in 2013 to around 80% globally — and roughly 95% for users in the United States — by 2026.[2] The same encryption that protects a page from your internet provider protects it from the stranger with a laptop at the next table. They see that your device is talking to some server, and they see encrypted noise. They do not see your password.

Second, browsers got aggressive about enforcing it. A modern browser shows a full-page warning, not a small icon, when a site’s certificate is invalid or missing — the kind of warning most people won’t click through. And browsers ship a hardcoded list, the HSTS preload list, of tens of thousands of domains that must be loaded over HTTPS, refusing to connect over plain HTTP even on the very first visit.[4] That specifically kills the classic “SSL stripping” trick, where an attacker on the network quietly downgrades your connection to HTTP so they can read it. For a preloaded site — which includes essentially every bank, major email provider, and large retailer — that downgrade simply fails.

The U.S. Federal Trade Commission’s consumer guidance reflects this. Its public Wi-Fi page states plainly that “because of the widespread use of encryption, connecting through a public Wi-Fi network is usually safe,” and it does not recommend a VPN at all — a notable shift from the agency’s older advice, which used to lead with one.[1]

What Public Wi-Fi Can Still See

“Usually safe” is not “nothing leaks.” Encryption protects the contents of your traffic. It does not hide everything about it, and this is where a VPN still does real work.

The domains you visit. When your device opens an encrypted connection to a website, the very first message of the TLS handshake normally includes the site’s hostname in the clear — the Server Name Indication, or SNI — so the server knows which certificate to present. An IETF standard published in March 2026, Encrypted Client Hello, exists specifically to close this gap; its own introduction calls the plaintext SNI “perhaps the most sensitive information left unencrypted in TLS 1.3.”[3] But Encrypted Client Hello is new and not yet universally deployed, so on many connections the network operator can still build a list of the sites you opened, even without seeing a single page. The destination IP address is visible regardless. And unless your device is using encrypted DNS, the network also sees every domain lookup — which browsers increasingly handle for you: Firefox turned on DNS-over-HTTPS by default for US users in February 2020, and Chrome added it in the same period.[6] That helps inside the browser. It does nothing for other apps or system-level lookups.

A VPN collapses all of that into one encrypted connection to the VPN server. The café, the hotel, the airport, and your home ISP see that you are connected to a VPN and nothing else — not the domains, not the DNS, not the destination IPs. That metadata does not vanish; it moves to the VPN provider, which is why an independently audited no-logs record matters. But if what bothers you is the network operator profiling which sites you use, that is the concrete thing a VPN fixes on public Wi-Fi in 2026.

A hostile access point. HTTPS stops passive eavesdropping. It does not stop someone from running the network. An “evil twin” is a rogue access point named to look like the real one — Airport_Free_WiFi — that you or your phone connect to automatically. A peer-reviewed review of these attacks from 2005 to 2026, published in August 2026, concludes that while HTTPS and HSTS have “reduced the effectiveness of basic attack variants,” the technique “is not diminishing; rather, it is mutating,” and remains “highly viable, particularly in high-turnover public and enterprise environments” like airports and hotels.[5] What still works is not password-sniffing. It is the captive portal: a fake “sign in to continue” or “update your browser” page that phishes credentials or pushes malware directly, and SSL-stripping against the minority of sites and apps that are not on the preload list. A VPN helps against the first of those two — once the tunnel is up, the portal can’t interpose on your traffic — but it does not stop you from typing your email password into a convincing fake page before you connect.

Legacy apps and old devices. The “usually safe” picture assumes up-to-date software. An old app that still falls back to HTTP, a smart device that never learned about HSTS, an operating system years behind on updates — these can still leak on a hostile network in the old-fashioned way. If you are stuck using something like that on public Wi-Fi, a VPN is a reasonable blanket over software you can’t fix.

What a VPN Does Not Fix Here

The limits deserve the same plain statement, because the same ads that oversell the threat oversell the cure.

A VPN does not stop phishing. If a captive portal or a lookalike email convinces you to hand over a password, the tunnel carried it faithfully to the attacker. It does not stop malware you download and run. It does not make you anonymous to a site you log into — your account is your account. It does not protect against someone shoulder-surfing your screen, and it does nothing about newer research into identifying people from the physical patterns of Wi-Fi signals in a room, which doesn’t touch your traffic at all. A VPN is a network-layer tool. Most of what goes wrong on public Wi-Fi in 2026 happens above that layer, in the browser and in the user.

So, Do You Need One?

Not in the sense the poster meant. Your banking session on a café network is protected by the bank’s HTTPS whether or not you run a VPN, and an official consumer regulator now calls that setup “usually safe.”[1]

A VPN on public Wi-Fi is still worth running if:

• You don’t want the network operator building a profile of the sites you visit. This is the strongest everyday reason. HTTPS hides the pages; it often does not hide the domains, and a VPN does.
• You are on a device or app you don’t fully trust to enforce HTTPS — something old, unpatched, or obscure. The tunnel covers for it.
• You are somewhere with a real incentive for a hostile access point — a big airport, a conference, a hotel in a location where you’d rather not take the chance — and you want the tunnel up before you touch anything. Just connect it before interacting with any sign-in page.
• You already run one all the time for jurisdiction or ISP-tracking reasons. Public Wi-Fi is not a special case then; it’s just another network.

If none of those describe you, keeping your software updated, letting the browser enforce HTTPS, and not typing passwords into captive-portal pages covers the realistic risk. The VPN is a metadata and legacy-device tool now, not a shield against a myth about the person at the next table.