What is a WebRTC leak?
A WebRTC leak happens when your browser's real-time communication feature reveals your actual IP address to a website while a VPN or proxy is supposed to be hiding it. No permission prompt appears.
WebRTC is the browser technology behind video calls, screen sharing and peer-to-peer file transfer in the browser. To connect two people directly, each browser has to work out which addresses it can be reached on. It asks a STUN server (Session Traversal Utilities for NAT, defined in RFC 8489) "what IP do you see me coming from?" and hands the answers, called ICE candidates, to the page.
That is the whole problem. A VPN browser extension is usually a proxy for web requests. WebRTC traffic is UDP, and unless the browser is told otherwise it can go straight out of your normal connection. The STUN server then reports your real public IP, and the page can read it.
The kind of IP leak WebRTC causes is quiet: pages load through the VPN and the website still ends up with both addresses. Run a WebRTC leak test whenever you change VPN, browser or extension.
How this WebRTC leak test works
The test does what a tracking script would do, then shows you the result. It opens a WebRTC connection with no camera or microphone, collects every candidate address, and compares them with the IP address this site receives over normal HTTP.
- It creates an
RTCPeerConnectionpointed at two public STUN servers:stun.l.google.com:19302andstun.cloudflare.com:3478. - It opens a data channel and creates an offer, which makes the browser start gathering ICE candidates.
- It waits until gathering completes, or 6 seconds, whichever comes first.
- At the same time it requests
/cdn-cgi/tracefrom this site. Cloudflare answers with the IP your HTTP request came from. - It sorts each candidate into host, server-reflexive or relay, checks whether each address is public, private or hidden, and applies the verdict rules below.
| Type | Where the address comes from | Privacy meaning |
|---|---|---|
| host | A network interface on your device | Should be a random .local name. A raw 192.168.x.x or 10.x.x.x is a local IP exposure. |
| srflx (server-reflexive) | What the STUN server saw as your public IP | Should match the IP websites see. If it differs while a VPN is on, you have a leak. |
| relay | A TURN relay server | Not requested here, so normally absent. It would show the relay's IP, not yours. |
The verdict rules are simple and strict. No leak: every public IP from WebRTC matches your HTTP IP and no raw local IP appears. Possible leak: WebRTC shows a public IP that differs from the HTTP one, or shows a raw private IP. WebRTC blocked: the browser has no RTCPeerConnection or gathers no candidates at all, which is the safest result.
How to read your WebRTC leak check results
Check the badge, then the three boxes. If the HTTP and WebRTC public IPs match and the local IP says hidden or none, you're fine.
- No leak
- WebRTC only revealed the same public IP websites already see, and local addresses were hidden behind mDNS
.localnames. Your VPN is doing its job for WebRTC. - WebRTC blocked
- Your browser, a policy or an extension stopped WebRTC from gathering addresses. Nothing can leak. Browser video calls may not work until you allow it.
- Possible leak: different public IP
- WebRTC reported a public IP that is not the one your web traffic uses. With a VPN on, that is almost always your real IP. Fix it with the steps below.
- Possible leak: raw local IP
- WebRTC listed a private address like
192.168.1.23. It doesn't show your location, but it adds detail to a browser fingerprint. - Can't compare
- The page couldn't read your HTTP IP, usually because a strict blocker stopped the request. Compare the WebRTC IP with your VPN app's IP by hand.
Does a VPN stop WebRTC leaks?
A full VPN app usually does; a VPN browser extension often doesn't on its own. The difference is what each one actually routes.
- VPN app (system-wide): it routes all of the device's traffic, UDP included, through the tunnel. The STUN server sees the VPN's IP, so WebRTC reveals nothing new. Gaps appear with IPv6 that the VPN doesn't carry, split tunnelling, or a dropped connection with no kill switch.
- VPN or proxy extension: it changes how Chrome sends web requests. WebRTC's UDP traffic can go around it unless the extension also changes Chrome's WebRTC setting. Good VPN extensions do this; check before you trust one.
So the honest answer is: run a WebRTC leak test with your exact setup. Browse our VPN Chrome extensions guide if you want an extension that handles this for you, and look for "WebRTC protection" or "leak protection" in its feature list.
WebRTC leak prevention: how to fix a leak
WebRTC leak prevention means telling the browser to keep WebRTC on the same path as your web traffic, or to switch it off. The option you have depends on the browser.
| Browser | Built-in option | What to do |
|---|---|---|
| Chrome | No user-facing switch | Install an extension that sets Chrome's WebRTC IP handling policy, or use the WebRtcIPHandling enterprise policy on managed devices. |
| Edge | No user-facing switch | Same Chromium engine: use an extension from the Chrome Web Store or Edge Add-ons. |
| Brave | Yes, in privacy settings | Set the WebRTC IP handling policy to one of the stricter options. |
| Firefox | Yes, in about:config | Set media.peerconnection.enabled to false to turn WebRTC off completely. |
How to disable WebRTC in Chrome
Chrome has no settings page toggle for WebRTC, so you can't fully disable it without help. Extensions can change it through the chrome.privacy.network.webRTCIPHandlingPolicy setting, available since Chrome 48. That needs the privacy permission. The four values are:
default all interfaces, normal behaviour
default_public_and_private_interfaces public + private, default route only
default_public_interface_only only the interface web traffic uses
disable_non_proxied_udp no UDP outside the proxy (strictest)default_public_interface_only keeps video calls working while hiding other interfaces. disable_non_proxied_udp is the strongest choice with a proxy-style VPN extension: WebRTC goes through the proxy or not at all.
Choosing a WebRTC leak prevent Chrome extension
A WebRTC leak prevent Chrome extension is a small add-on whose only job is to set Chrome's WebRTC IP handling policy for you. Names vary; a "WebRTC Leak Shield" or "WebRTC Control" style extension does the same thing with a different switch.
Because the job is so narrow, the checklist is short:
- Permissions: it should need the
privacypermission and little else. An extension that also asks to read every site you visit (see what "all URLs" access means) needs a very good reason. - Policy choice: it should let you pick
disable_non_proxied_udpordefault_public_interface_only, not just "on". - Maintenance: recent updates and a named developer.
- Proof: run this WebRTC leak test with the extension on and off. If the result doesn't change, remove it.
If your VPN extension has built-in WebRTC protection, use that first. For more privacy tools, see the security and privacy category.
WebRTC leak test vs IP leak test vs DNS leak test
They check different paths out of your device. A WebRTC leak test checks one browser feature; an IP leak test checks the address websites see in general; a DNS leak test checks who answers your domain-name lookups. This page does not test DNS.
| Test | What it checks | Covered here? |
|---|---|---|
| WebRTC leak test | IPs your browser's WebRTC reveals to a page | Yes |
| IP leak test | The public IP your web traffic arrives from | Yes, shown as "IP over HTTP" |
| DNS leak test | Which DNS resolvers look up domains for you | No, use your VPN provider's DNS check |
A clean result here and a failed DNS leak test means sites can't see your real IP, but your internet provider may still see which domains you visit. Run both.
What this WebRTC leak checker can't tell you
This WebRTC leak checker reports what your browser reveals at the moment you run it, to a page with no camera or microphone access. A few cases are outside that view:
- Sites with camera or mic access: Chrome can expose raw local IPs to a page you've allowed to use your camera or microphone. Our test never asks for that permission.
- Other apps: desktop apps with their own WebRTC stack aren't covered by browser settings.
- Changing networks: switching Wi-Fi or a VPN reconnect can change the result. Test again after any change.
- Blocked STUN: if a firewall blocks UDP to STUN servers, you may see only host candidates. That's still a no-leak result for this browser on this network.
Want more detail about your setup? What's My Browser shows your exact Chrome version, the Ad Blocker Test checks your content blocker, and the Chrome Flags Explorer explains experimental settings.