WebRTC Leak Test
WebRTC can expose your real IP address to websites even when your VPN is active. This test inspects every ICE candidate your browser reveals — host, srflx, and relay — and tells you exactly what is leaking. It's a different failure mode than a DNS leak, which exposes your resolver, not your IP — run both, plus our full IP leak test for a combined view. New to how this works? Start with what a WebRTC leak actually is for the full technical breakdown.
Scored using our published, open-source methodology. View methodology
ICE candidate types — what each one reveals
How WebRTC bypasses your VPN — the 4-step mechanism
Site uses WebRTC
Browser contacts STUN
STUN reveals real IP
Site reads your IP
Real-world leak scenarios most guides skip
Kill switch is on, but you still leak
A kill switch protects you if the VPN tunnel drops — it blocks all traffic until the tunnel reconnects. It has nothing to do with WebRTC. While the tunnel is up and healthy, WebRTC opens a separate UDP socket straight to a STUN server, and unless your VPN client specifically intercepts that traffic at the OS network layer, the STUN response carries your real public IP as a server-reflexive (srflx) candidate. The kill switch never fires because, from its point of view, nothing went wrong — the tunnel never dropped.
Browser extension vs. desktop app
Most WebRTC leaks we see reported against "trusted" VPN providers trace back to the browser
extension, not the app. Full VPN apps route every socket on the device, including the ones
WebRTC opens. Lightweight browser extensions on some providers proxy HTTP/HTTPS requests only —
they change what fetch() and page loads see, but the UDP path WebRTC uses for
STUN binding requests goes around them entirely. If your test shows a leak, check whether
you're running the extension alone versus the full client.
Split tunneling forgot the browser
Split tunneling lets you route specific apps outside the VPN tunnel for performance (gaming, large downloads). If your browser — or a specific extension/profile — is excluded from the tunnel, either intentionally or by a misconfigured rule inherited from a previous setup, WebRTC traffic from that browser instance goes out over your regular ISP connection while every other tab looks protected. This is one of the more common self-inflicted leaks we see, and it won't show up in a plain "what's my IP" check because the page load itself is still tunneled — only the WebRTC socket isn't.
Corporate proxy or managed network
On a corporate network sitting behind a proxy or NAT gateway, HTTP traffic may be transparently proxied while STUN/UDP traffic is allowed to pass directly, because many enterprise proxies only inspect TCP port 80/443. The result: your browsing looks like it's coming from the corporate egress IP, but a WebRTC srflx candidate can reveal the workstation's real internal-to- external mapped IP, which is a distinct and sometimes more identifying data point in an office environment.
How to fix WebRTC leaks
Firefox — disable WebRTC entirely
about:config, search for media.peerconnection.enabled and set it to false. Completely blocks all WebRTC — no STUN or TURN candidates can be gathered.Chrome — install a WebRTC control extension
Use a VPN with built-in WebRTC protection
Use the Brave browser
Managed / corporate devices — enterprise policy
WebRtcLocalIpsAllowedUrls and WebRtcIPHandling Chrome policies via Group Policy or a managed config profile to force relay-only behavior fleet-wide, without relying on end users to install extensions.