WebRTC Leak Test
Run a browser-side WebRTC ICE candidate check and see whether the current browser exposes public or local IP-style addresses through peer connection discovery. The tool uses RTCPeerConnection with public STUN servers and separates detected public-looking addresses from private LAN ranges.
This test will identify if your browser leaks your real IP address via WebRTC APIs.
Detected IP Addresses
Public WebRTC IPs
None detected
Local / Private IPs
None detected
DigitalDomainKit's WebRTC Leak Test checks what IP-style addresses the current browser exposes while gathering WebRTC ICE candidates. Select Run Leak Test, wait about five seconds, and the page lists detected public-looking WebRTC IPs separately from local or private IPv4 ranges.
The tool is useful when you want a quick browser-side check before or after changing a VPN, browser, extension, or privacy setting. It does not ask for a domain, file, account, or login. Instead, the active page creates a temporary RTCPeerConnection, adds a data channel, uses three Google STUN server URLs, listens for icecandidate events, extracts numeric IP address patterns from candidate strings, and displays the matches it can classify. A public result is marked as a potential leak because it may reveal an address different from the one you expected your browser to show.
What This WebRTC Leak Test Checks
WebRTC is the browser technology used for real-time peer-to-peer communication, including video calls, audio calls, screen sharing, and data channels. Before a WebRTC connection can work, the browser's ICE layer gathers possible connection candidates. Depending on browser policy, network routing, VPN behavior, and privacy protections, those candidates may include public addresses, local network addresses, relay addresses, or privacy-preserving hostnames.
This page focuses on one visible question: can JavaScript on this page see IP-style addresses in the browser's WebRTC candidate strings? If it can, the page displays them. If it cannot find matching addresses during the five-second window, it reports that no WebRTC IPs were detected and notes that the browser might be blocking WebRTC leaks. Treat that as a narrow result from this implementation, not a promise that every privacy setting is correct.
How To Use The Tool
- Open the WebRTC Leak Test page in the browser profile you want to check.
- If you are testing a VPN, connect to the VPN first and confirm it is using the location or exit server you intended.
- Select Run Leak Test. The button changes to a testing state while the browser gathers candidates.
- Wait for the status to change from Scanning for WebRTC leaks... to Analysis complete., or for the no-detected-IPs message after the timeout.
- Review Public WebRTC IPs. Any entry here deserves comparison with the public IP you expected to expose.
- Review Local / Private IPs. These are private LAN-style addresses such as
10.x.x.x,172.16.x.xthrough172.31.x.x,192.168.x.x, or link-local169.254.x.x. - Repeat the check after changing VPN servers, browser settings, WebRTC controls, or extensions so you can compare the visible result.
Inputs, Outputs, And States
| Area | Verified behavior | Important caveat |
|---|---|---|
| Input | No typed input is required. The only action is selecting Run Leak Test. | The result belongs to the current browser, profile, permissions, extension set, network route, and VPN state. |
| Browser API | The page calls RTCPeerConnection, creates an empty data channel, creates an offer, and sets the local description. |
If the browser disables or restricts WebRTC, candidate gathering may fail or return no visible IP-style candidates. |
| STUN servers | The inspected implementation uses stun:stun.l.google.com:19302, stun:stun1.l.google.com:19302, and stun:stun2.l.google.com:19302. |
STUN traffic can reveal network information to the STUN service as part of normal candidate discovery. This is not an offline-only check. |
| Public output | Numeric IP matches that are not recognized as private IPv4 ranges are shown under Public WebRTC IPs with a Potential Leak badge. | A public entry is not automatically your home ISP address. It may be a VPN exit, mobile carrier address, IPv6 address, proxy route, or another address exposed by the browser's ICE stack. |
| Local output | Private IPv4 and link-local ranges are shown under Local / Private IPs with a Local badge. | The current extractor does not reliably display mDNS hostnames, and it does not enumerate every network interface outside candidate strings. |
| Timing | The page finalizes the visible result after about five seconds. | Slow candidate gathering, blocked STUN, captive portals, strict firewalls, or browser policy changes can produce sparse results or no result. |
| Error state | If initialization fails, the status shows Error initializing WebRTC: followed by the browser error message. |
The page does not provide a deeper diagnostic log, packet capture, DNS comparison, or VPN tunnel inspection. |
How To Read Public And Local Results
A public WebRTC IP is the most important result to review. If you are not using a VPN or proxy, seeing your normal public IP may simply confirm that WebRTC can discover the address your network already uses. If you are using a VPN, compare any public WebRTC IP with the VPN exit IP you expect. A mismatch can indicate that WebRTC is exposing an address outside the VPN path, but it still needs confirmation with your VPN client, operating system network settings, and another independent leak test.
A local or private IP is different. Addresses beginning with 10., 192.168., 172.16. through 172.31., or 169.254. are not normally routable on the public internet. They can still reveal information about your local network shape, such as whether you are on a home router, office LAN, virtual adapter, or link-local interface. Modern browsers often reduce this exposure by replacing private host addresses with mDNS names, which means a page may see a generated .local hostname instead of the raw private address.
The current DigitalDomainKit implementation extracts numeric IPv4 values and a narrow full-form IPv6 pattern from raw candidate strings. That means it is good for quick visible candidate checks, but it can miss privacy-protected mDNS hostnames, compressed IPv6 notation, unusual candidate formats, and any address hidden by browser policy. A blank result is therefore best read as "this page did not detect matching IP strings during this run."
Privacy And Network Notes
The visible WebRTC analysis runs in your browser. No form value is typed, and the inspected tool code does not send the detected candidate list back to a DigitalDomainKit tool endpoint. However, the page itself is a normal website page, so ordinary page loading, advertising, analytics, caching, and browser history behavior can still apply. The site also loads Google Analytics globally, and this specific test uses public Google STUN server URLs to gather candidates.
Do not describe this as a completely private or offline-only test. WebRTC candidate gathering is a network operation, and STUN is designed to help a browser learn how it appears across NAT and routing boundaries. If you are working in a highly sensitive environment, use a controlled lab setup, review browser and VPN documentation, and avoid running web-based diagnostic pages on networks where contacting external STUN services is not permitted.
False Positives And False Negatives
A result can look alarming when it is actually expected. For example, a VPN user may see a public WebRTC IP that belongs to the VPN exit server rather than the residential ISP. A user on a mobile connection may see carrier-grade NAT behavior that does not identify a precise device. An IPv6 address can also be misread if you do not know whether your VPN handles IPv6 traffic or whether the browser is exposing a temporary privacy address.
The opposite can also happen. A clean-looking result can miss a problem because the browser masked local addresses with mDNS, the regular expression did not match the candidate format, a firewall blocked STUN only during the test, candidate gathering took longer than the five-second window, or the browser exposed a route that this page does not parse. Use this page as a first-pass signal, not as the only evidence for a privacy or security decision.
What This Tool Does Not Do
This is not a DNS leak test. It does not create unique DNS hostnames, compare resolver ownership, inspect system DNS settings, or determine whether DNS queries are leaving a VPN tunnel. It is also not a full VPN audit, traffic capture, firewall test, malware scan, identity proof, or anonymity guarantee. The result only describes the WebRTC candidate strings this page could see in the current browser session.
The page does not ask your VPN provider for status, does not verify the owner of an IP address, does not perform IP geolocation, and does not show TURN relay details. It marks public-looking addresses as potential leaks because they deserve attention, not because the page can prove who owns the address or whether it is personally identifying in your situation.
Practical Example Workflow
For a VPN check, first run the test with the VPN disconnected and note whether your normal public or local addresses appear. Then connect the VPN, refresh the page, and run the test again. The second run should be compared against the public IP shown by your VPN client or by a separate public IP lookup. If the WebRTC public result still shows your non-VPN ISP address, investigate the VPN's WebRTC protection, split-tunnel settings, IPv6 handling, browser profile, and any extensions that modify peer connection behavior.
When documenting a result, record the date, browser name and version, operating system, VPN state, VPN server location, and whether the Public WebRTC IPs and Local / Private IPs sections were empty or populated. Avoid pasting real personal IP addresses into shared tickets unless the recipient needs them. For public examples, use documentation ranges or redact the last octet.
Troubleshooting
| Problem | Likely cause | What to try |
|---|---|---|
| The page says no WebRTC IPs were detected. | The browser may be masking candidates, blocking WebRTC, returning mDNS hostnames, or preventing STUN from completing. | Try another browser profile, review WebRTC settings, temporarily disable privacy extensions for a controlled test, or compare with your VPN provider's recommended leak test. |
| A public IP appears while connected to a VPN. | The address may be the VPN exit, or it may be traffic outside the VPN route. | Compare it with the VPN app's exit IP and a separate public IP lookup. If it differs, review split tunneling, IPv6, and WebRTC protection settings. |
| Only local addresses appear. | The browser exposed private host candidates but no public server-reflexive candidate matched during the test. | Decide whether local network exposure matters for your threat model, then review mDNS/WebRTC privacy controls in the browser. |
| The button shows an initialization error. | RTCPeerConnection may be unavailable, disabled, blocked by policy, or interrupted by a browser extension. |
Update the browser, test in a clean profile, and check enterprise policies or privacy extensions that disable WebRTC APIs. |
| Different tools show different answers. | They may use different STUN servers, parse mDNS differently, wait longer, inspect additional APIs, or run from a different network vantage point. | Compare the methods before treating one result as final. Prefer tools that explain whether they test WebRTC, DNS, IPv6, and public HTTP IP separately. |
Related Privacy And Network Tools
IP Information Lookup helps identify the approximate network and location metadata associated with a public IP address you choose to investigate after a WebRTC result.
Browser Fingerprint Audit shows other browser-visible signals, such as user agent, screen, hardware, canvas, and audio indicators, so you can separate WebRTC exposure from broader fingerprinting behavior.
Hostname to IP Lookup resolves a hostname to IP addresses when you need to compare DNS resolution with the network address shown elsewhere.
IP to Hostname Lookup performs the reverse lookup companion check for a public address that appears in logs or diagnostic output.
DNS Lookup is useful when your investigation moves from WebRTC candidates to normal DNS records such as A, AAAA, MX, TXT, or CNAME values.
Technical Method And References
Digital Domain Kit maintains this tool page. The verified implementation reviewed on September 16, 2026 is a browser-side Alpine component in resources/views/modules/tools/webrtc-leak-test/view.blade.php. It uses RTCPeerConnection, createDataChannel(''), createOffer(), setLocalDescription(), and the onicecandidate handler. It searches each candidate string with a regular expression for IPv4 or full-form IPv6-like patterns, classifies private IPv4 ranges as local, and finalizes the visible result after five seconds.
For background on the browser APIs and privacy model, see MDN's documentation for the RTCPeerConnection icecandidate event, MDN's notes on the RTCIceCandidate address property, RFC 8828: WebRTC IP Address Handling Requirements, and the IETF draft on using mDNS to protect privacy when exposing ICE candidates. To report a problem with this tool page, use the DigitalDomainKit contact page.