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 exposure
Seeing a public candidate above? Here's how to disable WebRTC →
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.
What this means for you
This block turns the result into plain language: what the finding does and does not show, and what to do next.
Nothing has been checked yet.
Direct answer
WebRTC Leak Test checks browser WebRTC candidates and labels public, private, relay, and masked signals when available. A low-review result means no public candidate was observed in this test, not that every browser or app path was verified.
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. |
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 a literal public IP candidate in this browser session. This is useful, but not a complete privacy guarantee.
Only private, local, link-local, carrier-grade NAT, or mDNS-masked candidates appeared. These are not public IP candidates by themselves.
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.
Mobile browsers can differ by OS WebView, per-app VPN, Private DNS, Wi-Fi versus mobile data, and browser profile. Retest on the exact mobile browser and network you use.
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.
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.
Checks browser WebRTC candidate signals for public and local network hints.
The page asks the browser for ICE candidates and reports what came back. A public candidate means this browser was willing to hand that address to a peer. No public candidate means none appeared in this test, in this browser, at this moment.
WebRTC is a browser technology used for video calls and peer-to-peer connections. To establish a connection, it needs to gather your real IP addresses — including ones behind a VPN or proxy. A WebRTC leak happens when your browser exposes your real IP through WebRTC even though your traffic routes through a VPN. This works in Chrome, Firefox, Edge, and Safari without any plugins.
Most VPNs do not block WebRTC leaks by default. The WebRTC API runs inside the browser and can bypass the VPN tunnel to find your real public IP. Some VPNs (Mullvad, IVPN) ship browser extensions specifically to block this. Otherwise, you need to disable WebRTC in the browser manually or use a browser extension like uBlock Origin (which can block WebRTC).
In Firefox: go to about:config and set media.peerconnection.enabled to false. In Chrome and Edge: use an extension like uBlock Origin (enable "Prevent WebRTC from leaking local IP addresses" in its settings). In Brave: go to Settings → Privacy → WebRTC IP handling policy → Disable non-proxied UDP. Safari blocks WebRTC by default in most versions. Full guide: How to Block WebRTC IP Leaks.
If the test shows a public IP that does not match your VPN server's IP, you have a WebRTC leak. If the test only shows a local IP (like 192.168.x.x or 10.x.x.x), that is normal — local IPs are not routable on the public internet and do not reveal your identity. Only a public IP that differs from your VPN exit IP is a real leak.
Chrome, Firefox, and Edge all expose WebRTC by default and can leak your real IP through a VPN. Brave blocks cross-origin WebRTC requests by default. Safari has partial WebRTC support and does not expose the real IP in most configurations. If privacy is critical, test your specific browser every time you update it — browser behavior can change between versions.