WebRTC leak test

What a WebRTC leak is

WebRTC is the browser technology behind video calls, screen sharing and peer-to-peer file transfer on sites like Google Meet and Discord. To connect two people directly, the browser has to discover every address it could be reached at. It does this by sending a tiny request to a STUN server, which replies with the public address it saw the request come from. The browser then hands those addresses — called ICE candidates — to the web page's JavaScript.

That is useful for calls and a problem for privacy. Any page can start this process silently, without a permission prompt and without a camera or microphone. If the STUN request leaves your computer outside your VPN tunnel, the page learns the address your internet provider gave you, not the one your VPN shows. That is a WebRTC leak: the website sees two addresses, and one of them is the one you were trying to hide.

How to use it

1. Connect your VPN or proxy the way you normally browse, then open this page.
2. Wait for the result box at the top. The test starts by itself, and the Testing line is replaced by a one-line verdict with a short explanation.
3. In Addresses compared, set Your connection (HTTP) against Public IP via WebRTC. The STUN server used row shows which server answered your browser.
4. Look through the ICE candidates table. Type says where each candidate came from (host is your device, srflx is what the STUN server saw, relay is a TURN server), and Kind says whether the address is public, on your local network, behind carrier NAT or hidden behind a .local name.
5. After changing a browser setting or extension, press Run the test again. If you turned the VPN itself on or off, reload the page instead: the HTTP address is read once, when the page loads.

Run it once with the VPN off and note the address your provider gives you. That is the address that should never appear once the tunnel is up.

Use cases

• Vetting a VPN before you rely on it. With the tunnel up, the WebRTC public address should match the HTTP one or be missing entirely. A different address of the same family is the result to act on.
• Checking a proxy extension. Browser proxy extensions route ordinary page requests, but the STUN request is UDP and can go straight out through your provider unless the browser is told to block it.
• Finding an IPv6 gap. Some VPN setups tunnel IPv4 and leave IPv6 alone. The verdict then says that WebRTC also reveals your IPv6 address.
• Verifying a managed browser policy. IT staff who restrict WebRTC on company laptops can open the page on a test machine and confirm the candidates table shows only what the policy should allow.
• Debugging a WebRTC app on a strict network. If the table lists host candidates but no srflx, UDP to the STUN server on port 3478 is probably blocked, and calls on that network will need a TURN relay.

How this test works

1. Your browser loads this page through your normal connection, so our server sees one public address — shown above as Your connection (HTTP).
2. The page creates a WebRTC connection that never calls anyone and asks Cloudflare's public STUN server (stun.cloudflare.com) which address it sees.
3. We list every candidate your browser produced and compare the public ones with the HTTP address. All of this happens in your browser; nothing is sent back to us.

Reading the result

• No leak: WebRTC reports the same public address as your connection, or none at all. If you use a VPN, it is covering WebRTC.
• Leak: WebRTC reports a different public address of the same type (IPv4 vs IPv4). With a VPN switched on, that second address is almost always your real one.
• Other protocol exposed: you connected over IPv6 and WebRTC also shows an IPv4 address, or the reverse. On a normal home connection both belong to you. With a VPN that only tunnels one protocol, the other one leaks.
• Local address visible: a 192.168.x.x or 10.x.x.x address means your browser is sharing your device's address on the home network. Current Chrome, Edge, Firefox and Safari hide it behind a random .local name by default.

How to stop a WebRTC leak

• Use your VPN's app, not only its browser extension. A system-wide VPN routes STUN traffic through the tunnel; a proxy extension often does not.
• Turn on WebRTC leak protection in your VPN app or extension if it has one.
• Firefox: open about:config and set media.peerconnection.enabled to false to switch WebRTC off entirely, or keep it on and rely on the VPN.
• Chrome and Edge: there is no built-in switch; use a reputable extension that sets the WebRTC IP handling policy to "disable non-proxied UDP".
• Brave: Settings → Privacy and security → WebRTC IP handling policy → "Disable non-proxied UDP".
• Safari: leaks are rare because Safari restricts ICE candidates by default.

After any change, run the test again. Remember that turning WebRTC off breaks browser-based calls, so prefer fixing the VPN over disabling the feature.

What this test cannot tell you

A clean result covers WebRTC only. Your DNS requests, your browser's time zone and language, and your fingerprint are separate channels; the home page checks the time zone and language mismatch and the fingerprint test covers the rest. We do not run a DNS leak test, because that needs a dedicated DNS server, and we would rather not pretend.

Frequently asked questions

This test checks one leak channel at the moment you run it. Results depend on your browser, extensions and network and can change when any of them change. It is not a security audit of your VPN.