What Is a WebRTC Leak and Why Does It Bypass Your VPN

Understanding WebRTC at a basic level

WebRTC (Web Real-Time Communication) is the set of browser APIs that enable real-time audio, video, and data communication between browsers without a server intermediary. It's what powers Google Meet, Zoom in the browser, peer-to-peer file transfer tools, and many gaming platforms.

For two browsers to communicate peer-to-peer, they need to know each other's actual network addresses. This is the feature that creates the privacy problem.

ICE candidates and STUN

The process WebRTC uses to discover network paths is called ICE (Interactive Connectivity Establishment). As part of ICE, the browser queries a STUN server (Session Traversal Utilities for NAT) — a public server whose only job is to tell you what your public IP address looks like from the outside internet.

The browser gathers "ICE candidates" — a list of possible network paths that could be used to establish a connection. These candidates include:

• Your local IP addresses (192.168.x.x, etc.)
• Your public IP address as reported by the STUN server
• "Relay" candidates via TURN servers if direct connection isn't possible

This ICE candidate list is accessible via JavaScript in the browser. Any webpage that runs the code — two dozen lines, freely available — can read your real public IP address directly from your browser's WebRTC implementation.

Why a VPN doesn't stop this by default

Most VPN clients work by routing your internet traffic through a VPN tunnel at the OS network layer. HTTP requests, DNS queries, and regular TCP/UDP traffic get routed through the tunnel and exit from the VPN server's IP.

But WebRTC's ICE gathering happens at the browser level and queries your network interfaces directly. Depending on how the VPN is configured and how the browser handles routing, this STUN query might go directly to the STUN server without going through the VPN tunnel.

The result: the STUN server sees your real IP (your ISP-assigned address) and reports it back to the browser. The browser includes it in the ICE candidates. JavaScript on the page reads the candidates. Your real IP is exposed — even though all your other traffic is going through the VPN.

This is a design consequence of how WebRTC works, not a flaw in any particular VPN. Most VPN providers have documentation about this and recommend using a browser-level fix.

Which browsers are affected

Chrome, Firefox, Edge, and Opera all support WebRTC and are affected. Safari's WebRTC implementation is more restrictive and has a less severe leak by default.

Can websites detect this automatically?

Yes. The JavaScript required to read ICE candidates and extract IP addresses from them is simple and runs silently in the background. Any site wanting to detect VPN users can run this code and compare the WebRTC-revealed IP with the connection IP. If they differ, the user is on a VPN.

Advertising platforms and content providers (streaming services enforcing geo-restrictions) actively use this technique.

Fixing it with WebRTC Privacy Shield

WebRTC Privacy Shield is a Chrome extension that intercepts the WebRTC ICE gathering process and prevents real IP addresses from being included in the candidates.

Install it from the Chrome Web Store. In the default configuration, the extension blocks the local IP addresses and real public IP from appearing in ICE candidates, while still allowing the VPN-routed IP through.

This means: WebRTC still works for video calls and peer-to-peer applications, but the IP addresses that appear in ICE candidates are only those routed through your VPN — not your real ones.

Conclusion

WebRTC leaks bypass VPNs because WebRTC's IP discovery is a browser-level process that routes around network-layer VPN tunneling. The fix has to be at the browser level too — which is exactly what WebRTC Privacy Shield provides.