Compare your public IP with WebRTC candidates to check possible VPN IP exposure. No camera access needed. The test contacts IP lookup and STUN servers.
Compare the public address seen by the web IP lookup with public WebRTC ICE candidates. A matching address, a different address and no public candidate are three different observations. Private addresses and .local names should not be interpreted as a public ISP address.
Compare the public web address with the public addresses gathered through WebRTC. The examples below explain possible observations; they are not a test of your current connection.
This does not establish that every application or protocol uses the VPN. Private addresses and .local candidates are not public ISP addresses.
Browser protection, a blocked STUN request or network conditions can prevent a public candidate. Repeat under comparable conditions; an empty candidate list does not prove a VPN is leak-free.
A different public address deserves investigation, but IPv4/IPv6 routing or multiple interfaces may also explain it. Run the test with your intended VPN settings. IP lookup and STUN services receive connection information; no camera or microphone permission is needed.
The WebRTC protocol supports real-time audio, video, and data over a peer-to-peer connection. ICE candidates describe possible network paths. A STUN server helps discover the address assigned to outgoing traffic by NAT. This test opens a dummy data channel with Google STUN; it does not request your camera or microphone and closes the connection after gathering.
A VPN IP leak can occur when a browser uses a route outside the intended VPN tunnel. Browser-only proxies may cover HTTPS traffic without covering UDP used by STUN. Comparing the public web address with a different public ICE address can reveal a possible bypass, but dual-stack IPv4/IPv6 routing and multiple interfaces can also explain a mismatch.
Private IP vs public IP matters: local addresses such as 192.168.x.x are not globally routable. Modern browsers may replace local addresses with mDNS hostnames ending in .local. Neither a private address nor an mDNS name proves your ISP address leaked. Missing candidates can mean privacy protection, a blocked STUN server, or incomplete gathering; they do not certify VPN security. IP checks also do not prevent browser fingerprinting.
Chrome: 1. Use a system VPN that covers UDP and both IP families. 2. If needed, install a trusted WebRTC privacy extension with an IP-handling policy that disables non-proxied UDP; Chrome has no universal built-in WebRTC off switch. 3. Restart affected tabs and repeat the test. Restricting WebRTC may break calls or screen sharing.
Firefox: 1. Open about:config and acknowledge the advanced-settings notice. 2. Search for media.peerconnection.enabled and set it to false to disable WebRTC. 3. Reload this page and test again; restore true when you need WebRTC calls. Managed browsers or some mobile versions may restrict access to this preference.
Brave: 1. Open Settings and search for WebRTC IP Handling Policy. 2. Select Disable Non-Proxied UDP. 3. Reload tabs and rerun the test with your VPN connected. This restricts routing rather than proving all possible leaks are blocked. Check your VPN provider’s guidance if communication apps stop working.
Compares the public lookup result with ICE candidates gathered through the browser WebRTC path.
Labels observed addresses by routability and explains why private addresses and mDNS names are not proof of an ISP leak.
Uses captured public candidates even after a timeout; missing public candidates or a missing comparison address remain inconclusive.
Run the check after enabling a VPN and repeat it after changing split-tunnel or WebRTC routing settings.
Investigate unexpected candidate behavior before using a peer-to-peer application, without requesting camera or microphone access.
Use the candidate list and limitations to report what the browser observed instead of claiming that every leak vector was ruled out.
| Input or option | Reference | What to check |
|---|---|---|
| ICE candidate | Connection candidate reported by WebRTC | Visibility depends on browser policy |
| mDNS | May conceal a local address with a .local name | Hostname is not a readable private IP |
| VPN comparison | Compare before and after connecting | One test is not a complete privacy audit |
No. Private browsing primarily separates browsing history and session storage. WebRTC can still gather network candidates, and extensions may be disabled in private windows unless explicitly allowed.
Websites normally see your VPN exit address for tunneled traffic. Split tunneling, uncovered IPv6 routes, or non-proxied WebRTC traffic can expose another address. A mismatch is a reason to inspect routing, not proof of your identity or physical location.
No. It describes the routes and candidates observed by this test. No public candidate makes the comparison inconclusive, while a matching public candidate only shows that no mismatch was observed on that route. A WebRTC check is separate from DNS leak testing, other application traffic and a full VPN security assessment.
Modern browsers can replace local ICE addresses with a temporary .local mDNS hostname to reduce local-network exposure. That name is not a public ISP address and cannot by itself demonstrate a leak.
No public candidates, or an unavailable detected address for an observed IP family, prevents a reliable comparison. A timeout alone does not make matching public candidates inconclusive. Repeat the test if no public route could be compared.
An internet connection is required. The site handshake sends a random challenge, not files or text inputs. Network diagnostics need external connections. IP checks contact Cloudflare and ipapi; DNS queries send the entered hostname to Cloudflare; WebRTC contacts ipify for IPv4 and IPv6 detection and Google STUN; latency probes contact the listed providers. Those services receive your connection address and may apply their own logging policies. Results are not saved by this tool.
Connect to the intended VPN location, run the test and compare the web IP result with any public WebRTC addresses. Repeat after changing one VPN or browser setting if you need a comparison. An unexpected public address deserves investigation; private candidates and mDNS .local names are not themselves evidence that the public ISP address was exposed.
Technical references: Cloudflare DNS JSON, ipapi fields, WebRTC candidate addresses, Brave IP handling.
