What is WebRTC, and why can it leak your IP address?

Before WebRTC, a video call in a browser needed Flash or a downloaded plug-in. Google open-sourced the project in 2011 and the browser makers standardized it; WebRTC 1.0 became a W3C Recommendation in January 2021. Today every major browser ships it, and it is what runs underneath Google Meet, Discord's web client, browser-based support calls, remote-desktop web clients and sites that transfer files directly from one browser to another.

It has three parts that a site can use from JavaScript:

• Media capture (getUserMedia): the camera and microphone, always behind a permission prompt.
• Peer connections (RTCPeerConnection): a direct, encrypted link to another browser or a server.
• Data channels: arbitrary data over that same link, used for file sharing and multiplayer games.

Only the first part asks for permission; a page can open a peer connection silently.

Two browsers behind home routers cannot simply dial each other, so WebRTC uses a procedure called ICE to find every address that might work. It collects three kinds of "candidates":

1. Host candidates: the addresses of your own network interfaces, such as 192.168.1.23 on your Wi-Fi.
2. Server-reflexive candidates: your public address as seen from outside, learned by sending a small UDP packet to a STUN server, which replies with the address it saw.
3. Relay candidates: the address of a TURN relay server, used when nothing direct works.

The browser hands this list to the page's JavaScript so it can be sent to the other party, and nothing stops the page from logging it instead. No permission, no call and nothing on screen is needed: a hidden peer connection with a STUN server configured makes your browser report its public address within a second or two of the page loading.

Without a VPN this reveals nothing a site did not already know. The leak matters when you are hiding your address and WebRTC reports the real one anyway.

The WebRTC leak test opens a peer connection the same way a tracking script would and shows every candidate your browser produced. Read it like this:

Run it once without the VPN, then with it: the two public addresses must differ.

A VPN that is working correctly routes all traffic from your device through the tunnel, STUN packets included, and the STUN server then sees the VPN server's address. Leaks come from the cases where that is not true:

• Browser-extension "VPNs". Most are HTTP or SOCKS proxies that only carry the browser's web requests. WebRTC uses UDP sockets that bypass a proxy entirely, so the STUN request goes out over your ordinary connection. This is the most common cause.
• Split tunneling. If the browser is excluded from the tunnel, or the VPN app only covers certain apps, WebRTC traffic takes the physical route.
• IPv6 not covered. Many VPN apps tunnel IPv4 and ignore IPv6. If your ISP gives you native IPv6, the browser gathers an IPv6 server-reflexive candidate over the unprotected path. The IPv6 test tells you whether you have IPv6 at all.
• Tunnel drops and reconnects. During the gap, a page that is already open can gather new candidates on the bare connection unless the VPN has a kill switch.
• The VPN simply does not block it. Some apps advertise "WebRTC leak protection"; what they do is set the browser policy described below, or filter STUN packets. Others leave it to you.

You rarely need to switch WebRTC off entirely, which breaks browser calls. The useful setting tells the browser to use only the default route (the one the VPN controls) and to stop advertising other interfaces. All Chromium browsers share one policy with four levels: default, default_public_and_private_interfaces, default_public_interface_only and disable_non_proxied_udp. The last two hide local addresses; the last one also refuses to send UDP outside a proxy, which is the strongest option and still lets most calls work through a relay.

Chrome

Chrome has no settings-page toggle. Install Google's own WebRTC Network Limiter extension from the Chrome Web Store, then open its options page: the most restrictive choice disables non-proxied UDP (the store listing points out that this is not on by default, so installing alone does nothing). Managed devices can set the WebRtcIPHandling enterprise policy to disable_non_proxied_udp instead. There is no way to change this on Chrome for Android.

Firefox

1. Type about:config in the address bar and accept the warning.
2. Search for media.peerconnection.enabled and double-click it to set it to false. This disables WebRTC completely.
3. For a softer option, leave that alone and set media.peerconnection.ice.default_address_only to true, which uses only the default route, and keep media.peerconnection.ice.obfuscate_host_addresses at true so local addresses stay masked.

Firefox for Android does not expose about:config in the release build, so use the Disable WebRTC add-on there.

Safari

Safari masks local addresses with mDNS names and, since its first WebRTC release, has withheld host candidates from sites that do not have camera or microphone permission. There is no user setting to switch WebRTC off, and the WebRTC items in the Develop menu are debugging aids that should be left alone. The public-address part of the leak therefore depends entirely on whether your VPN covers the whole Mac or iPhone, which is where to look if the test shows your real address.

Edge

Edge uses the Chromium policy under the name WebRtcLocalhostIpHandling (values AllowPublicInterfaceOnly or DisableNonProxiedUdp hide the local address). Home users without group policy use the same Chrome Web Store extension; Edge installs Chrome extensions directly.

Brave

1. Open Settings and search for webrtc.
2. Under WebRTC IP handling policy, choose Disable non-proxied UDP.

On Brave for Android the setting is under Settings > Brave Shields & privacy > WebRTC IP handling policy. Brave switches to this mode automatically in private windows with Tor.

Only half of it. Since 2019 Chrome has replaced private addresses in host candidates with random names such as 1f2e3d4c-….local, resolvable only on your own network, and Firefox and Safari do the same. That stops a website from reading your LAN address, which was being used as a fingerprinting signal. The browsers make an exception for sites you have granted camera or microphone access, on the reasoning that you already trust them.

It does nothing about the server-reflexive candidate. Your public address is learned from the STUN server's reply, not from your network interfaces, so masking the interfaces does not hide it. If the STUN request leaves outside the VPN tunnel, the leak is there whether or not mDNS is on. The fix for the public address is always on the VPN side (full tunnel, IPv6 handled, kill switch) or on the browser side (disable_non_proxied_udp).

After changing anything, confirm it in this order:

1. Connect the VPN and note the address on the homepage IP check.
2. Run the WebRTC leak test. Every public candidate must match that address, and no IPv6 candidate may appear unless the VPN gives you one.
3. Run the full VPN leak test, which repeats the WebRTC check alongside DNS and IPv6, since a VPN that leaks one usually leaks another.
4. Open the browser fingerprint test. A blocked or limited WebRTC removes one identifying signal; it does not make you anonymous if everything else about your browser is unique.
5. Repeat after browser and VPN app updates, which reset settings more often than they should.