You turn on a VPN, a website shows the VPN server's IP address, and you assume you're covered. Usually you are. But browsers have a second way of discovering your network addresses that doesn't go through the normal path your web traffic takes, and if your VPN doesn't account for it, a site can learn your real public IP anyway.
That second path is WebRTC. This post explains what it is, what a leak actually looks like, why the most common "leak" people find isn't one, and how to check your own setup with the What's My IP tool.
What WebRTC does
WebRTC is the browser technology behind video calls, screen sharing, and peer-to-peer file transfer. Its whole job is to connect two devices directly, and to do that each side has to work out how the other can reach it. It gathers a list of "candidates," addresses where it might be reachable:
- Host candidates: addresses on your own network interfaces, like
192.168.1.23. - Server-reflexive candidates: your public address as seen from outside, discovered by asking a STUN server "what IP do you see me coming from?"
Any web page can start this process with a few lines of JavaScript, without a camera or microphone prompt. That's the root of the leak.
What a leak looks like
When you browse through a VPN, your HTTP traffic goes through the tunnel, so sites see the VPN's address. A WebRTC request to a STUN server is UDP traffic. If the VPN only routes some traffic, has a split tunnel, or the browser picks a network interface outside the tunnel, the STUN server sees your real ISP address and reports it back to the page.
So the test is simple: compare the IP your normal connection shows with the public IP WebRTC reports. If they're different and the WebRTC one belongs to your ISP, you have a leak.
The false alarm almost everyone hits: IPv4 vs IPv6
Most home connections today are dual-stack: they have both an IPv4 and an IPv6 address. Your browser might load a page over IPv6 while the STUN request goes over IPv4, or the other way round. A naive leak test sees two different public addresses and shouts "leak!"
It isn't one. Those are two addresses for the same connection, and without a VPN both of them are yours. The right comparison is like for like: your IPv4 with WebRTC's IPv4, your IPv6 with WebRTC's IPv6. The tool on this site does that, and when it only sees the other family it explains the difference instead of raising an alarm. (I learned this one the honest way: an early version of the test flagged my own home connection as leaking.)
If you're on a VPN, though, look at the other-family address too. A VPN that only tunnels IPv4 and lets IPv6 go out directly is a classic leak, and that IPv6 address will be your ISP's.
What about local addresses?
Older browsers handed out your local network address (192.168.x.x) to any page. That isn't a direct privacy disaster, but it helps with fingerprinting and with attacks against devices on your network. Modern browsers hide local addresses behind random .local names (mDNS) unless you've granted camera or microphone access. If the test shows your local addresses as hidden .local names, your browser is doing its job.
How to test
- Open What's My IP with your VPN off and note your public IP and location.
- Turn the VPN on and reload. The IP and location should change to the VPN server's.
- Click Run leak test. It asks Google's public STUN server what address it sees, the same way a video-call app would, and compares the answer with your connection's IP.
- Read the result:
- No leak: WebRTC shows the same public IP as your connection.
- Possible leak: WebRTC shows a different IP of the same type. If that's your ISP's address, your real IP is exposed.
- Other IP family: WebRTC reports your IPv4 while you connected over IPv6 (or vice versa). Normal without a VPN; on a VPN, check that it's the VPN's address.
While you're there, check the timezone card. If your IP's timezone is in one place and your browser says another, sites can notice, and some fraud and streaming systems do. It's a common giveaway that you're on a VPN even when nothing is leaking.
How to fix a leak
- Turn on your VPN's WebRTC or leak protection. Most major VPN apps and their browser extensions have it.
- Make sure the VPN tunnels IPv6, or disables it while connected. Leaking over IPv6 is one of the most common real leaks.
- Avoid split tunneling for your browser if privacy is the point.
- Restrict WebRTC in the browser if your VPN can't. Firefox can disable it entirely in
about:config(media.peerconnection.enabled). Chromium-based browsers need an extension or a policy to limit which interfaces WebRTC uses. - Re-test after every VPN or browser update. Settings get reset.
A note on how the tool works
The IP lookup on this site doesn't call a third-party IP service. It asks the site's own server, which reads the address and approximate location that the hosting platform already attaches to every request, and returns them to you without logging anything. The leak test runs only when you click it, and contacts one STUN server. The analyzer below it works entirely in your browser: paste any IPv4 or IPv6 address to see whether it's public, private, carrier-grade NAT, or reserved, along with its integer, binary, and reverse-DNS forms. If you work with networks, the Subnet Calculator pairs well with it.