WebRTC leaks: the browser feature that can reveal your real IP

The short version

Your browser has a built-in tool for video calls and voice chat called WebRTC. To connect two people directly, it sometimes shares your device's real network address with the website, even if you're using a VPN to hide it. That's a WebRTC leak. It can quietly hand out the very address you were trying to keep private.

What's actually happening

Think of a VPN as a mail-forwarding service. You send letters through them, so the return address on the envelope is their office, not your home. WebRTC is like a helpful assistant who, when setting up a phone call, blurts out your actual home phone number so the other person can call you back directly. The forwarding service is still working, but the assistant just said your real number out loud.

WebRTC does this on purpose: direct connections make video calls faster and clearer. The trouble is that a web page can trigger this "here's how to reach me directly" step in the background, without a call ever happening, and read the addresses your browser offers up.

Why it matters to you

• A website can learn your real public address even while your VPN is on, revealing roughly where you are and who your internet provider is.
• It can also expose your device's private address on your home network (less sensitive, but still a detail you didn't mean to share).
• It's one of the most common ways a VPN's protection gets undone without you noticing.

Honest limits: a WebRTC leak reveals your IP address. It does not read your files, passwords, or the contents of your calls. And if you don't use a VPN, WebRTC isn't exposing anything your browsing didn't already show.

How to fix it

The fix depends on your browser. Pick yours.

Firefox (has a true off switch)

1. In the address bar, type about:config and press Enter.
2. Click Accept the Risk and Continue.
3. In the search box, type media.peerconnection.enabled.
4. Click the toggle so its value becomes false.

This turns WebRTC off completely. Browser-based video calls (like Google Meet or Discord in a tab) will stop working until you set it back to true.

Brave (built-in menu setting)

1. Type brave://settings/privacy in the address bar and press Enter.
2. Scroll to WebRTC IP handling policy.
3. Choose Disable Non-Proxied UDP for the strongest protection, or Default Public Interface Only if you still want video calls to work.

Chrome and Edge (need a helper)

These don't have a simple off switch. You have two reliable options:

• Use a VPN that routes everything (a "full tunnel"). This is the most dependable fix, because there's no real outside address for WebRTC to leak.
• Add a trusted extension. In uBlock Origin, open its Settings (dashboard) → Settings tab → tick Prevent WebRTC from leaking local IP addresses. Or install WebRTC Network Limiter (published by Google) from the extension store.

Phones

• Android, Firefox: same about:config steps as desktop.
• Android, Brave: open Settings → Brave Shields & privacy and set the WebRTC option there.
• iPhone/iPad: Safari and other iOS browsers don't expose a WebRTC switch. The practical fix is a full-tunnel VPN.

How to check it worked

Turn on your VPN, then run the WebRTC leak test on this site. You should see your VPN's address (or no public address at all), not your home internet address. If your real address no longer appears, you're protected.

If your result was already good

If this test passed, your browser isn't leaking, you don't need to change a thing. Many modern browsers and VPN apps already handle this. Just remember that browser updates occasionally reset settings, so if you ever switch browsers or do a major update, it's worth a quick re-test.

Want to go further?

The Advanced version explains ICE candidates, STUN servers, the exact Firefox and Chromium policy values, and why "mDNS obfuscation" already hides your local IP in most browsers.

What a WebRTC leak actually is

WebRTC enables peer-to-peer media and data channels directly between browsers. To traverse NAT, it runs ICE (Interactive Connectivity Establishment), gathering candidates, the addresses and ports at which a peer might be reachable. ICE uses STUN to discover the host's server-reflexive (public) address and also enumerates local interface (host) addresses. Any page can instantiate an RTCPeerConnection, call createOffer(), and read the candidates from onicecandidate / the SDP, no user permission, no camera or mic access required. Those candidates can include your real public IP (defeating a VPN) and your LAN IPs.

Why a VPN doesn't always stop it

If the VPN is a full tunnel that also captures UDP and the OS has no route around it, the only reflexive address STUN can discover is the VPN's. Leaks occur when: the client split-tunnels, IPv6 is unmanaged (STUN finds a native IPv6 address outside the tunnel), or the browser can still reach a STUN server directly over the physical interface. The classic failure is IPv6, confirm the tunnel carries or blocks it.

The mDNS mitigation (important context)

Since ~2019, Chromium and Firefox obfuscate local host candidates by replacing them with a randomized .local mDNS hostname (per the IETF draft on mDNS ICE candidates). So the "local IP exposure" that old guides panic about is largely solved by default in current browsers. The remaining and more serious concern is the server-reflexive (public) candidate, which is what unmasks a VPN. Test for that specifically.

Fixes by browser

Firefox

• about:config → media.peerconnection.enabled = false disables WebRTC entirely (breaks in-browser calls).
• To keep WebRTC but reduce exposure: media.peerconnection.ice.default_address_only = true (offer only the default route's address) and media.peerconnection.ice.no_host = true (suppress host candidates). media.peerconnection.ice.proxy_only = true forces all WebRTC through the configured proxy.

Chromium family (Chrome, Edge, Brave, Opera)

• No user-facing per-setting toggle in Chrome/Edge. The underlying knob is the WebRTC IP handling policy with four values: default, default_public_and_private_interfaces, default_public_interface_only, and disable_non_proxied_udp. The last forces TCP unless the proxy supports UDP and exposes no local addresses, strongest, but most likely to break calls.
• Brave exposes this directly: brave://settings/privacy → WebRTC IP handling policy. "Disable Non-Proxied UDP" is auto-selected when fingerprinting protection is on or in a Tor tab.
• Chrome/Edge set it via extension (uBlock Origin's "Prevent WebRTC from leaking local IP addresses," WebRTC Network Limiter) or enterprise policy (WebRtcIPHandling / the WebRtcIPHandlingUrl policies). The retired WebRTC Leak Prevent extension exposed the same enum.
• Disabling WebRTC wholesale in Chromium isn't supported without a flag/policy or extension; blocking it also breaks legitimate apps, so scope the change.

Safari

Safari implements WebRTC and offers no exposed IP-handling toggle; it already restricts candidate enumeration more aggressively and uses mDNS. On iOS, all browsers use WebKit, so there's no reliable per-browser switch, rely on a full tunnel.

Verification

• Run a WebRTC leak test over the VPN and read the public candidate. It must be the VPN's egress, not your ISP address. Also check for a leaked native IPv6.
• Programmatic check: open DevTools and inspect the SDP from a test RTCPeerConnection; typ srflx candidates carry the reflexive (public) address, typ host the local ones (should now be .local).
• Test each browser separately, policies don't carry across browsers, and test after major browser updates, which can reset flags.

Trade-offs and edge cases

• Disabling WebRTC breaks real features, Meet, Teams-in-browser, Discord web, Jitsi, many "click to call" widgets, and some screen-sharing. Prefer a policy that keeps calls working (public-interface-only) unless you need maximum isolation.
• mDNS can itself be a fingerprinting signal in exotic setups, but for almost everyone it's a net privacy gain, leave it on.
• Extensions are the weak link on Chrome/Edge: they patch the JS API surface, which is effective, but a misbehaving or disabled extension silently removes protection. A full tunnel that captures all UDP is architecturally stronger.
• What it doesn't hide: fixing WebRTC closes one IP-exposure vector. It does nothing about DNS leaks, TLS/SNI, cookies, or browser fingerprinting, treat it as one item on the leak checklist, not a privacy cure.