WebRTC Leak: How a Browser Call Feature Reveals Your IP Past a VPN

Below: where to find services that use it in our rankings.

A WebRTC leak is when a page uses the browser's built-in real-time communication feature to pull the public address your provider issued you while the VPN is connected. The site itself sees the VPN server; a script on it sees your home connection. Because ordinary IP-checking pages read the site's request log rather than the browser's candidate list, this leak stays unnoticed for a long time.

Why browsers carry a calling engine at all

Browser-based meeting and chat services run on WebRTC (Web Real-Time Communication), APIs for voice, video, screen sharing and file transfer straight between two browsers, no plugin needed. For two peers to talk directly, each side works out all possible network paths. That job belongs to ICE, Interactive Connectivity Establishment: the browser gathers "candidates" and shares the list with the other side. The types it collects are: host, the address of a local interface; server-reflexive, the public address a STUN server sees the request coming from; relay, an address on a TURN server that forwards media when no direct path works.

A STUN server answers one question: which public address did this request come from. Public ones run by large companies are free and need no account. Many people assume WebRTC asks permission before revealing anything, and it does not: any page with JavaScript can create a peer connection and query STUN with no prompt and nothing on screen.

Four ways the real address gets past the tunnel

With a full-device VPN app, the STUN query rides inside the tunnel and the reflexive candidate shows the VPN exit. A leak with such an app points to one of these: WebRTC in a browser with a proxy extension not following the proxy settings by default, so its UDP request to STUN goes out over the normal connection; split tunnelling that leaves the browser outside; an IPv4-only tunnel on a network that also has IPv6; or a script firing while the tunnel reconnects.

The IETF defined how browsers should handle addresses in RFC 8828, WebRTC IP Address Handling Requirements. It lists four modes, from enumerating all addresses (only after consent, say camera permission) down to forcing everything through a proxy, and names split-tunnel VPN users as the case where both the VPN address and the provider address can be discovered.

What the ".local" names in a test mean

Modern Chrome, Edge, Firefox and Safari replace the private LAN address in host candidates with a random name ending in ".local" while the page has no camera or microphone permission. This masking covers the local address only; the public reflexive one is untouched. Safari exposes just the address used to reach the site unless you grant it media access.

Running the test

Connect the VPN, then open the VPNRadarLab VPN check tool, which shows the address websites see and runs a WebRTC leak test in the browser. Finding your home ISP's address among the results is a leak; seeing just the VPN exit, a ".local" name or a private range means the public side is safe. Repeat in every browser you use, on an IPv6-capable network, and right after the VPN reconnects.

Closing the leak

Where What to change What you lose
Firefox Set media.peerconnection.enabled to false in about:config Browser calls, screen sharing, some file transfer sites
Chrome, Edge Extension that sets the WebRTC IP handling policy (Google's WebRTC Network Limiter, or a block) Slower call setup or relayed media
Brave "WebRTC IP handling policy" in privacy settings Some calls get relayed
Opera "Disable non-proxied UDP" in privacy settings Some calls get relayed
VPN browser extension Its built-in WebRTC block, where offered Covers that browser only, not other apps
VPN app Full tunnel for all apps, IPv6 tunnelled or blocked, kill switch on Calls keep working, since the app does not change WebRTC itself

Disabling WebRTC entirely is the bluntest fix and breaks browser calls. Keeping it but limiting it to the default route preserves meetings at the cost of slower setup or relayed media.

What VPNRadarLab data shows

The main ranking of 377 services has no separate WebRTC field; the closest data point is browser extensions, where 99 services state they offer one, 2 partly, 47 say no and 229 do not state it (meaning the provider does not publish the information). The secure VPN ranking orders services by security checks such as leak protection, logging and audits.

FAQ

Can a WebRTC leak happen with a VPN app, not just an extension?

Yes. The usual causes are split tunnelling, an IPv4-only tunnel on a network with IPv6, or a script firing during a reconnect gap.

Does turning off WebRTC break video calls?

Browser calls and screen sharing stop working. Native meeting and chat apps are unaffected.

Is the local address in a test result a problem?

No. A ".local" name or a private range points only to a device inside the home network and does not identify you on the internet, so it is not a leak.

WebRTC leaks in brief

Any page can collect candidates without a prompt. A proper full-tunnel app returns the VPN exit address; proxy extensions, split tunnelling, open IPv6 and reconnect gaps return yours. Test each browser on a network with IPv6, then close the gap in browser settings, the extension or the app configuration.

Top services: Secure VPNs

  1. CitadelVPN9.05
  2. Proton VPN6.55
  3. IVPN6.20
  4. NordVPN5.97
  5. LunoVPN5.75

See the ranking: Secure VPNs

See also