Run a free WebRTC leak test to check if your real IP address is exposed through WebRTC. This tool probes multiple STUN servers to detect local IP leaks, public IP leaks, IPv6 exposure, and mDNS obfuscation status. If you use a VPN and this test shows your real ISP IP — your VPN is bypassed. Works on Chrome, Firefox, Edge, Safari, and Brave.
Quick Answer: Is WebRTC Leaking Your IP?
A WebRTC leak happens when your browser's WebRTC API exposes your real IP address through ICE candidate gathering — even behind a VPN. Our tool creates RTCPeerConnection objects against multiple STUN servers (Google, Twilio) to detect local private IPs (192.168.x.x), public IPs via STUN reflection, IPv6 addresses, and checks if your browser uses mDNS obfuscation to hide local addresses. If any real IP appears that does not match your VPN, you have a leak.
--
IPs Found
--
Local IPs
--
Public IPs
--
IPv6 Found
--
mDNS
IPs gathered from ICE candidates via RTCPeerConnection

Cybersecurity Threat Researcher
Jessica specializes in WebRTC privacy research, browser fingerprinting analysis, VPN leak detection, and data privacy compliance. She has assessed WebRTC leak vulnerability across 50+ VPN services and browser configurations.
View All ArticlesWebRTC (Web Real-Time Communication) is a browser technology that enables video calls, voice chat, and file sharing directly between browsers without plugins. It powers services like Google Meet, Zoom Web, Discord, and Facebook Messenger. The problem is that to establish these peer-to-peer connections, your browser must discover its own network addresses — and that discovery process can expose your real IP address to any website that asks.
When a website creates an RTCPeerConnection object and begins gathering ICE (Interactive Connectivity Establishment) candidates, your browser contacts STUN servers to discover your public IP. It also collects local network addresses from your device. These IP addresses are returned to the website through JavaScript — completely bypassing your VPN tunnel, proxy server, or any other privacy tool you are using. This is the core mechanism behind a WebRTC IP leak.
Our WebRTC leak test replicates exactly what a malicious website would do. It creates RTCPeerConnection objects against multiple STUN servers and collects every ICE candidate your browser produces. If any IP address in those candidates does not belong to your VPN, you have a leak. For a complete privacy audit covering all leak vectors, use our Browser Leak Test which checks WebRTC alongside 20 other privacy vectors.
Why This Matters: A WebRTC leak happens silently. You will never see a permission popup or notification. Any website can run this check in the background using a few lines of JavaScript. If your VPN does not specifically block WebRTC, your real IP is likely exposed right now.
Our tool performs a multi-stage probe that mirrors real-world WebRTC leak exploitation. Understanding the process helps you interpret results accurately and fix leaks effectively.
The tool creates a new RTCPeerConnection with STUN server configurations pointing to Google's public STUN server (stun:stun.l.google.com:19302) and a secondary STUN endpoint for redundancy. A data channel is created to trigger ICE gathering.
As ICE candidates arrive, the tool parses each candidate string to extract IP addresses. Every candidate contains the IP address, port, protocol (UDP/TCP), and candidate type. The tool classifies each IP into one of five categories:
abc123.local where the browser has replaced your local IP with a random hostname for privacy.// Raw ICE candidate example (what our tool parses)
candidate:842163049 1 udp 1677729535 192.168.1.105 54321 typ srflx raddr 0.0.0.0 rport 0
// ↑ This reveals your local IP to the website
// STUN reflection candidate (reveals public IP)
candidate:3478291056 1 udp 1845501695 203.0.113.45 12345 typ srflx raddr 192.168.1.105 rport 54321
// ↑ Your real public IP, bypassing VPN
Modern Chrome and Edge replace local IPs with .local mDNS hostnames by default. Our tool detects if your browser uses this protection. If you see .local addresses instead of 192.168.x.x, your local IP is obfuscated — but your public IP can still leak via STUN. Check your full browser configuration and DNS resolver settings.
Every browser handles WebRTC differently. Here is how to stop WebRTC IP leaks in each major browser, tested and verified in 2026.
Firefox is the only major browser that lets you completely disable WebRTC without extensions. Open a new tab, type about:config in the address bar, accept the risk warning, and search for media.peerconnection.enabled. Double-click to set it to false. This stops all WebRTC connections and eliminates every leak vector.
// Firefox about:config settings for maximum privacy
media.peerconnection.enabled → false
media.peerconnection.turn.disable → true
media.peerconnection.use_document_iceservers → false
media.peerconnection.identity.timeout → 1
// After changing: Re-run this WebRTC leak test to verify
Trade-off: Disabling WebRTC in Firefox breaks video calling on Google Meet, Zoom Web, Microsoft Teams, and Discord. If you need these services, re-enable WebRTC temporarily, use them, then disable again. Alternatively, use a separate browser profile for video calls.
Chrome has no built-in option to disable WebRTC. Install uBlock Origin from the Chrome Web Store, then go to its Dashboard → Settings → check "Prevent WebRTC from leaking local IP addresses". This blocks local IP exposure but may not prevent all STUN leaks. For complete protection, switch to Brave.
Brave has native WebRTC leak protection. Go to Settings → Privacy and security → WebRTC IP Handling Policy and select "Disable non-proxied UDP". This forces all WebRTC through your VPN or proxy. Brave is the most privacy-friendly Chromium browser for WebRTC handling.
Safari restricts WebRTC to require user permission for camera and microphone access. It does not expose local IPs through ICE candidates by default. However, STUN-based public IP leaks are still possible. Safari users should rely on their VPN's built-in leak protection.
Edge uses the Chromium engine, so the uBlock Origin extension works identically. You can also access edge://flags/#enable-webrtc-hide-local-ips-with-mdns and ensure mDNS obfuscation is enabled for local IP protection.
After Fixing: Always re-run this WebRTC leak test after applying fixes. Some VPN browser extensions override your settings, and browser updates can reset flags. Verify your complete privacy posture with our Browser Leak Test. Check your IP fraud score to ensure your IP has a clean reputation.
To understand why WebRTC leaks happen, you need to understand how browsers establish peer-to-peer connections. The process involves three key technologies: STUN, TURN, and ICE.
STUN (Session Traversal Utilities for NAT) servers help your browser discover its public IP address. When your browser connects to a STUN server, the server reflects your IP back to you. This is necessary because most devices sit behind NAT routers and do not know their own public address. Google operates free STUN servers at stun.l.google.com:19302 that are used by most WebRTC implementations.
TURN (Traversal Using Relays around NAT) servers act as relay points when direct peer-to-peer connections fail. TURN candidates in ICE gathering show relay addresses, not your real IP. These are generally safe from a privacy perspective.
ICE (Interactive Connectivity Establishment) is the framework that coordinates STUN and TURN to find the best connection path. During ICE gathering, your browser generates multiple "candidates" — each one containing an IP address, port, and connection type. These candidates are where the leak occurs.
| Candidate Type | Source | Leak Risk | Example |
|---|---|---|---|
| host | Local device interface | High | 192.168.1.105 |
| srflx | STUN server reflection | Critical | 203.0.113.45 |
| relay | TURN relay server | Safe | 198.51.100.10 |
| prflx | Peer reflexive | Medium | Varies |
The srflx (server reflexive) candidate is the most dangerous — it contains your real public IP address reflected by the STUN server. This is the candidate that bypasses VPNs. Our tool flags these specifically. Verify your connection security with our SSL Checker and Headers Analyzer.
In 2020, Chrome and Edge introduced mDNS obfuscation to address local IP leaks. Instead of exposing your real local IP (like 192.168.1.105) in ICE candidates, the browser generates a random UUID-based .local hostname (like 4a5b6c7d-8e9f-1234-abcd-ef1234567890.local). This means websites can no longer see your internal network address through WebRTC.
However, mDNS obfuscation has important limitations. It only protects your local IP address. Your public IP can still leak through STUN server reflexive candidates. It also does not apply when the user has granted media permissions (camera or microphone access) — once you allow a site to use your webcam, your local IP becomes visible again.
Our tool specifically checks for mDNS candidates. If you see .local addresses in the ICE log, your browser is applying this protection. If you see raw 192.168.x.x or 10.x.x.x addresses, your local IP is fully exposed. Firefox does not use mDNS — it either exposes local IPs or blocks WebRTC entirely depending on your about:config settings.
For additional fingerprinting analysis, check your Canvas Fingerprint, Audio Fingerprint, and Font Leak exposure.
Not all VPNs handle WebRTC leaks equally. Some VPN providers include built-in WebRTC leak protection while others leave you completely exposed. Here is what to check and what to demand from your VPN provider.
A VPN with proper WebRTC leak protection does one or more of the following: it configures browser WebRTC to only use the VPN interface, it blocks STUN requests from reaching servers outside the tunnel, or it forces WebRTC to operate through TURN relay servers controlled by the VPN. Without at least one of these measures, your real IP leaks despite the encrypted tunnel.
To test your VPN, connect to it first, then run this WebRTC leak test. Compare the IP addresses found with your known VPN IP. If any address matches your ISP (check with our IP Fraud Checker), your VPN is not protecting you from WebRTC leaks. Test from multiple browser profiles, because extensions and settings in one profile may mask a leak that exists in another.
VPN Testing Checklist: (1) Connect VPN → run this test → check for ISP IP. (2) Try different VPN protocols (WireGuard vs OpenVPN). (3) Test in incognito mode without extensions. (4) Check both IPv4 and IPv6. (5) Verify DNS resolver with our DNS Lookup. Read our IP reputation guide.
WebRTC leaks affect anyone who relies on IP-level privacy. Some users face more serious consequences than others depending on their threat model.
Journalists and activists working in countries with internet surveillance face the highest risk. A WebRTC leak can reveal their real location to the websites they visit, undermining the protection provided by their VPN or Tor setup. In 2024, researchers documented cases where state-sponsored websites used WebRTC probing to deanonymize visitors.
Remote workers accessing corporate networks through VPN can inadvertently expose their home IP and local network configuration through WebRTC. This gives potential attackers information about the network topology behind the VPN.
Privacy-conscious individuals who pay for VPN services specifically to hide their IP should know that without WebRTC protection, their subscription provides incomplete privacy. Running this test takes 5 seconds and can reveal whether your investment is actually working.
For comprehensive device privacy analysis, check your Hardware Info (GPU and CPU exposure), Screen Resolution details, Battery API leak, and Timezone Audit. Inspect cookies and tracking data with our Cookie Checker. Learn about clearing your digital footprint.
Pro Tip: Create two browser profiles — one for daily browsing with WebRTC disabled, and one for video calls with WebRTC enabled. This gives you maximum privacy without losing video call functionality. Check our IP reputation for email marketing guide.
A WebRTC leak exposes your real IP address through your browser's WebRTC API, even behind a VPN. It happens when ICE candidate gathering reveals your local and public IP to websites via STUN server requests that bypass your VPN tunnel.
Use our tool above. It probes STUN servers and collects ICE candidates from your browser. If your real ISP IP appears (not your VPN IP), you have a leak. Check both with and without your VPN connected.
Type about:config in the address bar, search for media.peerconnection.enabled, and set it to false. This completely stops WebRTC. Video calls will not work in this browser until you re-enable it.
Install uBlock Origin and enable "Prevent WebRTC from leaking local IP addresses" in its settings. Alternatively, use Brave browser which has built-in WebRTC leak protection under Privacy settings.
Not automatically. Most VPNs do not block WebRTC requests. STUN servers operate outside the VPN tunnel, so your real IP can leak. Some VPNs include WebRTC leak protection — always test with this tool after connecting.
mDNS obfuscation replaces your local IP with a random .local hostname in ICE candidates. Chrome and Edge do this by default. It hides your local network address but does not prevent public IP leaks via STUN servers.
In older browsers or after granting camera/mic permissions, yes. Modern Chrome uses mDNS to hide local IPs. Firefox exposes them unless WebRTC is disabled. Run our test to see what your browser reveals.
ICE candidates are network addresses your browser collects to establish WebRTC connections. STUN servers reflect your public IP back to your browser for NAT traversal. The combination of these is what enables — and leaks — your IP through WebRTC.
Our WebRTC leak test probes STUN servers, analyzes ICE candidates, checks mDNS obfuscation, and gives you a clear verdict — leaked or safe. Free, instant, no extensions required.