Check whether WebRTC exposes your real IP address while using a VPN or proxy. Inspect WebRTC, STUN, IPv4 and IPv6 exposure directly in your browser.
WebRTC candidate probing will inspect active STUN reflexive responses and compare discovered public addresses against your normal HTTP communication interface.
Note: This diagnostic tests network candidate signals only. It does NOT request camera or microphone permissions.
| Type | Proto | Family | Address | STUN Source |
|---|---|---|---|---|
| No candidates gathered yet. Click "Start WebRTC Leak Test". | ||||
SDP session description will appear here after candidate gathering.
* SDP content is displayed purely client-side for technical audit purposes and is never uploaded to any server.
WebRTC (Web Real-Time Communication) is an open W3C standard allowing browsers to establish direct peer-to-peer video, audio, and data streams.
To establish P2P connections, WebRTC queries STUN servers to discover your public and local IP addresses, which can bypass VPN tunnels.
Our test inspects all generated ICE candidate SDP strings to identify whether your real ISP IP or local subnet address is exposed to web pages.
Prevent leaks by installing browser WebRTC control extensions, disabling WebRTC media device permissions, or configuring VPN desktop client leak rules.
Quick answers about how this tool works.
Plain-language explainers that sit next to this tool.
Verify your VPN is actually working: a complete checklist covering WebRTC leaks, DNS leaks, and IPv6 leaks that can expose your real IP even while "connected."
Understand DNS leaks: Learn why unencrypted OS DNS requests bypass VPN tunnels to ISP resolvers, and how to configure private encrypted DNS.
Understand how stylus pressure sensitivity actually works via the Pointer Events API, the most common causes of broken pressure response, and how to isolate a driver issue from an app setting.
Complete diagnostic guide to Traceroute and MTR (My TraceRoute). Learn how IP TTL expiration works, compare ICMP/UDP/TCP probing methods, and identify false intermediate packet loss.
A WebRTC leak occurs when your web browser's WebRTC (Web Real-Time Communication) framework exposes your true public or private IP address to web applications even while operating behind an encrypted Virtual Private Network (VPN) or proxy. Because WebRTC establishes peer-to-peer data channels outside standard HTTP request loops, unconfigured browsers may bypass VPN routing tables when gathering connectivity candidates via STUN (Session Traversal Utilities for NAT) servers.
To establish direct audio, video, or data connections between two browser endpoints without requiring relay server bandwidth, WebRTC uses the Interactive Connectivity Establishment (ICE) protocol. During candidate gathering, your browser sends STUN requests to public STUN servers. These STUN servers reflect back the public IP address and port combination that received the packet. If your VPN does not redirect or block these STUN requests, your ISP-assigned IP address is returned directly to the browser script.
To test your connection accurately:
An ICE candidate is a descriptor containing a transport address (IP address and port) that a WebRTC endpoint can use to communicate with a peer. ICE candidates are divided into four primary types:
STUN (Session Traversal Utilities for NAT) is a standardized network protocol defined in W3C RFC 5389. It enables clients operating behind NAT (Network Address Translation) routers to discover their public IP address, NAT mapping behavior, and external port assignments needed for peer-to-peer communications.
To prevent local network fingerprinting, modern web browsers implement Multicast DNS (mDNS) candidate masking. Instead of exposing raw private IPv4 addresses (such as 192.168.1.15), the browser generates a randomized UUID ending in .local (e.g. 5b7a12cd-3e41-4c12-88f1.local). Important: An mDNS candidate is a browser privacy feature designed to protect your internal network topology—it is NOT a public IP leak.
Virtual Private Networks route your operating system's network packets through an encrypted tunnel to a remote exit server. However, browser WebRTC implementations can sometimes bind directly to physical local network interfaces, issuing STUN requests that bypass the virtual TAP/TUN adapter created by the VPN client.
WebRTC does not inherently bypass modern, well-engineered VPN software that enforces strict routing hooks, TAP adapter bindings, or WebRTC protection modules. However, if you rely on a basic browser proxy extension or a VPN app lacking WebRTC leak protection, WebRTC STUN requests may easily bypass the proxy and expose your real public IP.
If a WebRTC IP leak is detected during your test:
about:config, locate media.peerconnection.enabled, and set its value to false.Google Chrome supports WebRTC IP handling policies that allow users and extensions to limit interface binding. Under default settings, Chrome attempts to gather candidates across all active interfaces. Extensions can configure Chrome to force WebRTC traffic through proxy interfaces or restrict candidate gathering to public IP addresses only.
Mozilla Firefox provides granular WebRTC privacy toggles. Users can completely disable WebRTC by setting media.peerconnection.enabled to false, or restrict candidate gathering using media.peerconnection.ice.default_address_only.
Browser-based WebRTC leak tests provide highly accurate diagnostic snapshots of browser network behavior at the exact moment of testing. However, browser updates, VPN client state changes, or network interface toggles can alter candidate exposure over time. A clean test result confirms that no WebRTC IP exposure was observed during the current diagnostic run.
Be the first to rate WebRTC Leak Test
Search 250+ free tools by name, or pick a category below. Every one runs instantly in your browser — no signup, nothing to install.
Tap a star to rate WebRTC Leak Test.