WebRTC IP Leak Test

What's a WebRTC leak?

WebRTC (Web Real-Time Communication) is the browser API used for video chat, voice calls, screen sharing, peer-to-peer file transfer. To make peer-to-peer connections work behind NAT, WebRTC uses a technique called ICE — which involves enumerating your local network interfaces and asking STUN servers for your public address. The results are sometimes exposed to JavaScript on the web page.

For VPN users, this means: even though your traffic appears to come from the VPN's IP, WebRTC may reveal your real IP to any website that asks. This is the "WebRTC leak."

What this test detects

• Local IPs — your machine's private addresses (192.168.x.x, 10.x.x.x, etc.). Mostly harmless, but reveals your LAN structure.
• Public IPv4 — the public IP your browser sees from STUN. If this matches your VPN exit, you're fine. If it shows your real ISP IP while using a VPN — that's a leak.
• Public IPv6 — same as above for v6. Many VPNs handle v4 but leak v6.
• mDNS hostnames — Chrome and Safari now obfuscate local IPs as mDNS hostnames (random UUID-like values ending in .local). This is a privacy improvement.

What to do if you have leaks

• VPN setting: Most modern VPN clients have a "WebRTC leak protection" toggle. Turn it on.
• Browser extension: uBlock Origin can block WebRTC IP exposure (Settings → Privacy → Prevent WebRTC from leaking local IP addresses).
• Firefox: Set media.peerconnection.enabled = false in about:config. Breaks video calls but stops all WebRTC.
• Brave: Built-in "WebRTC IP Handling Policy" in Settings → Privacy.

Why WebRTC leaks matter

WebRTC is a browser API designed for real-time communication — video chat, voice calls, peer-to-peer connections between users. To make direct peer-to-peer connections work through NATs and firewalls, WebRTC asks the browser to enumerate every IP address associated with the device: local network IPs, public IP as seen from various perspectives, IPv6 addresses, and more. The results are made available to the JavaScript on the page.

This is fine when you actually want video chat. It's a problem when you're using a VPN and expect your real IP to be hidden. Even if all your regular web traffic routes through the VPN tunnel, WebRTC can still reveal your true local and public IP addresses through a separate discovery process. This has been the subject of numerous articles, VPN vendor debates, and browser-vendor mitigations over the years.

What the leak actually is

WebRTC uses a protocol called ICE (Interactive Connectivity Establishment) to figure out how two peers can reach each other. ICE gathers "candidates" — potential ways to make a connection — and shares them with the other peer. These candidates include:

• Host candidates: your device's local network interfaces, including LAN IP addresses and any VPN adapters
• Server-reflexive candidates: your public IP as seen by a STUN server
• Relay candidates: an IP address on a TURN server that will relay traffic when direct connection fails

Host candidates are the interesting ones for privacy. When your browser enumerates its network interfaces to WebRTC, it might list your real LAN IP (10.0.0.42, for example) even though you're on a VPN. It might also list your real physical LAN's private IP alongside the VPN adapter's IP. Any JavaScript on the page can read these values.

The server-reflexive candidate reveals your public IP as seen by a STUN server, which for anyone actually on a VPN should be the VPN's exit IP. But some VPN configurations don't route STUN traffic through the tunnel, revealing the real public IP through this channel too.

How VPN users get burned

Split-tunnel VPN configurations

Some VPNs, either by design or misconfiguration, route only web browser traffic through the tunnel. Other applications and system-level services might connect directly. If STUN traffic goes direct while HTTP goes through the tunnel, the WebRTC public IP disclosure reveals your real IP even though everything looks normal in a regular IP check.

Browser extensions that don't handle WebRTC

Some VPN browser extensions route your traffic through a proxy but don't disable WebRTC or block STUN. Users see they're on the VPN and assume they're fully protected, but WebRTC-enabled sites can still probe for the real IP.

Multiple network interfaces

A laptop with both wired and wireless connections, or with the VPN adapter in addition to the real network interface, might expose all of them to WebRTC. Even if the VPN routing is correct, host candidates include every interface. The tool that reads these candidates can see them all.

mDNS-based mitigation partially masks host IPs

Modern browsers (Chrome 76+, Firefox 68+) obfuscate host candidates behind mDNS-generated hostnames like ec7495d2-2c2b-4de9-9b3c-a1b2c3d4e5f6.local instead of the raw IP address. This is a real privacy improvement, but it only applies to the LAN IP, not the public IP. And older browsers or specific configurations don't use it.

What this tool actually checks

It initiates WebRTC candidate gathering with a public STUN server and shows you what candidates your browser exposes. If you see a private IP that's your actual LAN (10.x, 192.168.x, 172.16-31.x), that's your host candidate. If you see a public IP that matches what any IP checker shows, that's your server-reflexive candidate. If either doesn't match what you expect for your privacy configuration, you have a leak.

Interpreting the results

• You're not on a VPN and everything is normal: you'll see your LAN IP as a host candidate and your ISP's public IP as the server-reflexive candidate. This is expected and not a leak.
• You're on a VPN and it's working correctly: you'll see either your VPN adapter's IP as the host candidate (or an mDNS-obfuscated version) and the VPN's exit IP as the server-reflexive candidate. Your real LAN and real public IP should not appear.
• You're on a VPN and there's a leak: your real LAN IP and/or real public IP appear in addition to (or instead of) the VPN's addresses.

How to fix a leak

Use a full-tunnel VPN configuration

The most reliable fix. A full-tunnel VPN routes all traffic through the tunnel, including STUN queries. Applications never see the physical network directly. Most quality commercial VPN clients default to this; some have a split-tunnel option that you might have accidentally enabled.

Disable WebRTC in the browser

Nuclear option. Firefox has an about:config setting (media.peerconnection.enabled) that disables WebRTC entirely. Chrome and Edge don't have a native setting but there are extensions that add one. Disabling WebRTC breaks video chat, some interactive websites, and Google Meet. Worth it if you're using the browser exclusively for privacy-sensitive work.

Use a browser with better WebRTC handling

Some privacy-focused browsers (Brave, Tor Browser) handle WebRTC more conservatively than mainstream browsers. Brave has an explicit WebRTC handling setting that can force the "proxy only" mode where STUN follows the browser's proxy configuration.

Use a browser extension

uBlock Origin can be configured to block WebRTC from being used to leak local addresses. NoScript for Firefox has similar options. Neither is a complete fix but they help.

Configure the VPN to block WebRTC

Some enterprise VPN clients and some higher-end consumer VPN clients (Mullvad, ProtonVPN) include settings specifically to prevent WebRTC leaks. If your VPN offers this, enable it.

What WebRTC leaks reveal

Your public IP

If your public IP leaks, anyone with a public STUN server can identify your ISP's IP even while you're on a VPN. This is the concerning case for people specifically using VPNs to hide their real IP.

Your LAN IP

Your LAN IP is not directly identifying — most home networks use the same 192.168.1.x or 192.168.0.x ranges — but it can be used as a fingerprinting signal. If a site sees you always have 10.20.30.40 as a host candidate, that's a stable identifier across sessions unless you specifically change it.

The presence of a VPN

If both your real IP and the VPN's IP appear in candidates, that reveals to the site that you're using a VPN — even though the site would have otherwise seen only the VPN's IP through normal web traffic. Not always relevant, but sites that block VPNs might use this signal.

What WebRTC leaks don't reveal

Your name, location beyond IP, or any personal data

WebRTC only exposes network-level information. It doesn't reveal browsing history, personal identifiers, cookies from other sites, or anything that isn't already available to the current page.

Data from other browser tabs

WebRTC candidates are page-scoped. The candidates exposed to example.com don't leak to any other site.

Precise geolocation

The IP address is what gets exposed. The geolocation of that IP is a separate lookup that any site can do with any IP. WebRTC doesn't reveal GPS coordinates or anything similarly precise.

Related tools

To see what your public IP looks like from a normal HTTP request (compare against what WebRTC reveals), use the IP Lookup tool with no arguments. To understand which network operator owns the IP you're seeing, either the IP Lookup or the Domain Infrastructure tools show ASN and organization information.

For understanding the security posture of a site more broadly, the HTTP Headers Inspector and SSL/TLS Cert Inspector pair well.

Privacy

This tool runs entirely in your browser. The WebRTC candidates it displays are generated locally and shown only to you. Nothing about your candidates is sent to any server. The STUN query used to gather server-reflexive candidates goes to a well-known public STUN server (Google's or Cloudflare's, depending on availability) which by definition sees your public IP anyway.