WebRTC Leak Test

WebRTC is leaking if, with your VPN connected, the test above lists an address under "Public IPs exposed by WebRTC" that is different from "Your browsing IP". That second address is what any website running a few lines of JavaScript can collect, and it usually traces back to your real connection. If WebRTC shows only your browsing IP, local addresses, masked .local names or nothing at all, there is no WebRTC leak.

Here is exactly what happens when you click Run test:

1. Your browsing IP is fetched again from our own IP endpoint, so the comparison reflects your connection right now, not when the page loaded.
2. Your browser opens a WebRTC connection configured with Google's public STUN server, stun.l.google.com:19302, and starts gathering ICE candidates — the same request a tracking script would make.
3. Candidates are collected for up to 6 seconds, because gathering can stall on networks that filter UDP. Relay candidates are ignored: they carry a relay server's address, not yours.
4. Each address is classified: .local names are masked; 10.x, 172.16–31.x, 192.168.x, 169.254.x, 100.64–127.x (carrier-grade NAT), loopback and IPv6 fe80/fc/fd addresses are local; everything else is public.
5. Every public address is compared with your browsing IP. One that differs is a FAIL; a match, local-only or masked-only results, or no candidates at all are a PASS. If your browsing IP can't be fetched, a public WebRTC address is flagged amber instead, because there is nothing to compare it with.

WebRTC is one way a real IP slips out while the tunnel is up; the other common one is the moment the tunnel drops, which our VPN kill switch test checks. To see who operates an address the test reveals, paste it into the IP address lookup.

WebRTC (Web Real-Time Communication) is the technology that lets websites run video calls, voice chat, screen sharing, and peer-to-peer file transfers directly in the browser — no plugin, no download. When you join a browser-based meeting or a customer support video chat, WebRTC is doing the work. It ships enabled by default in Chrome, Firefox, Safari, Edge, and every other mainstream browser, because the modern web depends on it.

The privacy problem is a side effect of how peer-to-peer connections get established. Two computers behind home routers can't simply dial each other — each one first has to discover what its own address looks like from the outside. So WebRTC aggressively enumerates every address that might reach your machine: your local network addresses, your public IP, and — this is the dangerous part — it can do so through network paths that ignore the proxy settings your browser uses for ordinary page requests. A single snippet of JavaScript on any web page can trigger this discovery process silently, without asking permission and without you ever making a call. The result is what's known as a WebRTC leak: your true IP address handed to a website that should only ever see your VPN's.

To find a working connection path, WebRTC uses a process called ICE (Interactive Connectivity Establishment). It collects "candidates" — possible addresses a peer could use to reach you — and each candidate type reveals something different:

• Host candidates are the addresses your network adapters hold directly — local addresses like 192.168.1.23, and on some systems your real public IPv6 address, straight from the interface.
• Server-reflexive (srflx) candidates come from asking a STUN server "what address do you see me connecting from?" Our test uses Google's public STUN server for exactly this step — the same one countless real websites use.

Here is where the leak happens. Your VPN app encrypts and reroutes your traffic at the operating-system level, but WebRTC's STUN requests are small UDP packets that some configurations send outside the tunnel — through your untouched physical connection. The STUN server then truthfully reports your real public IP, and WebRTC hands that answer to the web page as a srflx candidate. Your browsing traffic says "Amsterdam"; WebRTC says your actual city. IPv6 makes it worse: a VPN that only tunnels IPv4 can leave your interface's globally-routable IPv6 address sitting in the host candidates for any script to read.

Browsers have partially closed the hole. Since 2019–2020, Chrome, Firefox, Safari, and Edge replace local host candidates with anonymized mDNS names — random identifiers ending in .local that only resolve inside your own network. That's why our test marks .local candidates as protected. But mDNS masking does nothing about the srflx path: if a STUN request escapes your VPN tunnel, the public IP it returns is real, current, and visible to every site that asks. That's the leak this tool is built to catch, and it's a standard check in our VPN testing methodology.

The verdict panel above does the interpretation automatically, but here is the full decision table so you can see exactly how each outcome is judged:

Two subtleties worth knowing. First, run the test twice: once with the VPN off (you'll see your real IP — that's expected and harmless, it just confirms the test works) and once with the VPN on (now any public IP other than the VPN's exit is a genuine leak). Second, watch for IPv6. If the leaked address contains colons while your browsing IP is a dotted IPv4 address, your VPN is tunneling IPv4 but letting IPv6 through natively — one of the most common leak patterns we see. You can verify what your browsing IP looks like at any time with our What Is My IP tool, and combine this check with DNS and location tests using Is My VPN Working?

To stop a WebRTC leak, either make sure your VPN carries all of WebRTC's traffic or restrict WebRTC in the browser. In Firefox, set media.peerconnection.enabled to false in about:config; in Brave, set the WebRTC IP handling policy to "Disable non-proxied UDP"; in Chrome and Edge, which have no user setting for it, use a WebRTC-limiting extension or, on managed machines, the equivalent browser policy. Then run the test again and confirm it says PASS.

If the test found a leak — or you simply never use browser video calls and want the attack surface gone — here is what each major browser allows. Note the differences: only Firefox lets you switch WebRTC off completely with a built-in setting.

Firefox — the clean kill switch

Type about:config in the address bar, accept the warning, and search for media.peerconnection.enabled. Double-click it to set it to false — WebRTC is now off entirely, and this test will report PASS. If you still need video calls, use the softer option instead: set media.peerconnection.ice.default_address_only to true, which restricts ICE to the default route (your VPN interface) so calls still work but stop enumerating other network paths. Both preferences are documented on Mozilla's WebRTC privacy page: the first controls whether pages can create a WebRTC connection at all, the second limits ICE candidates to the default interface.

Chrome — no off switch, two workarounds

Chrome deliberately provides no setting to disable WebRTC — Google considers it a core web platform feature. What Chrome does do, since version 79, is mask local addresses with mDNS by default. For the public-IP path you have two options: install an extension that sets Chrome's WebRTC IP-handling policy to "disable non-proxied UDP" (which forces WebRTC traffic to give up rather than bypass a proxy or VPN), or use a VPN whose browser extension or app blocks WebRTC leaks itself. On corporate machines, administrators can enforce the same thing via the WebRtcIPHandling policy set to disable_non_proxied_udp, which Chrome's policy documentation describes as WebRTC using TCP on the public-facing interface and UDP only when a configured proxy supports it. The policy's default value lets WebRTC use every available interface.

Edge — same engine, same answer

Edge is built on Chromium, so everything said about Chrome applies unchanged: local IPs are mDNS-masked by default, there is no built-in full-disable toggle, and the reliable fixes are a WebRTC-limiting extension (Chrome Web Store extensions install fine in Edge) or a VPN with its own leak blocking. Edge's InPrivate mode makes no difference to WebRTC behavior. On managed Windows and Mac machines, Microsoft documents its own policy for this, WebRtcLocalhostIpHandling: its DisableNonProxiedUdp option makes WebRTC use TCP unless the proxy supports UDP and stops it exposing the local IP address.

Brave — a built-in setting, no extension needed

Brave turns the same Chromium control into an ordinary setting. Open Settings → Privacy and security, find WebRTC IP handling policy and choose Disable non-proxied UDP. Brave's own documentation describes that option as WebRTC using only TCP to contact peers or servers unless the proxy supports UDP, without exposing local addresses. The softer "Default public interface only" option keeps WebRTC on the default route your web traffic uses and also hides local addresses, so calls keep working. Re-run this test after changing either.

Safari — locked down by design

Safari has historically been the most conservative browser here: it doesn't expose local IP addresses to WebRTC until you've granted a site camera or microphone permission (the policy the WebKit team set out in A Closer Look Into WebRTC: without capture access, only server-reflexive and relay candidates are exposed), and it offers no user-facing switch to disable WebRTC outright. In practice Safari users rarely fail this test on the local-address side — but the srflx public-IP path still depends on your VPN tunneling all traffic, so run the test with your VPN connected rather than assuming. If Safari is your daily browser, the highest-leverage fix is simply a VPN that tunnels IPv4 and IPv6 completely.

Yes, if the VPN captures all traffic — TCP and UDP, IPv4 and IPv6, browser and system — inside the tunnel. A well-built VPN client routes WebRTC's STUN packets through the tunnel like everything else, so the STUN server only ever sees the VPN exit IP and this test passes automatically, no configuration needed. Browser tweaks treat the symptom; a VPN that tunnels everything fixes the cause.

That's exactly what we verify when we review providers: we run this WebRTC check alongside DNS leak and kill-switch tests on every VPN we rank. In our testing, NordVPN and ExpressVPN consistently pass with full IPv6 handling, and Surfshark covers the same ground at a lower price. The complete, leak-tested lineup is in our best VPN rankings. If budget is the constraint, Proton VPN's free tier tunnels WebRTC traffic properly too — and every paid provider we rank carries a 30-day money-back guarantee, so you can run this exact test on your own connection risk-free.