A WebRTC IP leak is not hacking. It means a page using browser peer-connection APIs may learn connection candidates — sometimes your real public IP, and in some cases a private LAN address — 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. The VPN leak check reads ICE candidates in the browser and compares public ones with the address this site sees. It does not detect a VPN product, test DNS leaks, or score your privacy.
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 (local; usually masked as an mDNS .local name in current browsers) 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. Any web page can start that gathering and read the candidates; it does not need a permission prompt.
Typical candidates include:
- Host / local — your device’s own interface address. Since about 2019–2020, desktop Chrome, Edge and Firefox, and Safari, hide the private LAN address behind a random mDNS name ending in
.localby default. A raw192.168.x.xor10.x.x.xusually appears only after you grant the page camera or microphone access, in older or modified browsers — or in some mobile browsers such as Chrome on Android, which does not use this masking. - 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 | Usually an mDNS name ending in .local (a raw LAN IP with camera/mic permission, in older browsers, or in some mobile browsers such as Chrome on Android) |
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 showing a local candidate — in current desktop browsers, usually because the page has camera or microphone permission; some mobile browsers, such as Chrome on Android, can show it without that. 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, and mDNS masking does not hide it.
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 | 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
- VPN leak check — HTTP address, registered network, and WebRTC candidates gathered in the browser. DNS resolvers are not tested.
The leak check does not resolve mDNS .local host names, and a missing candidate is inconclusive. If its WebRTC panel disagrees with the homepage IP, that can be 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
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. Open the VPN leak check. Compare any public WebRTC candidate with your baseline and VPN-on homepage result. The page says when no candidate arrived. An empty result is inconclusive, not a pass.
4. Browser controls. Menus change between versions, but the main options are:
- Firefox: in
about:config,media.peerconnection.ice.default_address_onlyset totruelimits candidates to the system’s default route. That is usually the VPN when a full-tunnel VPN is on, but not with split tunneling, a browser-only proxy extension, or an IPv4-only VPN that leaves IPv6 outside the tunnel — re-run the leak check afterwards to confirm.media.peerconnection.enabledset tofalseturns WebRTC off entirely. - Brave: Settings → Privacy and security → WebRTC IP handling policy.
- Chrome and Edge: no simple menu. Browser extensions — including many VPN browser extensions — can apply the same restriction, and managed devices can set it by policy.
- Safari: no user-facing switch; rely on the VPN client.
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.
The leak check is not a one-click privacy score, and this site does not publish an affiliate “best VPN” list.
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).
- Not the only leak path. IPv6 traffic that bypasses a VPN is another (IPv4 vs IPv6), and DNS queries are a third (DNS over HTTPS). What the network operator still sees is covered in what your ISP can see.
- 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 the VPN leak check for ICE candidates. It still does not test DNS leaks.
- 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.