Unprotected Your provider sees every site you open. Encrypt it →
← All posts

WebRTC Leak: How Your Browser Hands Out Your Real IP

The most common way a connected VPN still exposes you. Not a bug, not a broken tunnel - a video-calling feature doing exactly what it was designed to do.

WebRTC Leak: How Your Browser Hands Out Your Real IP
TL;DR
  • WebRTC lets browsers make direct peer-to-peer connections for calls. To do that it must discover your addresses - including the real one behind the VPN - and it asks the operating system directly, bypassing the tunnel.
  • Any page can start this discovery silently, with no permission prompt, no camera access and nothing visible on screen.
  • The exposure is your actual public IP alongside the VPN's, plus your local network address. Together those defeat the entire point of the tunnel for anyone correlating them.
  • Fixes differ by browser: Firefox has a real switch, Chrome needs an extension, Safari asks per site. Disabling WebRTC breaks browser-based calls, which is the trade.
  • Test after every browser update. WebRTC settings are reset by updates more often than any other privacy setting.

A DNS leak exposes which sites you visit. A WebRTC leak exposes you. It hands a web page your real public IP address while your VPN is connected and working correctly, and it does so without a permission prompt, without touching your camera, and without leaving any trace on the page you are looking at. If you have ever wondered how a site seemed to know your real location while you were behind a VPN, this is almost always the answer.

What WebRTC is for

WebRTC is the technology that lets browsers do real-time audio and video without plugins. Join a video call from a browser tab, use a web-based screen share, open a browser game with voice chat - that is WebRTC. It has been in every major browser for over a decade and it is genuinely useful.

Its defining feature is peer-to-peer connection. Rather than pushing your video through a central server, two browsers connect directly to each other, which is why browser calls have lower latency than they otherwise would. But a direct connection requires each side to know how to be reached, and that is where the privacy problem is born.

Why it needs your address, and how it gets it

To establish a direct connection, your browser gathers a list of possible routes to you, called ICE candidates. The list includes your local network address, your public address as seen from the internet, and relay addresses if a direct path fails. The browser then offers these candidates to the other side so it can pick a working one.

The critical detail: to build this list, the browser asks the operating system's networking stack directly and queries STUN servers to learn its public address. This runs beneath the layer where your VPN operates for ordinary web requests, which means the enumeration can see, and report, the real address behind the tunnel. WebRTC is not evading your VPN out of malice; it is doing the address discovery that peer-to-peer connection requires, and that discovery is designed to find every route, including the ones the tunnel is meant to hide.

The result is that a script on any page can create a peer connection object it never intends to use for a call, read the candidate list, and learn both your VPN address and your real one. It needs no permission for this, because gathering candidates is not the same as accessing a camera or microphone.

What actually leaks

Three pieces of information, of very different value to whoever collects them:

Modern browsers have made this harder than it was in 2015. Chrome and Firefox now hide local addresses behind randomised mDNS hostnames by default, which removes the third-party fingerprinting value of the local address. What they did not remove is the public address discovery, because that is what makes the feature work at all.

Turning it off, per browser

There is no single switch across browsers, and the quality of the available control varies a lot.

Firefox is the only mainstream browser with a genuine off switch. Open about:config, accept the warning, search for media.peerconnection.enabled and set it to false. WebRTC stops entirely. Browser-based calls will not work until you set it back.

Chrome and Chromium-based browsers, including Edge and Brave, have no built-in setting. Google removed the flag that used to control it. The supported route is an extension such as WebRTC Network Limiter, which restricts candidate gathering to the default public interface instead of enumerating every adapter. Brave additionally offers a WebRTC IP handling policy under its shields settings, which is the best control in the Chromium family.

Safari is stricter by default: it asks before allowing a site to enumerate addresses, and it does not expose them to arbitrary scripts as freely. Under Develop, WebRTC, you can disable the legacy API. For most users Safari needs no change.

On mobile, the picture is worse. Firefox for Android exposes about:config on some builds; Chrome for Android exposes nothing. If mobile browsing is where your risk lives, use a browser with a WebRTC control rather than trying to configure Chrome.

The trade you are making

Disabling WebRTC is not free. Browser-based video calls stop working - Google Meet, Jitsi, Discord in a tab, Whereby, most web conferencing. Some sites will show a vague error rather than telling you why.

The practical arrangement most people land on is two browsers: a daily browser with WebRTC disabled, and a second browser used only for calls, with the VPN either off or accepted as leaking during them. This is less elegant than a single setting, and it is the honest state of the ecosystem.

See what your browser is volunteering.

IP, WebRTC and DNS checks in one page, run in your browser. Nothing stored, no signup.

Run the leak check

Why a VPN cannot fix this for you

It is worth being precise, because plenty of providers advertise WebRTC leak protection as if it were a server-side feature.

The leak happens inside your browser, on your device, before any packet reaches the tunnel. No configuration on our exits or anyone else's can prevent a browser from asking the local networking stack what its addresses are. What a provider can honestly do is ship a client that adjusts browser or system settings for you - and since we ship no client at all, we say plainly that this one is yours to configure.

What we can do is show you the result. Our check page runs the WebRTC enumeration in your browser and displays exactly what a hostile page would have collected, alongside the DNS and IP tests, with nothing stored on our side.

Test discipline

Two habits that matter more than the initial fix:

FAQ

Does a WebRTC leak mean my VPN is broken?

No. The tunnel is carrying your traffic correctly. WebRTC asks the operating system for your addresses through a path your web traffic does not take, so the answer it gets is the real one. Every VPN has this exposure, because the cause is in the browser.

Can a website really get my IP without permission?

Yes. Creating a peer connection and reading its candidate list requires no user permission, because it is not camera or microphone access. Nothing appears on screen. The permission prompt you associate with video calls comes later, when a site asks for the devices themselves.

Do incognito and private windows stop it?

No. Private browsing changes what is stored on your device after the session. It does not change what the network stack reports while the session is live, and WebRTC works identically in a private window.

Is the mDNS change enough on its own?

It solves half the problem. Randomised mDNS hostnames hide your local network address, which removes one fingerprinting signal. Your real public IP is still discoverable, and that is the part that identifies you.

Should I just disable WebRTC everywhere?

If you never make browser calls, yes - it costs you nothing. If you do, keep a second browser for calls. Do not leave it enabled in the browser where your VPN is meant to protect you, on the assumption that no page will look.

The other silent leak, and the one with more search volume: DNS leak test and how to fix a leak

Check it yourself, trust nothing.

Free leak check, no signup. And if you need the tunnel underneath it: no account, no email, crypto from $1.99 a week. Telegram: t.me/CypherESIM_bot

Open Cypher VPN