A WebRTC IP leak is not hacking. It means a page using browser peer-connection APIs may learn connection candidates — often a private LAN address and sometimes your real public IP — even when a VPN changes what a normal HTTP “what is my IP” page shows. FindMyIP’s homepage and ISP Lookup do not test WebRTC.
This post explains that gap for normal users. It is not a VPN review and it does not invent a leak tester on this site.
Short answer
WebRTC can expose more than one address path. Ordinary sites (including What Is My IP) usually see only the public source of that HTTP request. WebRTC’s ICE candidate gathering can also surface host (often private) and server-reflexive (often public) addresses used for real-time calls. Those paths are separate. A clean VPN exit on the homepage does not prove WebRTC is quiet.
For the VPN exit story alone, see what a VPN changes on your visible IP. This article owns the WebRTC deep dive that post only flags as a separate check.
What “leak” actually means here
Marketing language sounds dramatic. The mechanism is boring and documented.
Browsers implement WebRTC so video calls, screen share, and some games can connect peer-to-peer. To find a workable path, they gather ICE candidates — possible addresses and ports. A page with permission to use those APIs can read candidates the browser collects.
Typical candidates include:
- Host / local — often a private address on your LAN or VPN interface (for example
192.168.x.xor10.x.x.x) - Server-reflexive (srflx) — often your public address as seen via a STUN server
- Relay — traffic through a TURN server when direct paths fail
So “leak” usually means: a site learned an address the VPN marketing page did not mention, not someone broke into your router.
RFC 8828 covers WebRTC IP handling and browser privacy tradeoffs. Treat it as background, not a shopping guide.
Local vs public candidates
On a typical home network you already have two kinds of addresses. That split is normal networking, not a WebRTC quirk. See public vs private IP address for the RFC1918 home ranges.
| Candidate type | Often looks like | Why it appears |
|---|---|---|
| Local / host | Private LAN or interface IP | Your device’s own interfaces |
| Public / srflx | ISP or VPN-facing public IP | What a STUN server observes outside your NAT |
| Relay | Provider TURN address | Fallback when peer-to-peer fails |
A test that prints a 192.168… address is often a local candidate. That can still matter for LAN topology, but it is not “the whole internet saw my ISP IP.” A public candidate that matches your real ISP address while a VPN is “on” is the scenario VPN users worry about more.
Label what you saw (local vs public), then compare it to What Is My IP with the same VPN state.
How this differs from a homepage IP check
| Check | What it usually measures | What it does not prove |
|---|---|---|
| HTTP “what is my IP” | Public source IP of that request | Peer-connection candidates, DNS path, other apps |
| ISP / org lookup | Who owns the public address you present | Whether WebRTC gathered extra candidates |
| WebRTC / ICE test (elsewhere) | Addresses exposed via peer APIs | That every app or OS path matches |
FindMyIP:
- What Is My IP — public address for that HTTP request
- ISP Lookup — network / org label for a public address
We do not run a WebRTC leak test or list ICE candidates. If another site’s WebRTC panel disagrees with FindMyIP, that is expected: different APIs, different questions.
For the broader picture without the WebRTC angle, see what your IP address reveals.
When a VPN still looks fine on FindMyIP
A working VPN usually changes the HTTP source address. Reload What Is My IP and you often see a VPN exit; ISP Lookup often shows a hosting or VPN-related org instead of your home ISP.
WebRTC can still gather candidates on a physical interface, via STUN that reflects your ISP-facing public IP, or as a local address you did not expect. Or it may not. Browser defaults and VPN clients differ. Split tunneling can leave the browser half in, half out. None of that means FindMyIP is wrong — the homepage answered a different question.
Practical checks (no invented product features)
Keep this small and reversible.
1. Baseline. VPN off. Note the public address on What Is My IP. Optionally note the org on ISP Lookup.
2. VPN on, same browser. Recheck FindMyIP. Expect a different public address if the tunnel covers that browser. If it does not change, fix the client first.
3. Use a dedicated WebRTC / ICE test elsewhere. Prefer tools that label host vs srflx. Compare any public candidate to your FindMyIP baseline and VPN-on result.
4. Browser controls (high level). Some browsers offer preferences that limit non-proxied UDP or mDNS host candidates. Exact menus change by version — check current privacy docs. Blocking WebRTC can break calls; treat that as a tradeoff.
5. VPN client settings. Use the vendor’s own help for WebRTC or “prevent IP leaks.” Do not assume every provider implements the same fix.
6. Stop when calls matter. Aggressive WebRTC blocking can break browser video meetings. Privacy vs working calls is a real tradeoff.
We will not invent a FindMyIP WebRTC panel, affiliate “best VPN” list, or a one-click score.
Honest limits
- Not hacking. Candidate exposure is browser API behavior, often intentional for connectivity.
- Not the same as HTTP IP. Passing FindMyIP does not clear WebRTC; failing a WebRTC panel does not mean FindMyIP is wrong.
- Not full anonymity. Accounts, cookies, and traffic outside the tunnel remain separate (VPN visible-IP overview).
- Uncertainty is normal. Re-check after major browser or VPN updates instead of trusting one old screenshot.
Practical takeaways
- Read “WebRTC leak” as extra connection candidates (local vs public) — not as a break-in.
- Use FindMyIP for the HTTP public address and org label; use a separate WebRTC-aware check for ICE candidates.
- Compare public candidates to your VPN-on vs VPN-off FindMyIP results before you panic.
- Prefer reversible settings over permanent breakage of video calls.
- One clean homepage IP ≠ every path covered.
Use the result for the question it answers
A WebRTC IP leak is the browser sharing peer-connection candidates that can include private and public addresses. That is a different measurement from the public IP on What Is My IP or the network label on ISP Lookup. Verify each path on purpose. Do not treat either check as a full privacy score.