What a WebRTC leak actually is
WebRTC is the browser technology behind video calls, voice chat, and peer-to-peer file transfer. To connect two people directly, each browser has to discover its own reachable IP addresses and share them. It does this through a process called ICE, querying a STUN server that replies with your public address.
The problem: this discovery can happen outside your VPN tunnel. A page you're visiting can quietly run the same negotiation and read the public IP that comes back — the very address your VPN is supposed to hide. No permission prompt, no download. That's a WebRTC leak.
Who this matters for
- Anyone using a VPN specifically to keep their real IP and location private.
- People on networks where the browser exposes a reflexive (public) candidate despite the tunnel.
- Privacy-conscious users who want to confirm their setup does what they think it does.
How this test works
The page creates an RTCPeerConnection against several public STUN servers, opens a throwaway data channel, and reads the ICE candidates your browser generates. Candidates typed srflx, prflx, or relay carry an address other machines can reach. A public address that differs from the IP this page already used over HTTP is a leak — WebRTC left the tunnel. A public address that matches the HTTP path is the same connection, not a bypass. mDNS-obfuscated (.local) candidates and private-range addresses are never counted as leaks.
A green result means this specific check passed — WebRTC did not expose an extra public address at this moment, in this browser. It does not prove you're anonymous: DNS, IPv6, fingerprinting, and cookies are separate channels with their own tests.
How to fix a WebRTC leak
There are two honest routes, and the right one depends on your situation:
1. Harden the browser
- Firefox: open
about:configand setmedia.peerconnection.enabledtofalse. This disables WebRTC entirely — simple, but breaks browser calls. - Chrome / Edge / Brave: there's no native off switch. Brave exposes a WebRTC IP-handling policy under privacy settings; Chrome needs an extension that restricts WebRTC to your proxied address.
2. Use a VPN that closes the leak at the network layer
A well-built VPN app blocks WebRTC from ever seeing your real address, so you don't have to disable a feature you actually use. This is the maintenance-free route, and it's why a red result above points you to VPNs that are verified to handle WebRTC correctly — not every one does.
Common questions
Does a green result mean I'm fully anonymous?
No — it means this specific leak isn't present. Anonymity depends on DNS, IPv6, fingerprinting, cookies, and account logins too. Run the other tests in the suite for the full picture.
Why did the test show a local address like 192.168.x.x?
That's a private LAN address, not your public IP, and it can't identify you on the internet. Modern browsers also mask it behind a .local name. The address that matters for a leak is a public (reflexive) one.
I'm not using a VPN. Should I care?
Less so — without a VPN your IP is already visible to every site you load, so WebRTC exposes nothing new. This test is most meaningful when you're relying on a tunnel to hide that address.
Why was the test inconclusive?
Your browser returned no usable ICE candidates — usually because WebRTC is disabled, an extension interferes, or a firewall blocks STUN. That's not a verdict either way: with WebRTC fully disabled there is nothing to leak, but we only report what we actually measured.
Keep checking
WebRTC is one path. These cover the others: