Running the WebRTC Leak Test
Select Start test and wait for candidate gathering to finish. The page creates a temporary WebRTC connection and examines the connection candidates supplied by the browser. Those candidates describe possible network paths; collecting one does not mean that a call actually used that path.
The connection IP address is the public address observed when this page was requested. WebRTC candidates are collected separately. Comparing these two sources can reveal an address that ordinary web traffic and WebRTC expose differently, which is especially relevant when checking a VPN or browser proxy.
Keep your network and VPN connection unchanged during a test. If you switch networks or reconnect a VPN, refresh the page before starting another comparison. Run test again gathers a new set of candidates, but refreshing also updates the page request used as the comparison baseline.
Interpreting a Different Public Address
A different public IP address detected means at least one candidate differs from the address used to reach the page. Examine whether that address belongs to a network you intended the browser to expose. The result identifies a difference; it does not automatically identify the address as your home connection or prove that a VPN has failed.
IPv4 and IPv6 addresses can both be public. An IPv4 address cannot be matched directly with an IPv6 address. Compare each public candidate with an expected address from the same family; an address from the other family needs a separate comparison. A different address alone does not show that traffic bypassed a VPN.
No different public IP address detected means the available public candidates matched the comparison address. That conclusion applies to this test and the candidates supplied by this browser. It is not a guarantee about every application, every future connection, DNS requests, or all traffic passing through a VPN.
Local and Hidden Candidates
Browsers can replace local IP addresses with temporary mDNS names. The result groups these as hidden candidates and explains that hiding local addresses is a normal privacy measure. A hidden candidate is not presented as a confirmed public IP address.
The count represents candidates, not devices. One device can provide several candidates through different interfaces or connection options. Local, reserved, and uncertain addresses are kept separate from the public addresses used for comparison. Do not interpret the count as a list of other computers on the network.
Some browsers or network policies expose few candidates or none at all. If no usable public address is available, the page reports that it cannot complete the comparison. Finding no public candidates is not proof that there is no possible leak.
Unavailable and Incomplete Results
Not supported means WebRTC connections are unavailable in the browser or the feature has been disabled. A browser error, extension, network restriction, or unavailable test service can also prevent a useful result. These conditions are not treated as a successful privacy check.
If the page cannot identify the public IP address used to reach it, the test has no address to compare with the candidates. No result means that the comparison is unavailable; it does not mean that the connection is protected.
Wait until the test finishes before selecting Copy results. The copy action includes the status, baseline address, public candidates, matching and different addresses, and the local or hidden candidate summary. Browser information opens the separate report of browser capabilities; it does not change the WebRTC result.
Using the Comparison
If an unexpected public address appears, record the test conditions and check the VPN or proxy settings relevant to WebRTC traffic. A browser proxy and a system-wide VPN can cover different traffic. Repeat the comparison after an intentional configuration change, keeping the before and after results separate.
