WebRTC Leak Test
Running the leak test...
IPv4 (HTTP) Checking...
IPv6 (HTTP) Checking...
ICE candidates collected
No ICE candidates were collected.
Approximate location
Locating your network…

The marker shows the approximate centre of the area your provider serves , not your home, street or device. Being off by tens of kilometres is normal.

How to stop a WebRTC leak
Chrome / Edge — install a WebRTC-blocking extension (e.g. "WebRTC Leak Prevent"), or use a VPN client that explicitly blocks WebRTC traffic — modern Chrome no longer ships a built-in toggle for this.
Firefox — open about:config, search for media.peerconnection.enabled, and set it to false to disable WebRTC entirely.
Safari — WebRTC cannot be toggled globally; disable camera/microphone access per-site under Safari > Settings > Websites, or rely on a VPN that blocks WebRTC at the network level.
Brave — open the Shields panel and set the WebRTC network limiter to its strictest/"Proxied" mode to prevent local IP leaks.
About the WebRTC leak test

WebRTC is a browser technology built for real-time video calls and peer-to-peer file transfer. To connect two computers directly, it needs to discover every network address each side could be reached on, so it asks a public STUN server "what IP does this connection look like from the outside?" and collects the answer as an ICE candidate. That candidate exchange normally happens invisibly between two peers in a call — but any website can also trigger it silently in the background, read the candidates, and extract your addresses from them.

This becomes a privacy problem specifically for VPN users. A VPN reroutes your regular HTTP traffic through its tunnel, so websites see the VPN's IP address instead of yours. WebRTC, however, talks to the STUN server over its own connection, and on some setups that connection bypasses the VPN tunnel entirely — leaking your real internet IP even though the address bar shows you are "protected". Modern browsers also try to hide your local network address by replacing it with a random, single-use mDNS hostname ending in .local instead of a raw IP like 192.168.1.5; that substitution is a genuine privacy improvement, not a sign that anything is broken.

This tool runs the exact same ICE-gathering process a malicious page could run, using two independent STUN servers for reliability, and compares every public candidate it collects against your actual HTTP IP address. If they match, WebRTC is not adding any extra exposure beyond what every website already sees. If they differ while you believe you are on a VPN, that mismatch is the leak — and the fixes above explain how to close it for your specific browser.

This test only reveals what your own browser exposes through WebRTC ICE gathering; it cannot detect leaks happening at the operating system or router level.

WebRTC Leak Test: Is Your VPN Leaking Your Real IP?

This WebRTC leak test runs the same peer-connection trick a tracking script would, and tells you whether any address it collects is one your VPN was supposed to hide. It opens an RTCPeerConnection with an empty data channel — no camera, no microphone, no prompt — asks two public STUN servers what your connection looks like from outside, and compares that with the IP your HTTPS requests arrive from.

How to read the ICE candidates this test shows

WebRTC has to discover every address a peer could reach you on, so it produces a list of ICE candidates. This page shows that raw list, one row per candidate, with its type and transport, and stops gathering after five seconds.

Above it sit your regular IPv4 and IPv6 as seen over HTTP — the same values what is my ip address returns. Those are the baseline; the verdict is just the comparison.

host, srflx and relay — what the badges mean

  • Local (host) — an address your own interface owns: a LAN IP like 192.168.1.14, or a random .local name.
  • Public (via STUN) — the srflx candidate, the address STUN saw the packet arrive from. The one that matters on a VPN.
  • Relay (TURN) — bounced through a relay; this page uses STUN only, so a relay row is unusual.

What each verdict means

  • Leak detected — a public candidate differs from your HTTP IP; on a VPN, the STUN packet bypassed the tunnel.
  • No leak — the two match.
  • Local IP exposed — a raw LAN address appeared instead of an mDNS name.
  • Protected — your local address came back as a random .local hostname.
  • No public IP / WebRTC blocked — STUN was unreachable or WebRTC is off.

Why WebRTC leaks an IP your VPN is hiding

WebRTC exists for browser-to-browser video, voice and file transfer. Connecting two machines behind separate routers needs NAT traversal, and that needs one question answered from outside: what address does this connection come from? A STUN server answers it, and any page can start the exchange silently and read the candidates from JavaScript.

That only fails you when a different address is supposed to be visible. A VPN reroutes your HTTP traffic through its tunnel, but WebRTC sends its own UDP packets to STUN, and on a split tunnel those take the normal route. Browser-extension VPNs are the classic case: they proxy page requests, not the UDP stack — so this result can disagree with a vpn check made over HTTP.

A random .local hostname is not a leak

If a host candidate reads 7b3f9c21-4d0a-48e7.local instead of 192.168.1.14, nothing is broken. That is mDNS obfuscation: the browser mints a single-use multicast DNS name for the local interface and hands that over instead of the LAN address. Chrome, Edge, Brave, Firefox and Safari all do it by default — uBlock Origin dropped its own WebRTC option in v1.38 because the browsers took over. Two caveats: it covers the local address only, so it does nothing for a VPN leak, and a site holding camera or microphone permission gets the real local IP anyway.

How to fix a WebRTC leak in Chrome and Edge

Neither browser has an off switch, and no entry in chrome://flags or edge://flags disables WebRTC any more — Edge’s old "Hide my local IP address over WebRTC connections" checkbox is gone too. Three things work, in order of reliability:

  • Use a full-tunnel VPN client, not a browser extension. If every UDP packet leaves through the tunnel, STUN can only see the VPN address.
  • Set the IP-handling mode with an extension. WebRTC Leak Prevent and WebRTC Control block nothing themselves; they flip chrome.privacy.network.webRTCIPHandlingPolicy to default_public_interface_only or disable_non_proxied_udp. Only those two modes stop local exposure.
  • Apply the policy directly. Chrome reads WebRtcIPHandling; Edge reads WebRtcLocalhostIpHandling under SOFTWARE\Policies\Microsoft\Edge, where only AllowPublicInterfaceOnly and DisableNonProxiedUdp help. Both need a restart; confirm at edge://policy.

How to disable WebRTC in Firefox

Firefox is the one desktop browser with a real switch. Type about:config, accept the warning, search media.peerconnection.enabled and double-click it so the value reads false. WebRTC is then off for every site with no restart, and this test reports it as blocked.

That is blunt: browser-based Meet, Teams, Discord and Zoom stop connecting until you set it back. To keep calls working, leave it alone and set media.peerconnection.ice.default_address_only to true instead — Firefox then offers only your default-route address, which is the VPN’s when the tunnel carries everything.

How to fix a WebRTC leak in Brave

Brave ships the control Chrome hides. Open brave://settings/privacy and find WebRTC IP handling policy. Only the last two values are worth using on a VPN or proxy:

  • Default — may enumerate every interface. Exposes local addresses.
  • Default Public and Private Interfaces — default route only, but still reveals the matching private address.
  • Default Public Interface Only — default route only, no local addresses, calls unaffected. The sensible everyday setting.
  • Disable Non-Proxied UDP — TCP through the proxy unless it supports UDP. Strictest, and what Brave uses in Tor windows; it can break peer-to-peer calls.

Safari, iPhone and Android

Mobile and WebKit are where generic desktop advice stops being true.

Safari on macOS

Current Safari has no supported global toggle. The Develop > Experimental Features > Remove Legacy WebRTC API item older guides name is gone, and the Develop > WebRTC entries last only for the session. Safari withholds local addresses behind mDNS until you grant camera or microphone access, so the real levers are per-site permissions under Safari > Settings > Websites and a system VPN.

iPhone and iPad

Every iOS browser uses WebKit, so Chrome and Firefox for iPhone have no about:config, no flags page and no extensions — desktop advice does not apply, and content blockers cannot filter WebRTC. To prevent a WebRTC leak on an iPhone, use a VPN with a real system profile under Settings > VPN that tunnels UDP, then re-run this test in Safari.

Android

Chrome for Android has no WebRTC flag and no extensions. Brave for Android carries the same WebRTC IP handling policy list in its privacy settings, the easiest fix here; Firefox for Android exposes about:config only on Nightly and Beta. Otherwise rely on Always-on VPN with Block connections without VPN.

What this test cannot tell you

This page only sees what your browser hands to a script on this origin. It cannot detect a leak below the browser — a misrouted OS-level connection, an IPv6 path your VPN never claimed — and it does not test DNS. Readings can be ambiguous too: if a firewall blocks STUN you get "No public IP", which looks reassuring but only means the question went unanswered. An IP is also one identifier among many — the fonts, screen metrics and headers read by what is my browser single you out from a clean VPN address.

Frequently asked questions

Does WebRTC leak my real IP even when I'm connected to a VPN?

Yes, it can. WebRTC sends its own UDP packets to a STUN server, and with a split tunnel — most browser-extension VPNs, some desktop clients — those packets take the ordinary route instead of the tunnel. The STUN server then reports your ISP address, and any page can read it out of the candidate list without asking permission. A full-tunnel client that captures all UDP closes it. The verdict above tells you which case you are in.

Is there any way that I can turn off WebRTC in Edge?

Not with a normal setting — Edge has no on/off switch, and the old about:flags entry "Hide my local IP address over WebRTC connections" was removed. What still works is the WebRtcLocalhostIpHandling policy set to AllowPublicInterfaceOnly or DisableNonProxiedUdp under SOFTWARE\Policies\Microsoft\Edge, which requires a restart. Verify it applied at edge://policy. Otherwise, a full-tunnel VPN is the practical answer.

Where can I disable WebRTC and PeerConnection in Firefox?

In about:config: search for media.peerconnection.enabled and double-click it to false. That disables WebRTC entirely, with no restart — and browser video calls stop connecting until you undo it. If you want calls to keep working, leave that preference true and set media.peerconnection.ice.default_address_only to true instead, so Firefox offers only your default-route address.

How can I permanently disable WebRTC in Safari?

You can't in current Safari. The Develop > Experimental Features > Remove Legacy WebRTC API toggle that worked years ago no longer exists, and the Develop > WebRTC entries reset with the session. Safari does hide your LAN address behind an mDNS name and only reveals it once you grant camera or microphone access, so the realistic approach is per-site permissions under Safari > Settings > Websites plus a system-wide VPN for the public address.

What are the best settings to stop a WebRTC leak in Brave?

Open brave://settings/privacy and set WebRTC IP handling policy to "Disable Non-Proxied UDP" while you are on a VPN or proxy. WebRTC then uses TCP through the proxy unless the proxy supports UDP, so STUN never sees your real address. "Default Public Interface Only" is the softer choice: UDP still works and calls stay usable, but no local interface is offered.

Which WebRTC IP handling policy should I choose?

"Default Public Interface Only" suits most people. It hides every local interface, keeps UDP, and leaves video calls working normally. Pick "Disable Non-Proxied UDP" only when you are behind a proxy or VPN and want the hardest guarantee — it can degrade or break peer-to-peer calls if the proxy has no UDP support. "Default" and "Default Public and Private Interfaces" both still expose your local address.

Why is my private IP address made public by WebRTC?

In most current browsers it is not. Chrome, Edge, Brave, Firefox and Safari replace the raw LAN address with a random single-use mDNS hostname ending in .local, so a page sees that name rather than 192.168.1.14. uBlock Origin dropped its own WebRTC option in v1.38 because browsers took this over. If the list above shows a bare 192.168.x.x or 10.x.x.x host candidate, that protection is off and worth fixing.