Introduction
A WebRTC leak happens when a website learns your real IP address through the browser's WebRTC stack while your normal web traffic goes through a VPN or a proxy. The page itself loads from the VPN's address, so everything looks fine. Then a few lines of JavaScript ask the browser how it could be reached for a video call, and the answer contains the address your internet provider gave you.
In 2026 this happens less often than most leak-test pages suggest. Browsers stopped handing out local addresses years ago, and a properly configured full-tunnel VPN leaves nothing to leak. The leak that remains shows up with browser proxies, split tunnels and VPNs that ignore IPv6, and each of these has a specific setting that closes it.
What WebRTC Is, in One Paragraph
WebRTC is the browser API behind in-browser calls, screen sharing and peer-to-peer file transfer. To connect two browsers directly, it collects every way it might be reached and hands the list to the page. These are called ICE candidates, and there are three kinds. A host candidate is the address of a network interface on your machine, often a private one like 192.168.1.20. A server-reflexive candidate is your public address as seen from outside, which the browser learns by sending a small UDP request to a STUN server. A relay candidate is an address on a TURN server that forwards traffic when nothing else works. A page can start this collection without any permission prompt simply by opening a data channel, and that is how leak-test pages do it.
Where the Leak Comes From
Local addresses are mostly solved
Until 2019 any site could read the private address of every network interface you had. Chrome stopped this in version 76, and Firefox and Safari do the same today: host candidates carry a random name ending in .local, resolved through multicast DNS, instead of the real address. In Firefox the switch is media.peerconnection.ice.obfuscate_host_addresses, which is on by default. Safari goes further and offers no host candidates at all until a site has camera or microphone access.
Camera and microphone access is the exception. A site you have allowed to use them gets your real local addresses back, in Chrome and in Safari, because the browser treats that permission as a sign of trust. If a test reports a local address, the usual causes are an outdated browser, a changed setting, or a test run on a site that has media permission.
Your public address can still leak in three setups
The server-reflexive candidate is the one that matters, because it is a public address. Whether it is your real one depends on which network path the STUN request takes.
A browser proxy without a VPN. Proxy extensions and the proxy settings of the browser or the operating system cover HTTP and HTTPS. WebRTC sends its STUN request over UDP, directly, past the proxy. The page sees the proxy's address, while the STUN server sees your home address and reports it back to the page. This is the classic WebRTC leak.
A split tunnel. Many VPN apps let some programs or some kinds of traffic bypass the tunnel. If the browser is on the bypass list, or UDP is excluded, the STUN request leaves through your normal connection.
A VPN that only handles IPv4. If your provider gives you IPv6 and the VPN tunnels only IPv4, the browser can reach the STUN server over IPv6 outside the tunnel. The page loads over the VPN's IPv4 address, and WebRTC reports your real IPv6 address next to it.
With a full-tunnel VPN that carries all traffic, IPv4 and IPv6, TCP and UDP, the STUN server sees the VPN's exit address. WebRTC still reports a public address, but it is the one the website already has, so nothing new leaks.
Which traffic a proxy, a VPN or Tor carries in the first place, and who sees the rest, is laid out in VPN vs Proxy vs Tor.
What a Leak Exposes
A real public IP points to your provider, your approximate location and often your household. It also stays put when you switch VPN servers: the address the page sees changes, the WebRTC answer does not, and a site can use that to link your visits together. Anti-fraud checks compare the two addresses for consistency, so a mismatch also makes the connection look less trustworthy, much like a system clock that disagrees with your IP.
A local address reveals much less. It narrows down your device on a home network and adds a little to a browser fingerprint. It is worth fixing, but nobody learns who you are from 192.168.1.20.
How to Test for a WebRTC Leak
A useful test collects candidates the way a real site would and then compares them with the address the page was loaded from. Many test pages skip the comparison and only print a list of addresses. That list contains a public IP for almost everyone, including people on a full-tunnel VPN, so on its own it proves nothing.
The WebRTC card of the Privacy & Trust Index gathers candidates for a few seconds through a dedicated STUN server, drops the .local names, and sorts the rest into local and public addresses. It then compares every public address with your connection IP and returns one of five results:
| Result | What it means | What to do |
|---|---|---|
| Safe | WebRTC returned no address. It is disabled or blocked. | Nothing |
| Public IP match | The only public address WebRTC found is the one you are connected from. | Nothing. This is the normal result with a full-tunnel VPN or without any VPN. |
| Dual stack | A second public address appeared, IPv4 next to IPv6, and both belong to the same network. | Nothing. These are two addresses of one connection. |
| Local leak | Only a private address escaped. Your public IP stayed hidden. | Update the browser or check the settings below. Minor. |
| Leak detected | WebRTC found a public address that differs from your connection IP. | Apply the fix for your browser below. |
A public-address leak pulls the Privacy score down hard, while a local one costs only a little. The card prints the address it found, so you can check it by hand: look it up in the IP Geolocation tool. If it shows your home provider while the page shows your VPN, the leak is real.
How to Fix It
Turning WebRTC off always works, and it also breaks every call you make in the browser. A narrower setting is usually better. It keeps calls working and makes WebRTC use the same path as the rest of your traffic.
Chrome
Chrome has no switch for this on its settings page. The control is an enterprise policy, WebRtcIPHandling, supported since Chrome 91, with four values that map to the modes in RFC 8828:
defaultlets WebRTC use every network interface.default_public_and_private_interfaceslimits it to the interface that reaches the internet, private addresses allowed.default_public_interface_onlylimits it to that interface and drops private addresses.disable_non_proxied_udpsends WebRTC over TCP through your proxy and allows UDP only when the proxy supports it.
If you use a proxy, disable_non_proxied_udp is the value that closes the leak. For a split tunnel or an IPv6 problem, default_public_interface_only keeps WebRTC on the route your normal traffic takes. On a personal machine you can set the policy through the registry on Windows, a configuration profile on macOS, or a JSON file in /etc/opt/chrome/policies/managed/ on Linux. Open chrome://policy afterwards to confirm it is active. Extensions can set the same four values through Chrome's chrome.privacy.network.webRTCIPHandlingPolicy API, which is how WebRTC-blocking extensions work in Chrome.
Brave
Brave puts the same four options on its settings page. Open brave://settings/privacy, find WebRTC IP handling policy and choose Disable non-proxied UDP if you use a proxy, or Default public interface only otherwise.
Firefox
Firefox offers the most direct controls, in about:config:
media.peerconnection.ice.proxy_only_if_behind_proxyset totruesends WebRTC through the proxy whenever one is configured. This is the fix for proxy users.media.peerconnection.ice.default_address_onlyset totruekeeps WebRTC on the default route, which helps with split tunnels and IPv6 leaks.media.peerconnection.enabledset tofalseturns WebRTC off completely.
Leave media.peerconnection.ice.obfuscate_host_addresses at true. It is the setting that hides your local address.
Safari
Safari has no user setting to restrict or disable WebRTC, and it needs one less than other browsers, because it never offers host candidates to a site without camera or microphone access. The Develop menu has a WebRTC section with an option called Disable ICE Candidate Restrictions. It exists for developers testing calls and makes Safari less private, so leave it off. If Safari shows a public-address leak, the cause is the network setup, and the fix belongs in the VPN.
In the VPN
The cleanest fix is a VPN that carries everything. Check three things in its settings: that UDP traffic goes through the tunnel, that IPv6 is either tunneled or blocked, and that the browser is not on a split-tunnel bypass list. Then check your DNS leak posture as well, because DNS is another path that can slip past a VPN. The VPN test guide walks through all of these checks in one place, the kill switch included.
uBlock Origin used to have a setting called "Prevent WebRTC from leaking local IP addresses". It only ever covered local addresses, never the public one, and it was removed from the desktop versions once browsers began hiding local addresses themselves.
Sources
- RFC 8828: WebRTC IP Address Handling Requirements, IETF, January 2021.
- WebRtcIPHandling policy, Chrome Enterprise documentation.
- Private IP addresses exposed by WebRTC changing to mDNS hostnames, Chromium blink-dev announcement.
- A Closer Look Into WebRTC, WebKit blog.
What does your browser hand out right now?
Run the Privacy & Trust Index check and open the WebRTC card to see every address it found and how it compares with your connection.