A guide to WebRTC leak testing
An IP address is not, by itself, a leak. Check where it came from and whether the connection used the network exit you intended.
What is a WebRTC leak?
WebRTC lets browsers exchange real-time audio, video and data. To establish a connection, a browser gathers possible network addresses, known as ICE candidates.
If you expect traffic to use a VPN or proxy, WebRTC may still expose an address through another network path. The useful comparison is between its public address and your web connection’s exit address within the same IP version.
Compare IPv4 with IPv4, and IPv6 with IPv6.
How to read your result
The verdict uses addresses actually observed in this test. Missing evidence is not treated as proof of safety.
- Leaked
- WebRTC exposed a public address that differs from your web exit within the same IP version. This is an exit discrepancy to investigate; it does not, on its own, prove that the address is your home IP.
- Local IP exposed
- The browser returned a private or local network address. This is distinct from exposing a public IP: local addresses are generally not directly routable on the internet, but can reveal some internal network information.
- Not leaked
- The comparable public candidates matched the web exit and did not trigger another address-exposure finding. This applies only to what this test observed, not to every connection or application on your device.
- Inconclusive
- The test may have only mDNS names, no candidates, no trusted exit baseline, or IPv4/IPv6 addresses that cannot be paired. An unsupported browser or failed test must not be interpreted as a safe result either.
Found a discrepancy? Check these four things
A connected VPN does not guarantee every connection follows the same path. Browser proxies, split tunneling and IPv6 support can all affect the result.
Identify your intended exit
Check the VPN or proxy location you selected, then compare the web exit and WebRTC public addresses above. Separate IPv4 from IPv6 before comparing them.
Review proxy coverage and IPv6
Check whether you are using a device-wide VPN, an application proxy or a browser-only proxy. Review split-tunnel rules and IPv6 handling. Proxying web requests does not necessarily cover WebRTC connections.
Adjust WebRTC policy only as needed
Prefer your VPN’s leak protection or a supported browser network policy. There is no universal switch across browsers. Restricting WebRTC can affect video meetings, voice calls and real-time collaboration.
Retest and cross-check
After changing settings, reopen the page or run the test again and compare the addresses. Check DNS separately for another view of your connection. One green verdict is not a complete privacy assessment.
How does CHA.LA run this test?
The page creates a temporary RTCPeerConnection in your browser and uses a data channel to trigger ICE candidate gathering. When configured and available, STUN services help observe network addresses. The temporary connection is closed after collection.
Candidates are classified as public addresses, local addresses or mDNS names. Public candidates are compared with trusted addresses from the current web request and exit probes, separately for IPv4 and IPv6. This check does not require camera or microphone access.
Frequently asked questions
Practical answers about VPNs, browser settings and differences between test results.
Does seeing an IP address while using a VPN mean it leaked?
No. A website and WebRTC can both see your VPN’s exit IP, which is expected. Look for an unexpected public address and compare addresses within the same IP version. Even a mismatch needs context such as split tunneling, dual-stack networking and VPN configuration.
Should I worry about a 192.168.x.x or 10.x.x.x address?
These are usually private network addresses. Seeing one does not mean an internet visitor can connect directly to your device. It can reveal some network structure, however, so CHA.LA reports local address exposure separately from a public IP leak.
Why do I see a .local address or an inconclusive result?
A browser can replace a local address with an mDNS hostname, and a network can restrict candidate gathering. Without enough public candidates and a trusted exit baseline, the test cannot complete the comparison. Collecting no address is not the same as verifying that no address leaked.
Why do different testing websites disagree?
Tests can use different STUN services, collection times, exit baselines and IPv6 support. Browser versions, network changes and VPN split tunneling can also affect collection. Compare the actual addresses and reasoning under the same conditions, not just the labels.
Does the test work on mobile? Does it need camera access?
Mobile browsers that support WebRTC can usually run the check, but address visibility depends on browser and operating-system policies. This check uses a data channel and does not need camera or microphone access.
Will disabling WebRTC break normal browsing?
Ordinary web browsing usually does not need WebRTC, but browser-based video meetings, voice calls and some collaboration features may stop working. Choose a restriction that fits your needs, then verify the applications you use instead of disabling it only to change a test label.
Is a WebRTC leak the same as a DNS leak?
No. A WebRTC test checks network addresses exposed by real-time connection setup. A DNS test observes the resolvers handling domain lookups. They examine different paths, so passing one check does not establish that the other path is configured as intended.