WebRTC Leak Test
WebRTC can expose IP addresses through STUN even when you use a VPN. Click Start scan to see what this browser reveals. ICE gathering runs locally; only the optional HTTP IP row contacts a public IP echo service for comparison.
How to use
- Connect or disconnect your VPN depending on what you want to verify, then open this page in the browser you use daily.
- Click Start scan and wait a few seconds while ICE candidates are gathered through Google STUN.
- Read Public IP (WebRTC srflx) first — with VPN on, it should match your VPN exit, not your ISP.
- Compare HTTP public IP with the WebRTC row; mismatches deserve a closer look.
- Check Local IPv4, IPv6, and mDNS rows for extra exposure.
- Use Copy results for support tickets or VPN provider reports, then Scan again after changing browser settings.
FAQ
What is a WebRTC leak?
WebRTC can discover your device IP addresses by talking to STUN servers over UDP. That path is separate from normal VPN-tunneled web traffic, so your real IP may appear even while a VPN icon shows connected.
Does this test upload my IPs to your server?
ICE gathering runs locally in the browser. The HTTP public IP row optionally calls a third-party echo service (ipify) from your browser for comparison — not stored on our servers.
I use a VPN — what should I expect?
Both HTTP public IP and WebRTC srflx should show your VPN exit address. If WebRTC shows your home ISP IP while HTTP shows VPN, you likely have a WebRTC leak.
Why does Chrome show mDNS instead of 192.168.x?
Modern Chrome hides literal local IPs behind randomized *.local hostnames in ICE candidates. That is intentional privacy hardening — not a leak of your exact LAN address.
Is seeing any IP always bad?
Without VPN, exposing a public IP via WebRTC is normal. The test is most meaningful when you expect anonymity from VPN, Tor, or strict browser privacy modes.
How do I fix a WebRTC leak?
Use a VPN client with WebRTC leak protection, browser extensions (e.g. WebRTC Network Limiter on Chromium), Firefox's media.peerconnection.enabled=false for extreme cases, or a browser with built-in WebRTC policies (Brave, hardened Firefox).
Introduction
WebRTC Leak Test shows which IP addresses your browser exposes through WebRTC, independent of ordinary page loads. That matters because video calls (Meet, Zoom web, Discord), peer-to-peer features, and some trackers can use the same mechanism.
If you rely on a VPN for privacy, this test answers: “Does WebRTC bypass my VPN and reveal my real ISP or LAN address?”
The scan uses RTCPeerConnection with a public STUN server (stun.l.google.com) — the same family of technique used by real-time apps, not a simulated check.
Understanding each output row
Below is what every field on the results panel means, including normal, concerning, and VPN-specific cases.
1. Public IP (WebRTC srflx)
What it is: The server reflexive IPv4 address ICE learns from STUN. Think of it as “what WebRTC thinks your public IPv4 is” for peer connections.
How it appears: Candidate lines contain typ srflx with a public-looking IPv4 (not 10.x, 192.168.x, or 172.16–31.x).
| Scenario | Example output | How to read it |
|---|---|---|
| No VPN, normal home broadband | 203.0.113.45 |
Expected — matches what many sites would infer for WebRTC |
| VPN working for WebRTC | Same IP as your VPN city/server | Good — WebRTC is using the VPN path |
| VPN leak | Your US ISP IP (e.g. Comcast in Denver) while VPN claims New York | Bad — WebRTC bypassed VPN; sites can deanonymize you |
| VPN on but no srflx gathered | None detected |
ICE may be blocked, delayed, or UDP filtered — inconclusive, scan again |
| Corporate network / CGNAT | Shared carrier IP | Public but not unique to you; still valid for WebRTC |
Key point: Compare this row with HTTP public IP and with the IP you expect from your VPN dashboard.
2. HTTP public IP (comparison)
What it is: A separate check — your browser requests “what is my IP?” from a public echo service (api64.ipify.org). That mimics what normal HTTPS websites see (subject to VPN routing).
Why it exists: VPN users often verify VPN by checking a “what is my IP” site. WebRTC can disagree with that result when only HTTP is tunneled.
| Scenario | HTTP IP | WebRTC srflx | Verdict |
|---|---|---|---|
| VPN covers both | VPN IP | VPN IP (same) | Consistent — no split tunnel for these paths |
| Classic WebRTC leak | VPN IP | Real ISP IP | Leak — HTTP hidden, WebRTC exposed |
| No VPN | ISP IP | ISP IP (often same) | Normal |
| IPv6 split | VPN IPv4 | IPv6 in IPv6 row | Check IPv6 row — HTTP may be IPv4-only |
| Echo service blocked | Unavailable |
Any | Ignore comparison; rely on WebRTC rows only |
3. Local IPv4 (WebRTC host)
What it is: Host candidates — private addresses of your Wi‑Fi/Ethernet interface (192.168.1.24, 10.0.0.5, etc.).
Why it matters: Even if public IP is hidden by VPN, leaking a LAN address tells a site you are on a home or office network, aids fingerprinting, and helps LAN-targeted attacks in exotic scenarios.
| Scenario | Output | How to read it |
|---|---|---|
| Firefox / Safari (older behavior) | 192.168.x.x |
Local IP visible to scripts using WebRTC |
| Chrome / Edge (recent) | None detected + mDNS row populated |
Local IP masked — good |
| VPN on, host still shown | 192.168.x.x |
LAN still visible to WebRTC; VPN does not hide LAN |
| Virtual machine / Docker | 172.x or 10.x |
Virtual interface leaked — common in dev setups |
Not always a “VPN leak”: Local IP exposure is a WebRTC privacy issue even without VPN.
4. IPv6
What it is: IPv6 addresses gathered from ICE candidates when your network and browser use IPv6.
Why it matters: Many VPN products tunnel IPv4 only. Your IPv6 address may route outside the VPN while IPv4 looks protected — a well-known IPv6 leak.
| Scenario | Output | How to read it |
|---|---|---|
| IPv6 disabled / no global v6 | None detected |
Nothing to leak via v6 |
| VPN with full dual-stack | VPN or none | Should match VPN policy |
| IPv6 leak with IPv4 VPN | Your ISP global IPv6 | Bad — disable IPv6 or use VPN with IPv6 support |
| Temporary privacy addresses | Long hex with changing interface ID | Still identifies network; may rotate over time |
If you see any global IPv6 while on a VPN that promises “IPv4 only protection,” treat it as a finding and test with IPv6 disabled on the OS or router.
5. mDNS hostname
What it is: Instead of a numeric local IP, Chrome may emit a candidate like abc123def.local — an mDNS name that does not reveal your exact 192.168.x.x to remote JavaScript.
| Scenario | Output | How to read it |
|---|---|---|
| Chrome privacy mode | xxxxxxxx.local |
Expected and safer than raw local IP |
| Status may say “mDNS only” | Host row empty, mDNS filled | Browser is hiding LAN digits — generally good |
| No mDNS, local IP shown | See Local IPv4 row | Other browsers or settings |
Do not panic when you only see .local — that is modern hardening, not your router password leaking.
6. Status (summary line)
The status line synthesizes the rows:
| Status message (examples) | Meaning |
|---|---|
| No addresses gathered | WebRTC blocked, UDP filtered, or scan timed out — retry or try another browser |
| mDNS only | Only masked local hostname; no public/local numeric leak in this run |
| WebRTC gathered addresses | At least one row has data — read each row; VPN users verify srflx vs VPN IP |
| WebRTC public IP differs from HTTP | Split behavior — investigate VPN split tunneling or extensions |
| WebRTC unavailable | Browser lacks RTCPeerConnection (very old browser or enterprise lockdown) |
Who should run this test?
- VPN subscribers validating provider “no leak” claims
- Privacy-conscious users before sensitive browsing
- IT / security documenting browser baseline for remote workers
- Developers debugging why a WebRTC app sees unexpected candidates
Limitations
- Short ~4 second ICE window may miss slow networks (use Scan again).
- Tor Browser and hardened profiles may block WebRTC entirely — empty results are inconclusive, not “proof of safety.”
- HTTP IP check requires outbound access to ipify; blocked networks skip comparison.
- This tool diagnoses; it does not disable WebRTC or configure VPNs.
Related tools
- IP Address Lookup — geolocation and network metadata for a known IP
- DNS Lookup — see how DNS resolves (another VPN leak vector)
- HTTP Header Checker — inspect response headers from URLs