WebRTC Leak Test

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?

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.

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.

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.

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, 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.

Browser tweaks treat the symptom. The underlying question is whether your 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.

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.