You connect to a VPN. You confirm the new IP looks right on a "what's my IP" site. You feel safe. Then you load some random webpage and, behind the scenes, that page asks your browser to discover its own network addresses — and gets back not just the VPN's IP, but the actual private address of the laptop you're sitting at, like 192.168.1.42. No permission prompt. No camera or microphone request. Just a few lines of JavaScript that any site can run.

That's a WebRTC leak: a privacy hole that's been part of the web platform since 2011, that has nothing to do with cookies or tracking pixels, and that defeated VPNs for years. The good news is that modern browsers mostly plug it now. The bad news is that there's no warning when the protection isn't on.

What WebRTC actually is

WebRTC stands for Web Real-Time Communication. It's the browser API behind every video call you've made in a browser tab — Google Meet, Discord's web client, Whereby, your bank's screen-sharing widget. It also powers peer-to-peer file transfer in apps like ToffeeShare and browser-based games that need low-latency multiplayer. It's built into every major browser and needs no plugin.

The reason WebRTC exists is performance. Routing a video call through a server adds latency, bandwidth costs, and a single point of failure. Two browsers talking directly to each other is faster and cheaper. But to talk directly, each side needs to know its own reachable addresses — the local LAN address that other devices on the same network can hit, the public address other people on the internet can hit, and any fallback addresses for cases where neither works.

How ICE creates the leak

The process of discovering those addresses is called ICE — Interactive Connectivity Establishment, defined in RFC 8445. When a webpage creates an RTCPeerConnection, the browser gathers a list of candidates, where each candidate is one possible way to reach this browser. There are three main types:

  • Host candidates. Addresses on the local network interfaces of the device itself. On a typical laptop these are private addresses like 192.168.1.42 or 10.0.0.5. These are the ones that matter for the leak.
  • Server-reflexive (srflx) candidates. The browser sends a UDP packet to an external STUN server, and the STUN server replies with "I saw your packet coming from this address." That's your public IP, exactly as websites and other peers see it. (See our piece on public versus private IPs for what those mean.)
  • Relay candidates. Addresses on a TURN relay server, used as a fallback when both peers are behind restrictive NATs and can't talk directly. These reveal the TURN server, not you.

The leak is that any webpage can trigger ICE gathering in JavaScript and read the candidate list directly. No camera-permission prompt fires. No microphone-permission prompt fires. Nothing visible happens at all. The page just learns your public IP and your private LAN IP. In the worst-case version, on older browsers, it also learned the IP of every network interface — including the one bypassing your VPN tunnel.

That's why this matters disproportionately to VPN users. A normal user's public IP is already visible to every site they load — it has to be, or the response packets wouldn't know where to go. But a VPN user is intentionally hiding their public IP behind the VPN's. Pre-mitigation WebRTC let any page route around that hiding.

The mDNS fix

Browser vendors took the problem seriously after a 2015 demonstration made the rounds. The fix that stuck is called mDNS obfuscation. Instead of returning raw private addresses, the browser invents a random hostname like fb3ec246-f13a-4c4a-b7ff-8bc3beca1008.local for each host candidate and serves that to the page. Peers on the same local network can resolve the .local hostname via mDNS (the same protocol Bonjour and Avahi use) and reach the real device — but a webpage in JavaScript can only see the opaque random string, which is useless for tracking and changes every browser session.

Where this stands across browsers as of mid-2026:

  • Chrome, Edge, Opera, Brave. mDNS by default since Chrome 76 in 2019. Pages get raw IPs only after the user grants camera or microphone permission.
  • Firefox. Now also uses mDNS by default — the relevant pref is media.peerconnection.ice.obfuscate_host_addresses = true in about:config, and it ships on in current releases. This is a relatively recent change; many guides on the open web still say Firefox leaks, but if you're on an up-to-date build, it doesn't.
  • Safari. Doesn't expose host candidates at all by default — the most conservative posture of any major browser.
  • Brave. Has a configurable WebRTC IP-handling policy with strict options that disable non-proxied UDP entirely.
  • Tor Browser. WebRTC is off completely.

One thing worth being clear about: your public IP is always visible via the srflx candidate. That's not the leak — it's how STUN is designed to work, and it's the same address every site sees from your TCP connection anyway. The leak question is specifically about whether the page can see your local network address alongside that public one.

Who's still at risk

If you're on a default install of Chrome, Edge, Brave, Safari, or a current Firefox, you're probably fine. A short list of cases where the protection might not be on:

  • Older browser versions that predate mDNS support, especially on older mobile devices or kiosk systems.
  • Browsers where someone has manually flipped the obfuscation pref off, or installed an extension that disables mDNS for development or compatibility.
  • Custom or embedded WebRTC stacks (some app webviews, electron apps) that don't include the mainline browser hardening.
  • Network environments where mDNS is filtered upstream and a fallback to raw addresses kicks in.

If you're on a VPN and you want to know which bucket you're in, the test takes about four seconds.

How to test yours

The WebRTC Leak Test runs the same probe a tracker would: it creates an RTCPeerConnection, uses three public STUN servers (Google, Cloudflare, Nextcloud) for redundancy, gathers every candidate the browser produces, and shows you the list. Each row is one ICE candidate with its type (host / srflx / relay), the address, a classification (Public / Private RFC1918 / Link-local / mDNS), and the protocol.

The verdict at the top tells you the practical answer in one line:

  • Green "No Leak Detected" — only mDNS .local hostnames in the host candidates, or no host candidates at all. Your real LAN IP is hidden.
  • Red "Local IP Exposed" — a raw 192.168.x.x, 10.x.x.x, or 172.16-31.x.x address is in the list. Trackers can use it as a stable identifier inside your network. If you're on a VPN, your local network address is leaking around it.
  • Amber "WebRTC Blocked" — no candidates returned at all. WebRTC is either disabled (Tor Browser, hardened config) or blocked by the network. From a leak perspective this is the safest outcome.

The test runs entirely in your browser — there's no API call to a backend involved. The result never leaves your device. You can verify in DevTools / Network.

How to fix it

For most users, nothing needs doing — the browser already handles it. For the cases where the test does come back red:

  • Firefox (older builds): set media.peerconnection.ice.obfuscate_host_addresses = true in about:config to enable mDNS without breaking video calls. The nuclear option is media.peerconnection.enabled = false, which turns WebRTC off entirely — fingerprinting can't probe what doesn't exist, but video calls in your browser stop working.
  • Chrome and Edge: there's no native toggle. Either install a reputable WebRTC leak-prevention extension or switch to Brave, which has the controls built in.
  • Brave: Settings → Shields → WebRTC IP Handling Policy → "Disable Non-Proxied UDP". This is the most restrictive setting and the closest you can get to Tor's behavior without leaving the mainstream browser ecosystem.
  • VPN client: some commercial VPNs implement system-level WebRTC leak protection that intercepts STUN traffic before it reaches the browser. Check whether yours has it and turn it on. This is the only fix that works regardless of browser.

WebRTC is also one of many signals a sophisticated fingerprinting script can combine — see our piece on browser fingerprinting for the broader picture, and the browser fingerprint tool to see what your browser exposes beyond just WebRTC. To confirm what public IP the world actually sees from you, the IP lookup tool shows the same value any other site would.

Try it

Run the WebRTC Leak Test

Four seconds, three STUN servers, every ICE candidate your browser will hand over to a webpage. Find out exactly what your browser is willing to reveal — and check whether your VPN is plugging the hole or not.

Run the WebRTC Leak Test →

If your VPN is fine on the WebRTC front, the next thing worth checking is whether the public IP itself is flagged. The VPN & proxy check tells you whether the IP you appear to be coming from looks like a known commercial VPN, proxy, Tor exit, or data center — useful for sanity-checking that whatever you're paying for is actually doing what you expect.