Summarise this article with:
What WebRTC Is and Why Every Browser Ships It
WebRTC (Web Real-Time Communication) is a peer-to-peer protocol built directly into every major browser, allowing video calls, voice chat, and file sharing without plugins or third-party software. Google open-sourced the technology in 2011 and led standardization at the W3C and IETF alongside Mozilla, Microsoft, Cisco, and Ericsson. The W3C formally ratified it as a Recommendation in January 2021.
When you join a Google Meet call or use Discord's browser-based voice chat, WebRTC is the engine underneath. The problem is not what WebRTC does. The problem is one specific part of how it discovers your network: a process that can expose your real IP address to any website, silently, even while you are connected to a VPN.
The ICE Process: How Browsers Find a Path to Connect
To establish a peer connection, WebRTC runs a protocol called ICE (Interactive Connectivity Establishment). ICE's job is to find every possible network path between two devices and pick the best one. It does this by gathering what are called ICE candidates, which are essentially network address and port pairs your device can be reached at.
ICE gathers four types of candidates:
- Host candidates: your device's private IP addresses (e.g., 192.168.1.105), pulled directly from local network interfaces
- Server reflexive candidates (srflx): your public IP as seen from outside your NAT, discovered by contacting a STUN server
- Peer reflexive candidates (prflx): addresses discovered during connectivity checks between peers
- Relay candidates: addresses provided by a TURN server, used as a last resort when direct paths fail
The STUN step is where leaks happen.
The STUN Request: Simple Protocol, Serious Consequence
STUN (Session Traversal Utilities for NAT, defined in RFC 5389) is a lightweight request-response protocol with one core job: tell your browser what its public IP address looks like from the outside internet. Your browser sends a Binding Request UDP packet to a STUN server, and the server echoes back the source IP and port it received the packet from. That reflected address is your server reflexive candidate.
This is necessary for WebRTC to work. Two users sitting behind separate NAT routers both need to know their external addresses before they can attempt a direct connection. STUN makes that possible with a handful of bytes exchanged with a public server.
The problem: STUN requests travel over UDP, and they bypass the VPN tunnel for many users.
Why VPNs Fail to Block It
The mechanism differs by VPN type.
Browser-extension VPNs are proxies, not tunnels. They intercept HTTP and HTTPS traffic at the application layer. UDP packets, including WebRTC STUN requests, are never handed to the proxy at all. They leave your machine via your real network interface, hit the STUN server, and return your real public IP.
System-level VPN clients (those that install a virtual network adapter and capture OS-level traffic) are more resilient. They route UDP correctly in most cases. But they can still miss WebRTC traffic when:
- IPv6 is not tunneled. Many VPNs route IPv4 through the tunnel but leave IPv6 traffic on your real interface. If your ISP assigns you an IPv6 address, WebRTC's ICE gathering will discover and report it.
- A second network interface is uncaptured. If your machine has both Wi-Fi and Ethernet active, or a virtual adapter from another application, ICE may gather candidates from the uncaptured interface.
- Split tunneling excludes browser traffic. Some VPN configurations deliberately route only certain destinations through the tunnel.
What a Website Learns From Your ICE Candidates
Any website can trigger ICE gathering with roughly 15 lines of JavaScript using the RTCPeerConnection API. The site does not need to complete a call or establish any real connection. It simply creates a peer connection object, listens for icecandidate events as they fire, and reads the address out of each candidate string.
There is no browser permission prompt. No indicator in the URL bar. No notification of any kind.
The information that comes back can include:
- Your real public IPv4 address from your ISP, even if your VPN hides it everywhere else
- Your real public IPv6 address (IPv6 leaks through WebRTC are especially common because many VPNs do not tunnel IPv6 at all)
- Your local private IP address from your router's DHCP pool
With your real public IP, a site can geolocate you to city level, identify your ISP, and correlate your visits across sessions without cookies. Your VPN's IP may appear in your regular HTTP requests, but WebRTC can hand the site your actual address in the same page load.
In my testing with a browser-extension VPN enabled, the RTCPeerConnection STUN path returned the real ISP IP consistently while the browser's own IP-check pages showed the VPN IP. The two addresses in the same session are the fingerprint of the leak.
Why This Is Different From Other Privacy Leaks
Most browser privacy issues involve what you send in requests: cookies, headers, referrers. WebRTC leaks are different because the leak is generated by the browser itself in response to a browser API call, not by forwarding your traffic.
You can block all third-party cookies, strip referrer headers, and use HTTPS everywhere. None of that stops a page from calling new RTCPeerConnection() and listening to the ICE candidates your browser generates. The mechanism is built into the browser's networking stack at a level below HTTP.
This also makes it invisible in network monitors that only capture HTTP/S. A STUN request over UDP on port 3478 is easy to miss if you are not specifically looking for it. See our DNS leak test for a parallel example of how protocol-level bypasses work at a different layer.
How WebRTC Also Expands Your Browser Fingerprint
Even when no IP is leaked, WebRTC contributes to browser fingerprinting in ways most users do not expect. The types of media devices available (microphones, cameras), the codecs your browser supports for audio and video, and the network interface count all add data points to your fingerprint. Our browser fingerprint tool can show you how many of these signals your browser currently exposes.
Testing for a WebRTC Leak
Before configuring any fix, verify whether you are actually affected. The steps are:
- Connect to your VPN and confirm it shows as active
- Note your VPN's server IP (usually visible in the VPN app)
- Run the VPN leak test, which checks for WebRTC, DNS, and IP leaks together
- If the WebRTC section shows an IP that does not match your VPN server and instead matches what you see at My IP without the VPN, you have a confirmed WebRTC leak
Test again after any browser update. Major version updates can reset browser privacy settings, and the behavior of how browsers handle ICE candidate gathering changes between releases.
How to Fix the Leak
Fixes range from browser-specific settings (Firefox's about:config, Brave's built-in policy, Edge's flags) to VPN browser extensions with explicit WebRTC protection. The full browser-by-browser walkthrough, including how to preserve video-call functionality while blocking the leak, is in our companion post: How to Fix WebRTC Leaks in Every Browser.
If you want to understand whether your current VPN handles this at all, the VPN leak test gives you a direct answer without any configuration changes first.
Frequently Asked Questions
Does a VPN always protect against WebRTC leaks?
No. Whether a VPN blocks WebRTC leaks depends on its architecture. Browser-extension VPNs are HTTP/S proxies and do not route UDP traffic at all, so WebRTC STUN requests bypass them entirely. System-level VPN clients route UDP through the tunnel in most configurations, but they can still miss IPv6 traffic if IPv6 tunneling is not enabled, or fail when a second network interface is present. Always verify with a VPN leak test rather than assuming protection.
What is a STUN server and why does my browser contact one?
A STUN (Session Traversal Utilities for NAT) server is a public network endpoint defined in RFC 5389. When your browser runs WebRTC, it contacts a STUN server to discover what your public IP address looks like from the outside internet, because your device's local IP is hidden behind your router's NAT. The STUN server simply echoes back the IP and port it received your request from. This server reflexive address is then included in your ICE candidates and shared with the other peer. The process is necessary for peer-to-peer connections to work across NAT boundaries.
Why are IPv6 WebRTC leaks so common?
Many VPN services tunnel IPv4 traffic correctly but leave IPv6 traffic on your real network interface. If your ISP assigns you an IPv6 address (which is increasingly common), WebRTC's ICE process will discover it as a host candidate and include it in the candidate list. A website receiving that candidate gets your real IPv6 address even if your IPv4 address is hidden behind the VPN's server. The fix is either enabling IPv6 tunneling in your VPN settings or disabling IPv6 at the OS level if you do not need it. You can also check your current IP status at My IP to see whether your ISP has assigned you an IPv6 address.
Can websites trigger WebRTC candidate gathering without my knowledge?
Yes. The RTCPeerConnection JavaScript API is available to any page without user permission. A site can create a peer connection, pass no STUN configuration or use a public STUN server, and listen for icecandidate events as they fire. Each event carries a candidate string containing an IP address. The site does not need to complete a call. No browser alert is shown. No indicator appears. The entire process can happen in a hidden script within a fraction of a second of the page loading.
Will fixing WebRTC leaks break video calls?
It depends on the method. Fully disabling WebRTC in the browser (for example, via Firefox's media.peerconnection.enabled) will break browser-based video calls on Google Meet, Discord, and similar services. More targeted approaches, such as limiting ICE candidates to the default network interface or routing WebRTC through the VPN tunnel, can block the leak while preserving video call functionality. The right trade-off depends on how often you use browser-based video calls. The detailed options are covered in How to Fix WebRTC Leaks in Every Browser.
Sources
WhatIsMyLocation Team
Our team of network engineers and web developers builds and maintains 25+ free networking and location tools used by thousands of users every month. Every article is reviewed for technical accuracy using real-world testing with our own tools.
Related Articles
Try Our Location Tools
Find your IP address, GPS coordinates, and more with our free tools.