What is a WebRTC leak?

What WebRTC is for

WebRTC is the browser technology behind video calls, voice chat, and screen sharing that work directly in a browser tab, no plugin or separate app required. Google Meet, Discord's browser version, and WhatsApp Web all run on it. Its entire reason for existing is to let two browsers talk to each other as directly as possible, because routing every frame of a video call through a distant server adds delay that makes conversation feel laggy and unnatural.

"As directly as possible" is the part that matters here. To connect two devices directly, each one first has to work out its own network address and share it with the other side — and that discovery process happens automatically, in the background, the moment a page asks for it.

Why it needs your real IP address

Finding the most direct path between two devices is handled by a protocol called ICE (Interactive Connectivity Establishment), and it works by gathering a list of every possible address your device might be reachable at, called candidates, then trying them in order of preference until something connects. There are three kinds.

Local candidate

Your device's private address on its own network, something like 192.168.1.14. Useful if the other person happens to be on the same network, like a colleague on the same office Wi-Fi — in that case the call can connect directly with zero internet involved at all.

Server reflexive candidate

Obtained by asking a STUN server, a small, simple server whose only job is to tell your device what public IP address it's being seen from. This is how WebRTC learns your actual public-facing IP, and it's the candidate at the center of most WebRTC leak reports, because a STUN request happens automatically without ever showing you a permission prompt.

Relay candidate

If a direct connection genuinely can't be established, usually because of restrictive network firewalls on one or both ends, the call falls back to a TURN server that relays the traffic between both sides. This is the slowest option and the one WebRTC tries hardest to avoid.

How this becomes a leak through a VPN

A VPN's entire job is to make your traffic look like it's coming from the VPN server's IP address instead of your own. That works cleanly for ordinary web browsing, where every request goes through the browser's normal networking stack, which the VPN can fully intercept and reroute.

STUN requests don't always play by those rules. They're typically sent over UDP, and depending on how a given VPN client is built, it may only reliably capture and reroute certain kinds of traffic through its tunnel, leaving some UDP flows — including the ones WebRTC generates for address discovery — to go out over your normal network interface instead. When that happens, the STUN server that WebRTC contacted answers with your real, ISP-assigned public IP address, not your VPN's exit IP, and the page that requested it now has both addresses sitting right next to each other.

This isn't a flaw in WebRTC doing something it shouldn't. It's doing exactly what it's specified to do. The gap is that VPN software and browser networking were built by different people solving different problems, and STUN traffic has historically been one of the places that gap shows up.

What actually gets exposed

Two pieces of information, and they matter differently. Your local IP address on its own reveals almost nothing to a website across the internet — it's only meaningful to devices on your own network. Your public IP address, obtained through the STUN request, is the one that actually defeats a VPN, because it's the same real-world identifier your VPN exists specifically to hide. If a site can read a public IP through WebRTC that doesn't match the IP your browser otherwise appears to be using, that mismatch is the leak, in exactly as many words as a leak-test tool would report it — the same kind of address/identity mismatch that shows up in a DNS leak, just at a different layer.

How browsers handle it differently

This has genuinely improved since WebRTC leaks first became a widely known issue, and the current state is worth knowing rather than assuming it's unchanged.

Chrome, Edge, and other Chromium browsers

Since 2020, Chromium-based browsers hide the local candidate behind a randomized, meaningless hostname ending in .local instead of exposing your raw private IP directly, resolved through mDNS only on networks that support it. This closes off the local-IP exposure specifically, but it does nothing about the public IP obtained via STUN, which is the one that actually matters against a VPN. Chrome also removed the ability to fully disable WebRTC through browser flags years ago, so blocking it now genuinely requires an extension.

Firefox

Firefox applies the same mDNS obfuscation to local candidates, but is the one major browser that still exposes a real, user-facing setting (media.peerconnection.enabled in about:config) to disable WebRTC outright, no extension needed — at the cost of breaking any site that depends on it for calls.

Safari

Safari's WebRTC implementation also uses mDNS for local candidates and doesn't offer a simple built-in toggle to disable the feature entirely; managing it typically means going through content-blocker extensions rather than a native setting.

Testing it yourself

The mDNS change means the classic advice to "check for a private IP starting with 192.168" is outdated on a modern browser — you won't see one, and that doesn't mean you're safe. What actually matters is comparing the public IP a WebRTC leak test reports against the IP your VPN is supposed to be showing. Run our WebRTC leak test with your VPN connected, and check whether the address it finds matches your VPN's exit IP or your real one. For a broader check across DNS, IP, and WebRTC at once, our full privacy scan covers all three in a single pass.

Fixing it

A handful of VPN providers now advertise built-in WebRTC leak protection, which typically means they intercept and route STUN traffic through the tunnel specifically rather than relying on general-purpose routing to catch it — worth checking for by name rather than assuming any VPN handles it. Short of that, a browser extension that blocks WebRTC from making any connection at all is the most reliable fix on Chrome or Safari, and Firefox users can flip the media.peerconnection.enabled setting directly. Either approach will break video or voice calling on any site that depends on WebRTC, which is the real trade-off: the fix for the leak is disabling the exact feature that was leaking, not a way to keep using it safely.

Frequently asked questions

Does every VPN have this problem?

No, but it's inconsistent enough to be worth checking rather than assuming. Whether a given VPN catches WebRTC's STUN traffic depends on:

• Built-in WebRTC leak protection — whether the app specifically built it in, rather than relying on general system-wide routing
• Protocol and UDP capture — which protocol the VPN uses and how completely it captures UDP traffic
• IPv6 handling — whether IPv6 is involved, since a VPN that only tunnels IPv4 can leave an entirely separate path open

If my local IP is hidden behind mDNS now, does that mean I'm not leaking?

Not necessarily. mDNS obfuscation only hides the local network candidate. The public IP obtained through a STUN request is unaffected by it and is the one that actually reveals your real address to a website, VPN or not.

Will disabling WebRTC break anything I use regularly?

Yes, potentially. Any site that runs voice or video calls in the browser rather than a separate app — Google Meet, Discord's web client, WhatsApp Web calling — depends on WebRTC directly and will stop working if it's blocked entirely.

Sources

• W3C — WebRTC 1.0 specification
• RFC 8445 — Interactive Connectivity Establishment (ICE)
• RFC 5389 — Session Traversal Utilities for NAT (STUN)
• MDN — mDNS-based ICE candidate obfuscation