WebRTC Leak Test

WebRTC Leak Test

The test runs as soon as the page opens. It compares two things: the address this site sees your connection coming from, and the addresses your browser reveals through WebRTC. If WebRTC shows a public address the site doesn’t otherwise see, that’s a leak. You get one of five verdicts, every address WebRTC offered, and, if there’s a leak, how to fix it. Run again repeats the test, for instance after switching your VPN on.

The comparison happens in your browser, and nothing is stored.

What WebRTC is, and how it leaks

WebRTC lets browsers talk to each other directly, for video calls, voice chat and screen sharing. To set up a direct connection, the browser needs to know its own public address. So it asks a STUN server, “which address do you see me from?”, and hands the answer to the web page.

That’s harmless when you’re not hiding anything, since every site already sees your address. It becomes a leak when you’re on a VPN that doesn’t carry WebRTC’s traffic. The browser asks the STUN server outside the VPN tunnel, the server sees your real address, and the page learns it, even though everything else you do goes through the VPN.

The test asks public STUN servers run by Google and Cloudflare. They learn your address the same way any server you connect to does.

The five verdicts

The amber verdict is a warning rather than a conclusion, because two very different situations look the same from here. Either your VPN carries only IPv4 and your real IPv6 address is leaking, or the site’s own IPv6 check was blocked along the way. If you’re on a VPN and see amber, treat it as a leak until you’ve ruled it out.

Example: no leak

A home connection without a VPN:

What this site sees: IPv4 203.0.113.42; IPv6 not present. The IPv4 address belongs to the home provider.

What WebRTC reveals: IPv4 203.0.113.42; IPv6 none; hidden behind mDNS names: 3f6c1d2e-8b7a-4c55-9e21-0d4f7a9b6c13.local.

Verdict: no leak. WebRTC shows the same address this site sees. The STUN server saw the address your connection arrives from anyway, so WebRTC gives sites nothing they didn’t already have.

What a leak looks like

Now the same person turns on a VPN whose server is at 198.51.100.7, and the VPN doesn’t protect WebRTC:

• What this site sees: 198.51.100.7, belonging to a hosting network.
• What WebRTC reveals: 203.0.113.42.

Verdict: leak (red). The page names both addresses: the VPN’s, which the site sees, and the real one, which WebRTC gave away.

If instead the VPN covers IPv4 properly but the home connection also has IPv6, WebRTC may reveal something like 2001:db8:4f2a:9900:1c3e:5a7f:2b9d:6e41 while the site saw no IPv6 at all. That gives the amber verdict.

Reading the candidate table

Every address the browser offered appears in the table as a “candidate”, labelled by type:

• host: an address on your own device. Today browsers usually hide it behind a random .local name (more on that below).
• server reflexive: your public address as the STUN server saw it. This is the one that matters for leaks.
• peer reflexive: an address discovered while talking to the other side of a connection.
• relay: an address on a relay (TURN) server that forwards traffic when a direct connection isn’t possible.

Addresses that only work inside a network are listed as local addresses, not counted as leaks. That covers home ranges like 192.168.x.x and 10.x.x.x, carrier-grade NAT addresses (100.64.0.0 to 100.127.255.255), and link-local IPv6 addresses starting with fe80:.

Hidden addresses are .local names like the one in the example. Modern browsers replace your device’s local addresses with a random name, so sites can’t map your home network. That’s the default in current Chrome, Edge, Firefox and Safari. A site you’ve given camera or microphone access to may be shown the real local addresses, because calls work better with them.

How IPv6 addresses are compared

The same IPv6 address can be written several ways, with or without leading zeros, and with :: in different places. Before comparing, the tool writes every address in the standard short form (RFC 5952), so spelling differences don’t count as a mismatch.

It also treats addresses in the same /64 block as the same connection. The first half of an IPv6 address identifies your home connection. The second half is chosen by the device and changes regularly for privacy, so a device can easily use one address for the page and another for WebRTC. Counting that as a leak would be a false alarm.

When it’s a VPN leak, not a WebRTC leak

Sometimes the site itself sees two addresses, an IPv4 and an IPv6, and the one it mainly uses belongs to a hosting or VPN network. The other one, then, isn’t going through the VPN at all. Every site you visit can see it, with or without WebRTC.

The page points this out, because the fix is different: it’s the VPN’s settings, not the browser’s. Check whose network the other address belongs to with ASN Lookup. If it’s your home provider, your VPN isn’t carrying that kind of traffic.

How to fix a leak

When the test finds a leak, it lists the fixes that apply:

• Your VPN’s WebRTC protection. Many VPN apps and browser extensions have a setting for it, often off by default.
• uBlock Origin: in its settings, turn on “Prevent WebRTC from leaking local IP addresses”.
• Firefox: in about:config, set media.peerconnection.enabled to false. This switches WebRTC off entirely.
• Brave: under privacy settings, set the WebRTC IP handling policy to “Disable non-proxied UDP”.
• Chrome and Edge: there’s no built-in setting, so use an extension that limits WebRTC, such as Google’s own WebRTC Network Limiter.
• If only IPv6 leaks, switching off IPv6 on your network adapter (or in the router) closes the gap, if your VPN can’t carry IPv6.

Then click Run again with the VPN on, and look for a green verdict.

How to test properly

The test only tells you something useful when you’re trying to hide your address:

1. With the VPN off, open the page and note your real address under What this site sees.
2. Turn the VPN on and click Run again.
3. The site should now see the VPN’s address, and WebRTC should show either the same address or none.

WebRTC is one of several ways a VPN can leak. DNS Leak Tester checks whether your DNS lookups still go to your own provider. What’s My IP shows both your IPv4 and IPv6 addresses, and whether they look like a VPN.

FAQ

Is it a leak if I’m not using a VPN?

No. Without a VPN or proxy, every site already sees your public address, and WebRTC showing the same one changes nothing. The green “same address” verdict is the normal result.

Should I switch WebRTC off completely?

Only if you don’t need it. Video calls and screen sharing in the browser rely on it (Google Meet and the web versions of Teams and Discord, for instance). Limiting it to the VPN, through the VPN’s protection, uBlock Origin or Brave’s policy, keeps calls working while stopping the leak.

Does private or incognito mode help?

No. WebRTC works the same way in private windows.

Why did the test contact Google and Cloudflare?

WebRTC needs a STUN server to learn which public address you’re seen from. The test uses public ones run by Google and Cloudflare. They see your address only as any server you connect to does, and they get nothing else from the test.

What are the long .local names?

They’re your browser hiding your device’s local addresses behind random names, so sites can’t read your network layout. It’s the modern default and nothing to fix.