How to run the WebRTC leak test
The WebRTC leak test shows address candidates exposed by this browser and compares public candidates with HTTP reference addresses. Start it after your connection is ready, then read the status and individual observations together. A changed address deserves investigation, but a browser measurement cannot certify every application or every route on your device.
Before running the WebRTC leak test, decide what you expect to observe. If you use a VPN, note its selected server and whether its documented protection covers this browser, UDP traffic, and IPv6. If you are simply exploring a home connection, an ordinary public address is expected. Visibility alone does not establish that a protective feature failed.
Select Run WebRTC leak test. The browser contacts Cloudflare's public STUN endpoint and separate ipify HTTP endpoints for IPv4 and IPv6. These services receive the source addresses used to contact them. The test requests no camera or microphone access, creates no call with another person, and sends no candidate report to our application server. Provider documentation identifies the Cloudflare STUN endpoint used here.
Allow up to twelve seconds. You can stop the WebRTC leak test at any time; observations already collected may remain, clearly marked as partial. Keep the network unchanged during a run. Switching Wi-Fi, VPN servers, or mobile connections halfway through can produce references from different moments and make the comparison harder to interpret.
When the WebRTC leak test finishes, inspect the summary, HTTP references, and expandable candidate details. Clear the WebRTC leak test results before sharing your screen. If you copy a report, it includes observed addresses, including any local addresses exposed by the browser. Review it before sending it to a support team or posting it publicly.
Read the WebRTC leak test evidence
The WebRTC leak test distinguishes three summary outcomes. A different public address means a readable, non-relay public candidate differed from an available HTTP reference of the same address family. No difference observed means candidate gathering finished without reported STUN errors, and all observed public candidates that we compare matched their references. Inconclusive means the available evidence does not meet those conditions.
Neither a reassuring summary nor a warning should be read in isolation. The WebRTC leak test may observe a legitimate second interface, an expected VPN exit, or a different path selected by a proxy. To call a difference an unwanted disclosure, you need to know which addresses belong to the network you intended to protect and what your chosen configuration promises.
HTTP references are collected afresh for each WebRTC leak test. We compare IPv4 candidates with the IPv4 reference and IPv6 candidates with the IPv6 reference. Comparing an IPv4 string against an IPv6 string would always produce a difference and would be meaningless. When a same-family reference is missing, the corresponding candidate is marked as uncomparable rather than treated as matching.
In the WebRTC leak test, candidate details show the browser's reported type, transport, address scope, and any readable related address. A public related address may also contribute to the comparison. A related address of 0.0.0.0 or :: is an unspecified placeholder, so it is not presented as a discovered network address. The report does not retain the complete session description or its temporary connection credentials.
Candidate types in a WebRTC leak test
A host candidate describes an interface address made available by the browser. It can be private, public, or represented by an mDNS hostname. A server-reflexive, or srflx, candidate describes an address learned through a STUN interaction. Peer-reflexive, or prflx, candidates are associated with connectivity checks, while a relay candidate refers to a relay service. See the browser candidate type definitions.
This WebRTC leak test configures STUN, not a TURN relay or a remote peer. Its parser still distinguishes relay candidates so that a relay address is never automatically classified as an unexpected subscriber address. A TURN server has its own address; treating that normal difference as a leak would confuse the purpose of relaying.
The WebRTC leak test also recognizes browser-generated .local names. These conceal a literal interface address in the candidate exposed to JavaScript. We do not resolve those names or infer a hidden address from them. A private address such as 192.168.1.20 describes a local addressing context; it is not your public internet exit and does not identify a unique household worldwide.
WebRTC leak test timeouts and error codes
A WebRTC leak test timeout means our time limit ended before gathering reported completion. It does not prove that your browser lacks WebRTC, that a VPN is working, or that the STUN service is down everywhere. Some candidates may already be visible. The summary remains limited by the incomplete run even if one observed address matches its HTTP reference.
An ICE error code can refer to a particular attempt or network path. Code 701 indicates that a STUN or TURN server could not be reached through the relevant candidate path; another attempt can still yield a candidate. We preserve the code rather than converting it into a claim about your VPN. Browser support for these events also varies. ICE error event documentation
If a WebRTC leak test has no readable public candidates, the correct conclusion is that this run did not provide that comparison. Restrictions, address concealment, network filtering, or endpoint reachability can all affect what appears. A blank list is evidence about this observation, not a universal privacy guarantee.
What the WebRTC leak test cannot establish
The WebRTC leak test measures one browser context through specific endpoints. Browser policies, installed extensions, operating-system routes, proxies, and VPN settings can change the available candidates. A browser proxy may affect HTTP while real-time traffic follows a different permitted route. The WebRTC IP address handling requirements explain why browser address exposure involves both connectivity and privacy choices.
This WebRTC leak test does not identify the recursive DNS servers used for every lookup. It is not a DNS leak test, malware scanner, firewall audit, or traffic capture. It also does not test applications running outside this tab. Use the IPv6 test to inspect protocol-specific HTTP reachability and the public versus private IP guide to interpret local address ranges.
No location database participates in the WebRTC leak test comparison. A candidate's country or city cannot determine whether it is expected: location estimates can be stale, and VPN exit addresses can change. If ownership matters, examine the address through IP lookup or ASN lookup, then verify it against information from your network or VPN provider.
Investigating a WebRTC leak test difference
First rerun the WebRTC leak test without changing networks. Confirm that the same difference repeats and that both observations belong to the same address family. Record the selected VPN location, time, browser, and relevant settings without publishing account details. A repeatable difference is easier to discuss with support than a single unexplained screenshot.
Next review the intended routing policy. Split tunneling may deliberately exclude an application or traffic category; a browser extension and a system VPN can have different coverage. Avoid disabling protections merely to produce a cleaner result. If you make an intentional configuration change, run a new WebRTC leak test and compare the observations in context.
For support, a WebRTC leak test report is a starting point. Explain which address was expected and which was unexpected. Remove local addresses and other unnecessary details before public sharing. The site's IP privacy guide explains why address visibility, precise identity, and an exploitable service are separate questions.
WebRTC leak test questions
Does a WebRTC leak test match mean my VPN is secure?
No. A WebRTC leak test match means the compared public candidates and HTTP references matched in this run. It says nothing conclusive about DNS routing, other applications, future network transitions, or the provider's wider privacy practices. Keep the test's scope attached to any saved result.
Why does another browser show different results?
Browsers can expose different candidate sets under their own privacy policies and configurations. Run the WebRTC leak test separately in each browser you actually use. Do not apply one browser's outcome to another, especially when only one has a VPN extension, managed policy, or different permissions.
Does this tool remember my address history?
The WebRTC leak test keeps its candidate report in the current page state. Clearing results removes that display; leaving the page ends any active collection. Copying is an explicit action that puts the report on your clipboard. Cloudflare and ipify independently process the requests sent to their endpoints; the absence of a stored report here does not describe those providers' retention policies.
Can I run it without JavaScript?
The explanation remains readable, but the WebRTC leak test requires browser JavaScript and the peer-connection API to collect candidates. If the API is unavailable, the tool reports that limitation. Your ordinary HTTP address can still be checked from the homepage, which serves a different, simpler observation.
MyIP.dog