← All articles  ·  Privacy  ·  11 min read  ·  Updated 2026-05-16

WebRTC Leaks: The Browser Flaw That Exposes Your Real IP Behind a VPN

WebRTC is one of the more impressive pieces of plumbing in a modern browser, and also one of the more awkward from a privacy standpoint. It powers Google Meet, Discord voice rooms, Whereby, Jitsi, and countless support-chat widgets without ever asking the user to install anything. To deliver that experience, it has to know the user's real network address. That requirement, built into the protocol itself, is the source of the WebRTC leak.

What WebRTC is and why browsers need it

WebRTC stands for Web Real-Time Communication. It is a collection of browser APIs that enable direct audio, video, and data channels between peers. The relevant standard is RFC 8445, which defines ICE (Interactive Connectivity Establishment): the algorithm browsers use to find a working path between two endpoints across the messy reality of NATs, firewalls, and asymmetric routes. Without ICE, the conversation between two browsers behind two home routers would never start.

ICE works by enumerating every plausible network address the browser could be reached on (local LAN IP, public IP after NAT, relay servers as a last resort) and trying them in priority order until one connects. That enumeration is the source of the leak: it inherently exposes addresses the user might not want exposed.

How STUN servers discover your real IP

To learn the public IP behind a NAT, the browser sends a UDP packet to a STUN (Session Traversal Utilities for NAT) server. Google operates several at stun.l.google.com:19302. The server replies with the source IP it saw, which is the public address the home router presents to the internet. The browser then includes that address as a candidate in the ICE list.

When a VPN is active, the route table normally sends all packets through the tunnel, so the STUN packet should travel through the VPN, hit Google from the VPN exit IP, and the returned address should be the VPN's address. That works for the public-IP discovery in most setups. The real leak comes from a separate ICE candidate: the local IP. WebRTC asks the OS network stack directly for the local interface address. The OS happily returns the address of the physical Wi-Fi or Ethernet adapter, not the VPN's virtual adapter, because the API call asks for "all interfaces". That local IP, combined with timing and other browser fingerprints, can deanonymize a session.

What a leaked IP actually reveals

A leaked public IP exposes the user's true country, region, and often city, as documented in IP geolocation accuracy ranges. A leaked local IP (something like 192.168.1.42) does not directly identify the home, but combined with other fingerprints it confirms the user is on a specific subnet, which a re-identification engine can correlate with previous visits. The IPv6 leak is the most identifying of the three because it ties one specific device to one specific user across the open web. For more on what any IP can reveal in isolation, see what your IP says about you.

How to test for a WebRTC leak

The cleanest test runs in the browser you actually use, with the VPN active:

1. Open browserleaks.com/webrtc in the target browser.
2. Scroll to the "Local IP Address" and "Public IP Address" rows.
3. If either matches your real ISP-assigned address (the one you get when the VPN is off), the leak is confirmed.
4. Cross-check on ipleak.net, which runs an independent ICE candidate enumeration.

The test takes seconds and is non-invasive. Repeat it after every browser update, because each major release shifts WebRTC defaults.

Fix per browser

The fixes differ because each browser handles WebRTC differently. A single VPN setting cannot solve this; the patch lives in the browser layer.

Brave deserves a paragraph

Brave handles WebRTC better than any mainstream Chromium fork. The "Disable Non-Proxied UDP" option keeps WebRTC functional but routes all candidate gathering through whatever proxy or VPN is active, so the leak disappears without losing video chat. Users who rely on web-based meetings every day get a clean compromise instead of a binary on-or-off switch. For a broader list of browser hardening steps, the EFF's tracking deep dive is the standard reference.

VPN-side mitigations

Some VPN providers ship browser extensions that override WebRTC's local-IP candidate selection. These extensions are convenient but only protect traffic from the browser they are installed in. They do not help a desktop app, a system service, or a separate browser that the user occasionally opens. The cleaner approach is to fix WebRTC at the browser level so the protection applies regardless of the VPN client state. For the underlying tunnel choices, see how a VPN tunnel actually works.

Common misconceptions

• "My VPN has a kill switch, so WebRTC is safe." The kill switch blocks traffic that tries to leave outside the tunnel. WebRTC's STUN packets travel through the tunnel and still return the VPN's public IP. The leak is the local-IP candidate, which never crosses the tunnel boundary at all. The kill switch cannot see it.
• "Incognito mode disables WebRTC." It does not. Incognito only suppresses local storage and history; the network APIs behave identically.
• "WebRTC only matters during video calls." Any website can instantiate an RTCPeerConnection object and gather ICE candidates silently in the background, without user permission and without a UI. Many ad networks do this for fingerprinting.
• "Disabling JavaScript fixes it." True but impractical; most modern sites do not function with JS off.

The bigger picture

WebRTC is one of several browser features that can betray a VPN user. Others include canvas fingerprinting, font enumeration, and audio-context fingerprinting. The cumulative profile a site can build from a single visit is detailed enough to re-identify a returning visitor even without a single tracking cookie. WebRTC is unusually serious because it leaks an explicit IP address rather than a derived statistical signature. Fixing it should be the first step in any browser hardening pass, before fingerprint mitigations. For a complementary cleanup, also work through how to seal DNS leaks, since the two are often present together.

One more practical note: any time a browser updates to a new major version, the WebRTC defaults can shift. The about:config flag, extension, or toggle should be re-verified after each update. A leak that appeared after months of safe browsing is almost always the result of a default that quietly flipped back during an auto-update. The test page bookmarked at the top of the browser solves this in under a minute.