What Is a WebRTC Leak

A WebRTC leak is the exposure of your IP address through the browser's real-time communication stack. WebRTC was designed to connect two devices directly, which requires each side to discover its own reachable addresses. That discovery happens automatically, and in some configurations it reveals addresses the rest of your privacy setup was meant to hide.

Why WebRTC can see your address at all

Direct peer-to-peer connections cannot rely on a central server, so the browser must find a path between two endpoints. The standard mechanism is ICE: the browser gathers candidate addresses, tests them, and picks a working pair. Gathering candidates means enumerating local interfaces and asking an external service what address the internet sees.

That external service is a STUN server. The browser sends a request, the STUN server replies with the source address it observed — your public address as seen from outside. This is legitimate and necessary. It is also the same mechanism that produces a leak when the observation does not match what you intended to expose.

The STUN exchange, step by step

1. JavaScript creates an RTCPeerConnection with an empty configuration.
2. The browser collects host candidates from local interfaces — LAN addresses, sometimes IPv6 link-local addresses.
3. The browser queries the configured STUN server and receives srflx candidates — the public address the server observed.
4. The page reads those candidates through the ICE callback.

Nothing in that sequence asks for permission. Historically, the addresses were readable by any page; modern browsers require at least one active media permission before exposing host candidates, which is why mDNS obfuscation and permission gating now matter.

What a leak looks like

Observed	Interpretation
Public IPv4 matching your expected exit	No leak. STUN reports what you intended.
Public IPv4 that is your real ISP address while a VPN is active	Leak. WebRTC traffic bypassed the tunnel.
Private address such as 192.168.x.x	Host candidate exposure. Reveals LAN structure, not your public identity — still a fingerprinting signal.
IPv6 address while your VPN is IPv4-only	Common leak. The IPv6 stack is unmanaged.
Random .local hostname instead of an address	mDNS obfuscation is working. This is the modern default and not a leak.
Nothing at all	WebRTC is disabled, blocked, or restricted by policy.

Why VPN users are the usual victims

A VPN routes IP traffic through a tunnel. WebRTC's candidate gathering can happen on interfaces the tunnel does not cover, particularly:

• the physical adapter, which still has a local address and can still reach a STUN server directly;
• IPv6, which many VPN clients do not tunnel;
• the STUN request itself, which is UDP and may follow a different routing rule than TCP page traffic.

The result is a page that loads through the VPN while the script reports the address of the connection underneath it. This is the classic "VPN is on but the test says my real IP" scenario.

Turning it off, per browser

• Firefox — media.peerconnection.enabled in about:config disables WebRTC entirely. Breakage is limited to actual video calls.
• Chrome and Chromium-based — no supported user-facing switch. Extensions can block the API, and enterprise policy can restrict it. Disabling via flags is unreliable across versions.
• Safari — restricts candidate gathering by default and requires user action for some cases; it is the least exposed of the major browsers.
• VPN clients — many offer a "block WebRTC" or "block IPv6" toggle. Verify by re-running the test rather than trusting the label.

mDNS: why local addresses stopped showing

Browsers now replace host candidates with a random xxx.local mDNS name unless the page holds a media permission. This hides LAN structure from arbitrary pages. It does not hide the public address gathered from STUN, which is the part that matters for VPN users.

FAQ

Is a WebRTC leak the same as a DNS leak?

No. DNS leaks expose which resolver saw your queries. WebRTC leaks expose addresses through the media stack. They are independent and both worth testing.

Does disabling WebRTC break video calls?

It breaks browser-based calling (Meet, Teams web, some WebRTC demos). Native apps are unaffected.

Why does the test show a private IP?

A host candidate escaped. It reveals your LAN range, not your public address, but it is still a distinguishing signal.

Can a VPN fix a WebRTC leak?

Only if it tunnels the interfaces and address families WebRTC uses. Many do not tunnel IPv6, which is the most common remaining leak.