Disable WebRTC Loopback Candidates: Stop IP Leaks (2026 Browser Guide)

April 29, 2026

Open the network panel of your favourite tracking-detection tool, visit any well-instrumented website, and look at what gets reported. Almost every time, you'll see a row labelled "WebRTC local IPs" with one or two private network addresses on it — 192.168.1.42, 10.0.1.5, sometimes IPv6 link-local. Those addresses are leaking out of your laptop without your permission, regardless of whether you're using a VPN, and they reveal more than most users realise.

What is actually leaking

WebRTC — Web Real-Time Communication — is the API that lets browsers do peer-to-peer video and voice calls without plugins. To do that, two browsers need to figure out how to reach each other through NAT. The way the protocol does this is via STUN: each browser asks a public STUN server "what does my IP look like to you?" and "what local network addresses do I have?" and then exchanges those candidates with the other browser through a signalling channel.

The leak is in step two. To collect "what local network addresses do I have?", the browser doesn't ask the user, doesn't show a prompt, doesn't even fire a permission check. It just enumerates every network interface on the device and exposes their IP addresses to JavaScript on the page. Any site running fingerprinting code can call this API and read back, without consent:

Your private IPv4 (the one your router gave you, e.g. 192.168.1.x)
Your private IPv6 (link-local fe80::, ULA fd**::)
Sometimes your VPN's interface IP, if you're connected to one
On older browsers, your public IP — even behind a VPN, because the WebRTC connection bypassed the system DNS and the kernel routing table

The last one was the original "WebRTC leak" panic of 2015, and it's been mostly fixed by mainstream browsers — they now route WebRTC traffic through the same routing table as everything else. But the local-network IP exposure is still wide open, and that's what privacyscore.dev's WebRTC detector measures.

Why this matters even though "192.168.1.42 is just my laptop"

A few reasons. None of them are theoretical.

Re-identification across IPs. Your public IP changes when you switch from home WiFi to mobile data to a coffee shop, but your laptop's 192.168.1.42 stays the same as long as your home router gives it the same DHCP lease. A tracker that records "user X has private IP 192.168.1.42" can re-identify you the next time you appear on a different public IP, as long as you're still on your home network.

Network topology disclosure. If your private IP is 10.0.0.5 with subnet mask suggesting a /8, that's almost certainly a corporate network. 192.168.x.x is consumer-grade, 172.16.x.x is often small business or VPN, and IPv6 ULA prefixes fd**:: are unique enough to identify the exact router. None of this is "private" once it's exposed to a third-party JavaScript engine.

VPN bypass for fingerprinting. A VPN hides your public IP. It does nothing to WebRTC's local-IP enumeration. So a tracker that sees your home private IP one day, and the same private IP a week later when you're "anonymously" connected through Mullvad, has trivially re-identified you across the VPN.

Per-device fingerprinting. Your laptop's WiFi adapter has one IP, your Ethernet adapter has another, your VirtualBox/VMware virtual NIC has a third. Each interface's IP plus your MAC's vendor prefix is a per-device signal that's hard to fake.

The mDNS twist (and why most modern browsers leak less than they used to)

In 2019 the W3C and the major browser vendors agreed on a partial fix: instead of exposing the actual IP address of each interface, browsers should generate a per-session UUID, register it on the local network as an mDNS hostname (9b8e3d24-4f...local), and expose that instead of the raw IP.

The benefit: mDNS hostnames rotate on every page load, so they can't be used for cross-site or cross-session tracking. The local-network discovery still works for legitimate WebRTC use cases (a video call still finds the right network interface) because the call peer can resolve the mDNS name to an IP via local broadcast.

The status as of late 2026:

Chrome / Edge / Opera: mDNS-only by default. Raw IPs only exposed if you enable WebRTC IP Handling Policy manually.
Firefox: mDNS is enabled by default since Firefox 70. Same policy as Chrome.
Safari: mDNS by default since iOS 13 / Safari 13.
Brave: mDNS by default plus an option to disable WebRTC entirely in Settings → Shields.

So the picture in 2026 is much better than in 2018. But — and this is what privacyscore.dev's detector cares about — a browser that's not on its default settings, or running an old version, or where a corporate policy has switched mDNS off, will still leak raw private IPs. Our detector reads what the browser exposes and either:

Sees mDNS-only candidates (UUID.local strings) → reports "no leak" and doesn't deduct.
Sees raw private IPs → reports them and deducts 15 points.

Here's the actual logic from resources/js/fingerprint/webrtc.js (simplified):

const pc = new RTCPeerConnection({ iceServers: [] });
pc.createDataChannel('');
const ips = new Set();

pc.onicecandidate = (event) => {
    if (!event.candidate) return;
    const cand = event.candidate.candidate;
    const match = cand.match(/(\d+\.\d+\.\d+\.\d+|[a-f0-9:]+:[a-f0-9:]+)/i);
    if (!match) return;

    const ip = match[1];

    // Filter mDNS .local UUIDs — these rotate per session, not identifying
    if (cand.includes('.local')) return;

    // Filter loopback / non-routable
    if (ip.startsWith('0.') || ip === '127.0.0.1') return;

    ips.add(ip);
};

await pc.createOffer().then(o => pc.setLocalDescription(o));

The mDNS filter is critical: without it, every Chrome user since 2019 would show "WebRTC leak detected" when in fact their browser is correctly defending. The filter is a positive signal — its presence means the browser is doing the right thing.

How to fix WebRTC leaks, browser by browser

Firefox

The cleanest option: open about:config and set:

media.peerconnection.enabled = false

That disables WebRTC entirely. You will lose the ability to do video calls in Discord-web, Zoom-web, Slack huddles and similar — they'll fall back to TURN-server-relayed audio if available, or just fail. For a fingerprinting-conscious profile, this is the right trade.

If you don't want to lose WebRTC entirely, the media.peerconnection.ice.default_address_only pref (introduced in FF 70) restricts ICE to a single default interface, which limits the leak.

Chrome / Edge / Brave

Chrome doesn't expose a clean chrome://flags toggle for WebRTC anymore. The supported way is the WebRTC Network Limiter extension from Google itself, which sets the policy to "default route only" — same effect as Firefox's default_address_only.

For full disable, the only path on Chrome is the Enterprise WebRtcUdpPortRange / URLBlocklist policies via policy.json, which most home users won't touch. On Brave, Settings → Shields → "WebRTC IP Handling Policy" gives you the toggle directly without needing extensions or policies.

Safari

Safari has no exposed setting. Your only option is to use Lockdown Mode (Settings → Privacy & Security → Lockdown Mode), which disables a number of fingerprintable features including some WebRTC paths, but breaks a lot of legitimate functionality. For most users it's not worth the cost.

Tor Browser

WebRTC is disabled by default. Nothing to do.

LibreWolf

WebRTC is enabled but with the same default-route-only restriction as Firefox 70+. Single-interface mode is the default; full disable is a one-pref change as in Firefox.

What about VPNs?

This deserves repeating because the misconception is everywhere: a VPN does nothing to WebRTC's local-IP exposure. The VPN encrypts your traffic at the IP layer; the JavaScript engine reading WebRTC candidates is operating at the application layer and pulling data straight from the OS. The two have nothing to do with each other.

If you connect to ProtonVPN, your public IP changes from your ISP's allocation to a Swiss exit node. Your WebRTC candidates still report 192.168.1.42, the same as before, because that's still the IP your laptop has on its WiFi adapter. The VPN doesn't relocate your network interfaces; it only routes their packets differently.

If you specifically want the VPN to also mask your WebRTC, you need either: a browser configured to disable WebRTC, or a VPN client that injects WebRTC-handling code into the browser (Mullvad's browser extension does this, as does NordVPN's). The VPN tunnel alone is not enough.

FAQ

If I'm at home behind NAT, why does any of this matter?

Because the IP behind NAT identifies you — it's a stable per-device, per-network token that survives public IP changes. A tracker that sees the same private IP across two visits has likely confirmed two visits from the same household even if the public IP rotated. Combine with one or two other signals (User-Agent, canvas hash) and re-identification is trivial.

Is mDNS hostname (UUID.local) actually safe?

Yes, for tracking purposes. mDNS hostnames are generated fresh per RTCPeerConnection, which is per-page-load in practice. They don't persist, can't be correlated across sessions, and don't reveal anything about your network beyond "you have at least one network interface". If you see only UUID.local entries in the WebRTC list on privacyscore.dev, that's the equivalent of "no leak" and our scorer treats it that way.

Why doesn't disabling WebRTC just become the default?

Browser vendors have a hard time disabling WebRTC because it's load-bearing for Discord-web, Slack huddles, Google Meet (when not using the desktop client), Zoom-web, Microsoft Teams-web, and basically every "open a video call in the browser" workflow. Even mDNS-only mode breaks a few advanced use cases — anything that needs to discover specific local devices (Sonos web app, Plex, Home Assistant) suffers because mDNS-rotated names can't be hand-keyed.

I disabled WebRTC and now Discord won't open call. Worth it?

For most users, no. The pragmatic compromise is "default route only" mode (Firefox default_address_only or Chrome's WebRTC Network Limiter extension): you keep WebRTC working but it only exposes the IP of your default interface, eliminating the cross-network re-identification angle. That's what we'd recommend if you don't have a specific threat model that warrants full disable.

Does this matter on mobile?

Less, but not zero. On iOS and Android, mDNS is the default for all major browsers, so the typical "private IP leak" is already mitigated. The remaining issue is for users on cellular data who happen to also be on a WiFi network — both interfaces leak — and for VPN-connected mobile users where the VPN interface IP can leak too. If you're a privacy-conscious mobile user, install Brave and use its WebRTC toggle.