Guide
What WebRTC reveals about your network address to a web page
WebRTC is the technology behind browser video calls, screen sharing and peer-to-peer file transfer. To connect two browsers directly it needs to know each one’s network addresses, and any web page can ask for them without a permission prompt. That behaviour is the reason a VPN can fail to hide your address. The test shows what a page could learn in your current browser.
How WebRTC finds addresses
Before a call, each browser gathers a list of ICE candidates, possible ways to reach it. A host candidate is an address on one of the computer’s own interfaces, such as a LAN address. A server-reflexive (srflx) candidate is the public address as seen from the Internet, which the browser learns by sending a request to a STUN server and reading the reply. Traffic through a VPN uses the tunnel, but the STUN request can leave over the normal interface in some configurations, so the page learns the real public address next to the VPN’s.
What the test does
Pressing the button makes your browser open a WebRTC connection attempt that contacts Google’s public STUN server, stun.l.google.com, to collect candidates. It also asks api4.ipify.org and api6.ipify.org which IPv4 and IPv6 address ordinary websites see. Those services receive your IP address as every site you visit does; nothing is sent to openWorkstand. The results show each candidate with its type and a plain explanation, then the addresses websites see, and a verdict comparing the two.
Reading the results
A line with a random identifier ending in .local and type host is a local address hidden by mDNS obfuscation: the browser protects the private address. A srflx line is a public address learned from the STUN server. If it matches the address websites see, the page says that is normal without a VPN, and warns that with a VPN you expected, it is not working. If the srflx address differs from what websites see while a VPN is on, WebRTC has exposed your real address. IPv6 candidates are separate: an IPv4-only VPN does not protect them.
A worked example
On a home connection without a VPN, a test typically shows two host candidates with random .local names and two srflx candidates, one IPv4 and one IPv6, both public addresses; the “addresses websites see” line shows the same IPv4 and IPv6 pair, and the verdict reads that the public address WebRTC reports matches the one websites see, which is normal without a VPN. With a working VPN the websites line shows the VPN server’s address and, if the WebRTC line shows your ISP’s, you have a leak.
Limits
Results depend on the browser, its settings and extensions. Some browsers can restrict WebRTC to the default route, and privacy extensions can block it; the test then shows fewer or no candidates. Headless and corporate networks that block UDP or STUN also produce no public candidate, which is not the same as a leak-free VPN. The test covers WebRTC only. To check IPv6 reachability itself use the IPv6 Test, and to create your own tunnel see the WireGuard Config Generator.
Related tools
- IPv6 Test shows whether your connection reaches IPv6-only servers.
- WireGuard Config Generator builds a VPN whose leaks you can test.
- Private IP Checker tells whether a candidate address is private or public.
- Reverse DNS Lookup shows the host name behind a public address.
Checked against the current version of the WebRTC Leak Test on .