Run a WebRTC leak test to see whether ICE candidates reveal public, local, private, limited, or mDNS-masked address signals from your current browser session.
WebRTC behavior depends on your browser, settings, extensions, operating system, network, and VPN configuration. Local or limited candidates are not the same as public IP exposure, and this test does not prove all WebRTC risk is absent.
WebRTC exposure
Short answer
Modern browsers may show mDNS or local candidates that are not the same as a public IP leak. The higher-risk signal is a public candidate that matches your real ISP, mobile carrier, office, or non-VPN route while you expected VPN traffic.
| Observed candidate | What it usually means | What to compare |
|---|---|---|
| mDNS masked host | Often normal modern browser behavior. | Compare Chrome/Firefox and VPN state. |
| Local/private candidate | May reveal local network shape but not necessarily public IP. | Check browser privacy settings and app requirements. |
| Public VPN candidate | The browser may expose the VPN-facing route. | Document the route and run DNS/IPv6 checks. |
| Public ISP candidate | Higher-priority review while VPN is connected. | Check VPN split tunnel, proxy extension, IPv6, and browser profile. |
WebRTC test checklist
Run the WebRTC leak test in the same browser profile you actually use, then repeat it after changing VPN, proxy, extension, or browser privacy settings. The important signal is whether WebRTC exposes a public candidate that differs from the route you expected.
mDNS-masked and local candidates are common in modern browsers. Public ISP or mobile-carrier candidates deserve closer review when a VPN is connected.
Use DNS Leak Test, IPv6 Leak Test, and VPN Leak Test to see whether the same route appears elsewhere.
Change one browser, extension, VPN, or split-tunnel setting at a time so the before/after result is easy to trust.
A WebRTC flag means the browser surfaced a visible signal in this session. Receipt copy, share, and PNG export use safe categories and remove raw candidate strings before export. Read the methodology.
See what Safe Copy includes before sharing or saving a result.
Combine IP, WebRTC, IPv6, DNS leak, fingerprint, user-agent, and related privacy signals in one report.
Result meanings
WebRTC ran without exposing literal public or local IP candidates. The browser may have masked host candidates with mDNS.
Only private, local, link-local, or carrier-grade NAT candidates appeared. These can still reveal network shape to websites.
A public IPv4 or IPv6 candidate was visible. Compare it with your expected VPN or network route and retest after changes.
The browser did not provide RTCPeerConnection, or a policy or extension blocked the API before the test could begin.
The browser supported the API, but candidate gathering timed out, errored, or returned too little data to classify reliably.
Browser fixes
Settings and policy names change over time, so treat these as a checklist to verify in your current browser, VPN app, and operating system.
Check privacy extensions or enterprise policy controls for WebRTC local IP handling, then restart the browser and rerun this test. For the browser-specific path, open the Chrome WebRTC leak test.
Edge uses Chromium WebRTC behavior. Review browser privacy settings, managed WebRTC local IP policies, and VPN leak-protection settings.
Advanced users can review about:config WebRTC preferences such as media.peerconnection.enabled. Disabling WebRTC can break calls and peer-to-peer apps.
Open Brave privacy settings and review the WebRTC IP handling policy. Choose a stricter option when you do not need local network discovery.
Keep Safari and the operating system updated, review website permissions, and retest after VPN or network changes. Safari exposes fewer direct WebRTC toggles.
Review the specific browser's site permissions, VPN app leak protection, split-tunneling settings, and private DNS settings, then test again on mobile data and Wi-Fi.
iOS browsers rely on WebKit behavior and have fewer extension-level WebRTC controls. Test each browser profile after changing VPN, relay, or network settings.
Methodology
The page creates a temporary RTCPeerConnection, opens a data channel, and asks the browser to gather ICE candidates using stun:stun.l.google.com:19302. MyIPScan classifies literal public candidates, private or local candidates, and mDNS-masked candidates locally in the browser.
This does not inspect VPN traffic outside the browser, does not audit every app on the device, and can change with browser, OS, VPN, network, and STUN behavior. For the broader diagnostic model, read the MyIPScan methodology.
Related tools
Related guides
Before / after privacy flow
This page is focused on public, local, private, limited, and mDNS-masked WebRTC candidates. Run the WebRTC candidate check first, then use Public Exposure Report to compare it with IP, DNS, IPv6, and fingerprint signals. Results are visible browser/session signals, not a certification.
Status language
These labels keep the result understandable without implying a VPN, browser, device, or account is safe.
A browser/session signal was visible and should be compared with what you expected.
The observed signal appears consistent with the stated route or browser behavior.
The signal may need closer review before relying on this setup for the current session.
The check ran, but this page cannot cover every app, device route, server, or future connection.
The tested signal was not observed in this browser/session.
The signal has not run yet or the browser did not provide enough data.
Fix checklist
Settings names change. Treat this as a route to verify, then rerun the focused check and the Public Exposure Report.
Check WebRTC
Browser ICE candidate behavior, including public candidates, local/private candidates, IPv6 candidates, and mDNS-masked candidates surfaced in this session.
Limits
It cannot audit every app, VPN route, browser extension, OS network rule, STUN behavior, or future session outside this browser test.
Read results
A good result means no unexpected public WebRTC candidate appears for the non-VPN route you were trying to avoid. Local and mDNS-masked candidates need context before concern.
Warnings
A warning means the browser exposed a candidate that may deserve review, especially if it matches an ISP, office, mobile, or non-VPN route.
Fix path
Compare the result with the VPN and DNS tests, then review browser WebRTC settings, extensions, VPN leak protection, and profile-specific behavior.
Retest
Retest after browser updates, extension changes, VPN reconnects, network switches, or WebRTC privacy setting changes.