Turn on a VPN before joining café Wi-Fi, and your device creates an encrypted connection to a VPN server. The café network can generally see that connection, but not the individual sites you reach through it. The VPN company, however, becomes part of your traffic’s route. That tradeoff—not a promise of invisibility—is the starting point for deciding whether a VPN helps.
What changes when a VPN is on?
A virtual private network routes selected traffic through an encrypted tunnel between your device and a VPN server. Websites reached through the tunnel usually see the server’s public IP address rather than the one assigned by your local network. That can obscure your approximate location, but logging in, changing browser settings, or sharing personal information can still identify you.
The tunnel protects traffic between your device and the VPN server. Beyond that server, the connection continues to its destination. If you visit an HTTPS site, your browser’s separate encrypted connection protects the contents of that exchange across the rest of the route. A VPN cannot give an unencrypted HTTP site end-to-end encryption.
The VPN provider may be able to observe connection metadata, including when you connect and which destinations your traffic reaches. Exactly what it can see depends on the application protocol and how DNS is handled. With HTTPS, it generally cannot read page contents or submitted passwords, though it may still learn the destination. In short, a VPN shifts some visibility from the local network and internet provider to the VPN provider. It does not make that visibility disappear.

Where a VPN adds practical protection
Shared and unfamiliar networks
On a network you do not administer, a VPN limits what the network operator can learn from traffic sent through the tunnel. It can also protect traffic from applications that do not handle transport security as carefully as a modern browser. HTTPS already protects the content of properly configured web sessions; a VPN is not what makes banking or email safe. Its separate benefit is an encrypted path for routed traffic and less visibility for the local network.
Remote access to a private environment
Organizations use VPNs to give authorized devices access to internal resources without exposing those resources directly to the public internet. A development team, for example, might use a company VPN to reach a private test service. Unlike a consumer VPN for general browsing, this setup is about access control and a protected network path, often paired with device checks and account permissions. Connect only to environments you are authorized to use. Being on a VPN does not give you permission to inspect everything you can reach.
Reducing exposure to an internet provider
Without a VPN, an internet provider can see connection information and may infer destinations, even when HTTPS hides page contents. A VPN limits that view of your destinations, but puts its operator in a comparable position of trust. That may be a worthwhile privacy tradeoff; it is not a reason to trust any provider by default.
What a VPN does not fix
A VPN cannot stop a fake login page from collecting a password you enter. It will not remove malicious attachments, patch vulnerable software, or prevent every kind of data theft from a compromised device. Sign in to a service, and that service still knows which account you used. Cookies and other browser data may also link your visits after your IP address changes.
A changed IP address is not an anonymity switch. Sites may recognize your account, browser characteristics, or a location you share yourself. VPN use may also conflict with service rules or local regulations. Check the rules that apply to your network and activity rather than treating a different IP address as permission to bypass them.
There is a performance cost to consider, too. Encryption and an extra route can add latency, particularly if the VPN server is distant or congested. A video call to a nearby service may suffer if its packets detour through another region. If an application stops working when you connect, treat that as a clue to investigate—not proof that the application is secure only with the VPN off.
Choosing a service without relying on slogans
Start with the problem you want to solve. On café Wi-Fi, dependable tunneling and sensible behavior when the connection drops matter. For work access, use the service and configuration your organization approves. For general privacy, look at what the provider could learn and what evidence backs its claims.
- Logging claims: Look for a clear account of what the provider collects, retains, and shares. “No logs” says little by itself; operational records and payment information may still exist.
- Protocol and app support: Choose a maintained client that supports modern, well-reviewed VPN protocols and receives security updates. Avoid setups that ask you to disable certificate checks or install unrelated browser extensions.
- Connection-drop protection: A kill switch can block traffic if the tunnel fails. Check whether it works on your operating system and whether it blocks all traffic or only selected apps.
- DNS and traffic routing: Check whether DNS requests use the intended tunnel and whether the app uses split tunneling. Neither setting is automatically right or wrong; it needs to fit your purpose.
- Account and device security: Use a unique password and multifactor authentication when available. The tunnel offers little help if someone else takes over the account that controls it.
Independent security assessments offer more to examine than advertising, but check their date and scope. An audit of one app version cannot establish that every server and policy will stay the same. Free does not automatically mean unsafe, and paid does not automatically mean trustworthy. In either case, consider how the provider funds its service and how clearly it explains its data practices.

Make routing behavior predictable
A VPN app may route all device traffic through the tunnel or exclude certain applications and destinations. Those exclusions are called split tunneling. They can be useful when a local printer or an approved work service needs a direct connection, but excluded traffic does not get the tunnel’s protection. If you are relying on a VPN to limit what an unfamiliar network can see, review those exclusions first.
DNS turns names, such as a service’s domain, into addresses. If DNS requests leave outside the intended tunnel, the local network or its DNS resolver may still learn which names your device looks up. IPv6 traffic can have a similar routing mismatch if the VPN does not handle it as expected. That is a configuration issue, not a reason to disable IPv6 blindly. Check the VPN app’s documented status information and your operating system’s network settings to see which connection is active.
On a trusted device and network, try a simple comparison: note the public IP address shown by a reputable IP-checking service before and after connecting, then check that the VPN app reports the expected server. This confirms an obvious routing change, not complete privacy. Run DNS or connection tests only against services you are permitted to use, and do not upload sensitive traffic captures to a testing site.
Put the VPN alongside other controls
Keep HTTPS enabled in your browser, install updates, and use strong account authentication whether or not the VPN is connected. Take browser certificate warnings seriously: the tunnel cannot verify a website’s identity for your browser. Follow your organization’s policy on when to disconnect a work VPN, too. Leaving it running is no substitute for locking your device or limiting access permissions.
For a personal laptop on public Wi-Fi, install the provider’s current app from its official distribution channel. If the app supports it, enable automatic connection on untrusted networks, and check the kill-switch setting before relying on it. Then, on a permitted test connection, briefly disconnect the VPN and see whether traffic is blocked as promised. That tells you more about what happens during a tunnel failure than a “connected” icon can.
