WebRTC Leak Test
Checking for leaks…
What sites see
What WebRTC reveals
Gathering network paths and fetching your connection address, the same probe a tracking script would run.
Local network
stun · run 01 · probe runs locallyNetwork path log
Checking for leaks…
Gathering network paths and fetching your connection address, the same probe a tracking script would run.
Checking whether WebRTC leaks your IP.
Checking for leaks…
Gathering network paths and fetching your connection address, the same probe a tracking script would run.
How it works
The probe itself runs in your browser using the native WebRTC API, the same way a tracking script would run it.
We create a temporary RTCPeerConnection pointed at public STUN servers and open a dummy data channel. That starts the gathering process WebRTC uses to discover network paths.
Each candidate the browser emits carries an address. We record them live as they arrive and classify each one: public, private, or a masked .local name.
Separately, we fetch the address your connection shows websites. Every public address WebRTC surfaced is compared against it, with network data to tell a dual-stack second address apart from a genuine tunnel bypass.
What you get
A route map of how your traffic actually leaves this device, and everything WebRTC was willing to hand out.
Your browser path and your WebRTC path, drawn side by side. When the test finishes and both land on the same exit, nothing extra escaped.
Each WebRTC address is compared against your connection's exit address, and the verdict says only what was proven: leaked, safe, or couldn't verify.
The address websites see for your normal traffic. If WebRTC turns up something different, we read it again at the end of the test so a rotating proxy can't be mistaken for a leak.
Location, ISP and AS number for each public address we could look up, so you can see which network it belongs to.
Whether your browser masks your LAN address behind a random .local name or hands the real one to any script.
Every network path with its timing, type and protocol, exactly as a site running the same probe would receive it.
Change a setting and re-run. The tool tells you whether the exposure closed, opened or stayed the same.
Copy the full report as text or download the raw result as JSON for a bug report or an audit trail.
Go deeper
Not every address WebRTC reports is a problem. The verdict depends on what kind of address it is and which network it belongs to.
A server-reflexive (STUN) or public host candidate that does not match your connection's exit and does not share its network. If you are behind a proxy or VPN, this is the classic leak: the address the tunnel was supposed to hide.
An extra public address in your line's other address family (IPv6 next to IPv4) that resolves to the same AS number as your connection. That is how a dual-stack line looks, so it is flagged as a second address, not a leak. A same-family extra address never gets this benefit of the doubt, and an address whose network we couldn't check is reported as unverified rather than safe.
Modern browsers replace LAN addresses with a random mDNS hostname ending in .local, rotated by the browser. These are treated as protected: sites cannot turn them back into your real address. Browsers only stop masking on sites you have given camera or microphone access, so the test reads that permission to explain the result.
10.x, 172.16 to 172.31, 192.168.x, 169.254.x and IPv6 fe80/fc/fd addresses cannot identify you on the internet, but a raw one is still readable by scripts, which makes it a fingerprinting signal.
Reading the result
The headline states only what the probe measured. The detail cards under it carry the evidence.
WebRTC surfaced a public address your connection isn't using. If that address is your normal ISP line, WebRTC went around your proxy or VPN. The test reports what it saw rather than guessing whose address it is, because a rotating proxy can legitimately show two of its own exits.
The extra address belongs to your connection's own network and sits in your line's other address family: the other half of a dual-stack line. Not a tunnel bypass, but sites still see more of you than the connection shows.
Gathering finished and every public address WebRTC surfaced matches the address websites already see. Nothing extra escaped.
The probe finished and found no routable address, produced no candidates at all, or this browser has no WebRTC to call. Whatever the cause, a site running this probe learns nothing extra. A probe that merely failed to start is reported separately, because a failure is not the same as protection.
No public address escaped, but your browser handed out its address on your own network instead of masking it. Nobody can reach you at it, and any script can still read it as a way to recognise your device, so this isn't reported as a clean pass.
No public address escaped, but your browser handed out an address in the shared 100.64.0.0/10 range. That range is not your own network: mobile networks use it to share one public IP across many subscribers, and it is also Tailscale's range. Nobody can reach you at it, and a script can still read it as one more detail about your connection, so this isn't reported as a clean pass either.
When the network lookup fails, no STUN server answers, your exit address rotates mid-test, or a candidate arrives in a form we can't read, the tool says exactly that instead of guessing. Anything it couldn't check is treated with suspicion, never as safe. A run that ended early but had already found something reports the finding, and notes separately that there may be more it never saw.
A clean result reflects this browser, this session. Another browser or profile on the same machine can behave differently, and settings can reset after updates, so re-test after any change.
Why it matters
Fixes
If the test flags an address, close the gap and re-run to confirm.
Firefox: set media.peerconnection.enabled to false in about:config, which turns WebRTC off completely, browser calls included. Chrome has no settings toggle, but extensions can set its WebRTC policy so candidate gathering stays inside the proxy, and workplace-managed browsers can enforce the same policy.
The free Proxidize proxy extensions for Chrome and Firefox include WebRTC leak protection with a shield indicator, alongside full proxy management.
Some VPN clients include a WebRTC leak setting. Check your client's current documentation for one, turn it on if it exists, then re-run this test to confirm it works.
Browser updates, new profiles and extension changes can silently reset protections. The run-over-run badge here tells you immediately whether a change helped.
Privacy & security
The probe runs in your browser. The little we do send exists only to answer your question.
More tools
Other free Proxidize tools for checking how you appear online.
A leak-free IP is half the picture. See the browser signals sites combine into a cookie-free ID.
Full proxy manager for Chrome with built-in WebRTC leak protection.
The same proxy manager and WebRTC leak protection, built for Firefox.