01What is a WebRTC leak?
WebRTC powers in-browser audio/video calls and peer-to-peer (Meet, Discord, video conferencing…). To connect two machines directly, it must discover your IP addresses — even behind a router — through STUN servers. The problem: this discovery can bypass your VPN or proxy and reveal your real IP address to any website, with a few lines of JavaScript.
This test reproduces exactly what a curious site would do: it asks WebRTC for its connection candidates and compares the public address obtained with your HTTP connection's (also shown on the home page). If the two differ while you are behind a VPN, your VPN provider is leaking your address.
02Understanding the results
- STUN
- A server that answers “here is the address you are contacting me from”: this is how WebRTC discovers your public IP, even behind a NAT.
- Candidate
- Each address your machine believes it is reachable at: local (host), public via STUN (srflx), relayed (relay).
- srflx
- Server-reflexive: the public address seen by the STUN server. This is what leaks when STUN traffic escapes the VPN tunnel.
- mDNS
- Modern protection: browsers replace your local addresses with random .local pseudonyms, unreadable to websites.
- Leak
- WebRTC reveals an address your VPN/proxy was supposed to hide. Geolocation, ISP and sometimes the subscriber become traceable.
03How to protect yourself
The best defense is a VPN that handles WebRTC: serious providers route STUN traffic through the tunnel too (re-run this page once connected to verify). Otherwise, browsers offer settings: Firefox can disable WebRTC (media.peerconnection.enabled in about:config), Brave has native blocking (“WebRTC IP handling policy”), and extensions like uBlock Origin can “prevent WebRTC from leaking local IP addresses”.
Disabling WebRTC entirely breaks in-browser video calls — prefer selective blocking, or a dedicated browser for sensitive activities. And remember the IP address is only one tracker among others: your user agent and your HTTP headers also feed your fingerprint.
04Frequently asked questions
My test shows the same IP everywhere: am I safe?
You have no WebRTC leak: the site cannot learn through WebRTC any address other than the one it already sees over HTTP. If you don't use a VPN, this is the expected result. If you do, it is the right result: the tunnel covers WebRTC traffic too.
WebRTC exposes an IPv6 while my HTTP connection is IPv4: is that a leak?
Not necessarily. Many connections are dual-stack: the page loaded over IPv4 but your machine also has a public IPv6, which STUN discovers. It is only a leak if that IPv6 does not belong to your VPN — compare the prefix with the address shown on our home page, with and without the VPN.
Why does the test show “WebRTC disabled”?
Your browser blocks the creation of peer-to-peer connections: a setting (Firefox media.peerconnection.enabled, Brave), a privacy extension, or a corporate policy. It is the safest setting privacy-wise, at the cost of in-browser audio/video calls.
Are the .local addresses a problem?
No, quite the opposite: they are mDNS pseudonyms generated by the browser to replace your real local addresses (192.168.x.x). The site sees a random identifier, useless for mapping your internal network. Every recent browser applies this protection.
Can a site run this test without my knowledge?
Yes — that is the whole problem. WebRTC candidate discovery requires no permission, no camera, no click: an invisible script is enough, exactly like this page's. This is why WebRTC leaks are used by ad networks and anti-fraud systems to de-anonymize VPN users.