What is a WebRTC leak?
WebRTC lets browsers exchange audio, video and data directly with each other. To set up that direct connection, your browser asks a STUN server to work out how it appears from the outside, then shares the resulting network addresses — called ICE candidates — with the other side. Any website can perform the same trick without asking permission: it creates a peer connection, reads the candidates, and learns addresses your normal browsing traffic never exposes. If you use a VPN, the danger is specific. Your browsing goes through the VPN, so websites see the VPN exit address — but WebRTC may still report your real ISP address, quietly defeating the VPN for any site that bothers to look.
Reading the results: host, server-reflexive and relay
Each candidate has a type. A host candidate is an address assigned to one of your own network interfaces, usually a private LAN address such as 192.168.x.x. A server-reflexive (srflx) candidate is the public address a STUN server saw you come from — this is the one that matters for VPN users. A relay candidate comes from a TURN server that would forward your traffic; this test uses no TURN server, so relay candidates normally do not appear. Compare the srflx address with your browsing IP shown above: if they match, WebRTC sees the same public address as ordinary browsing. If they differ, WebRTC is revealing an address your browsing traffic does not — and if you are on a VPN, that second address is very likely your real one.
mDNS: why local addresses may look like gibberish
Modern browsers protect local addresses with mDNS obfuscation. Instead of a plain 192.168.1.5, a host candidate may appear as something like a1b2c3d4-1234-5678-9abc-def012345678.local. That random hostname cannot be resolved by the website, so your real LAN address stays hidden — this is the browser doing its job. Seeing .local names rather than raw private addresses is a good sign, not a failure of the test. If raw private addresses still show up, your browser is either old or has the protection disabled.
How to stop WebRTC leaks
In Firefox, type about:config in the address bar, search for media.peerconnection.enabled and set it to false. This disables WebRTC entirely, which also disables browser-based video calls. In Chrome, the official WebRTC Network Limiter extension offers a middle ground: it can force WebRTC traffic through the same proxy your browsing uses, or block non-proxied candidates, without breaking calls outright. Some VPN clients also offer a WebRTC leak protection setting that does the same job. Whichever route you choose, re-run this test afterwards to confirm the leak is gone.
Frequently asked questions
Is a host candidate with a private address a leak?
On its own, not necessarily a serious one: a private address such as 192.168.1.5 is not reachable from the internet and does not identify you by itself. The serious leak is a server-reflexive address that differs from your VPN exit address, because that exposes your real public IP.
Why does the test show no server-reflexive address?
Either the STUN server could not be reached from your network, or your browser or an extension blocked candidate gathering. Try again, and if the result repeats, check whether a VPN or firewall is filtering UDP traffic.
Does this test record my addresses?
No. Candidate gathering and parsing happen entirely in your browser. The only network request to our server is the optional browsing-IP lookup, which is handled like the IP checker and is not stored against the test.
Can I use this test on a phone?
Yes. Mobile browsers support WebRTC the same way, and the same leak applies. Run the test with the VPN on and off to compare what changes.
Related tools
- What Is My IP? — the address your browsing traffic uses
- DNS Leak Test — check which DNS servers your browser really uses
- DNS Lookup — inspect the records of any domain
- SSL Checker — verify the certificate on the server you connect to