WebRTC leak test: how to check (and fix) the leak that exposes your real IP

You connect to a VPN, the app says "protected", and you assume your real IP address is hidden. For most of your traffic, it is. But there's a quiet exception built into your browser that can hand your real IP straight to any website you visit — and your VPN won't warn you about it.

That exception is WebRTC. It's a browser technology designed for real-time audio and video, and it works so well that it's enabled by default almost everywhere. The same mechanism that lets you make a video call without installing anything can also reveal the IP address your VPN was supposed to mask.

This guide explains what a WebRTC leak actually is, why it slips past the VPN tunnel, how to test for it in under a minute, and how to fix it in every major browser — including the honest downside of each fix.

What WebRTC is — and why it can leak your IP

WebRTC (Web Real-Time Communication) is an API built into modern browsers that lets web pages exchange audio, video and data directly between users, peer-to-peer, without a plugin. It's what powers in-browser video calls, voice chat and some file-sharing tools.

To connect two people who are both behind home routers, WebRTC needs to discover the public address each device can be reached at. It does this using STUN servers and the ICE (Interactive Connectivity Establishment) framework. In plain terms: your browser asks a STUN server "what does my address look like from the outside?" and the answer comes back with your IP.

Here's the catch. That STUN/ICE discovery can enumerate every network address your device knows about — including your local network IP and, crucially, your real public IP — and it can do so through a path that bypasses the VPN tunnel. The VPN reroutes your normal traffic, but the WebRTC request can short-circuit it, so the IP it reports is the one your VPN was supposed to hide. The website never had to ask your VPN's permission; the browser volunteered the information.

This isn't a bug in any single VPN. It's a consequence of how WebRTC was designed to find the most direct route between peers — direct routes are exactly what a VPN tries to prevent.

Which browsers are affected

WebRTC is enabled by default in most modern browsers because real-time calls depend on it. That means the potential for a leak exists across the board:

• Chrome — WebRTC on by default; controlled mainly through extensions or policies.
• Firefox — WebRTC on by default, but it exposes a direct toggle in about:config.
• Edge — Chromium-based, behaves like Chrome.
• Brave — Chromium-based but ships a dedicated WebRTC IP-handling setting in its privacy options.
• Safari — supports WebRTC; behaviour and controls differ from the Chromium family.

The severity and the available fixes vary by browser, which is why testing your own setup matters more than assuming "my browser is fine".

How to test for a WebRTC leak

Testing is the only way to know your actual exposure, and it takes less than a minute:

1. Connect to your VPN and confirm the app says you're protected. Note the exit IP your VPN claims to be using (most VPN apps show it).
2. Run a leak test. The fastest check is our own IP & WebRTC leak test — it runs entirely in your browser and shows what your IP, DNS and WebRTC are actually exposing, with nothing logged.
3. Compare the IPs. Look at the IP address WebRTC reports. If it matches your VPN's exit IP, you're fine. If it shows your real public IP (the one your ISP gave you), or if your real IP appears anywhere alongside the VPN IP, that's a leak.

A quick sanity check: note your real IP first with the VPN off, then turn the VPN on and test again. If WebRTC still surfaces that same real IP, the tunnel is being bypassed.

How to fix a WebRTC leak

There are three honest routes, and the right one depends on whether you ever make browser-based calls.

Disable WebRTC entirely (Firefox)

Firefox is the simplest case because it gives you a direct switch:

1. Type about:config in the address bar and accept the warning.
2. Search for media.peerconnection.enabled.
3. Set it to false.

WebRTC is now off in that browser. This is the most complete fix — but it will break any site that relies on WebRTC for calls (see the trade-off below).

Restrict WebRTC instead of killing it (Brave)

Brave lets you keep WebRTC working while stopping it from leaking. In Brave's settings, under privacy/security, set the WebRTC IP handling policy to "disable non-proxied UDP". This forces WebRTC to route through your proxy/VPN path instead of taking a direct UDP shortcut, so it can't expose your real IP behind the VPN.

Use an extension (Chrome, Edge and others)

Chromium browsers like Chrome and Edge don't expose a native toggle, so the practical fix is an extension. uBlock Origin includes an option called "Prevent WebRTC from leaking local IP addresses" in its settings — enable it. There are also dedicated single-purpose extensions that control WebRTC, but using a tool you already trust (like uBlock Origin) keeps your extension footprint small.

Choose a VPN that handles it for you

Some VPN apps include built-in WebRTC leak protection, so the tunnel is enforced at the system or app level rather than relying on browser settings. If you don't want to fiddle with about:config or extensions, a VPN with audited leak protection is the lowest-effort option. Whatever you pick, re-run the leak test afterwards — protection you haven't verified is just a hope.

The honest trade-off

Disabling WebRTC is not free. WebRTC is the technology behind in-browser calls, so turning it off can break tools like Google Meet, Discord in the browser, and other web conferencing apps. That's the real cost, and it's worth being clear about.

If you rely on browser calls, you have two sane options: restrict WebRTC (the Brave-style "disable non-proxied UDP" approach, which keeps calls working while routing them through your VPN), or keep a separate browser profile with WebRTC enabled that you only use for calls, while your everyday browsing runs in a hardened profile with WebRTC off. Either way, the goal is the same: stop the leak without losing the features you actually use.

After you fix it: verify, don't assume

The single most important habit is to re-test after every change. Browser updates, new profiles, a reinstalled extension or a switched VPN server can all change your exposure. Connect the VPN, open a leak test, and confirm WebRTC reports the VPN's IP — not yours.

If you want to dig deeper into the related leaks that defeat a VPN, DNS leaks are the other big one: your traffic goes through the tunnel but your DNS queries quietly don't. The same testing discipline applies.

This article explains documented, verifiable browser behaviour (Firefox about:config, Brave's WebRTC IP handling policy, uBlock Origin's anti-leak option). Browser settings and menu locations change between versions — verify the current option names in your browser. VPNSmith publishes this content for educational purposes.