What Is a WebRTC Leak?

You turn on your VPN, the app says connected, and you assume your real IP address is hidden from every site you visit. Most of the time that's true. But there's a browser feature built for something completely unrelated to VPNs, video calling, that can quietly undo that protection without your VPN app ever knowing anything went wrong. That's a WebRTC leak.

This article covers what WebRTC actually is, what "leak" means here, why it happens even with a decent VPN, and how to check whether it's happening to you.

What is WebRTC?

WebRTC stands for Web Real-Time Communication. It's a browser feature that lets two devices set up a direct audio, video, or data connection without installing a plugin. It's the reason Google Meet, Discord's browser version, and WhatsApp Web can do live video calls right inside a browser tab. Every major browser, Chrome, Firefox, Safari, Edge, Brave, has WebRTC built in and turned on by default.

None of that is a problem on its own. WebRTC is genuinely useful, and turning it off entirely breaks a lot of ordinary things people use every day. The issue is a side effect of how it works under the hood, which is what the rest of this article is actually about.

What is a WebRTC leak?

A WebRTC leak is when a website uses WebRTC to discover your real IP address, even though you're using a VPN or proxy that's supposed to hide it. It happens because WebRTC needs to know each device's real network address to set up a direct peer-to-peer connection, and figuring that out involves a step that runs outside your browser's normal, VPN-protected traffic path.

In practice: a site runs a small bit of JavaScript, your browser hands back a list of your device's possible network addresses, and the site now has your real IP even if the address bar, your VPN app, and every other part of your setup looks completely normal.

How the leak actually happens

To set up a direct connection between two browsers, WebRTC uses a process called ICE (Interactive Connectivity Establishment). ICE gathers a list of every network path your device might be reachable on, called candidates, and offers them all to the other side so the two browsers can pick whichever path actually works.

There are three kinds of candidates, and they matter differently:

The srflx candidate is where the leak lives. To generate it, your browser sends a short request over UDP straight to a STUN server (commonly one of Google's or Cloudflare's public ones). That request doesn't go through your browser's usual HTTP(S) traffic path, and depending on how your VPN is set up, it may not go through your VPN tunnel either. The STUN server sees your real connection and reflects your real public IP straight back to the browser, which then hands it to whatever site asked for it. Your VPN app never sees this happen, because from its point of view, nothing about your web browsing changed.

Local IP vs public IP: which one matters

People often panic at the wrong result. If a leak test shows a local IP like 192.168.1.42 or 10.0.0.5, that's your home router's internal addressing, and it's not unique to your device or your ISP. It's a mild fingerprinting signal at most, since modern browsers have masked it by default since around 2020 anyway, replacing it with a randomized .local hostname through a technique called mDNS obfuscation.

The result actually worth worrying about is your real public IP showing up while a VPN is connected. That's your ISP-assigned address, the same one a VPN is specifically supposed to hide, and it's what a site can use to trace your rough location and identify your internet provider. If your VPN's public IP and the address in the WebRTC section of a leak test don't match, that's the leak that matters. Our IP leak test and DNS leak test check the same class of exposure through different paths.

Why your VPN doesn't always stop it

Good VPN apps that route your entire system's traffic, including UDP, generally do stop this. The leak shows up most often for one specific and very common reason: the "VPN" isn't actually a full VPN.

A lot of people use a browser extension labeled "VPN" and assume it works the same way as a desktop or mobile app. It doesn't. Most browser VPN extensions are proxies that reroute your browser's HTTP and HTTPS traffic. They have no way to touch WebRTC's UDP-based STUN requests, because that traffic was never going through an HTTP proxy to begin with. The extension isn't lying when it says "connected". It's just protecting a narrower slice of your traffic than a real VPN client does, and WebRTC lives entirely outside that slice.

Full VPN apps can still leak too, usually from split-tunneling settings, an IPv6 connection the VPN doesn't account for, or a kill switch that doesn't cover traffic already in flight when the VPN reconnects. It's also worth being clear that this is a separate layer from which VPN protocol you're using. Switching between WireGuard and OpenVPN doesn't fix or cause a WebRTC leak on its own; both can leak or both can protect you, depending on how the app around them handles UDP traffic. If you're not sure your provider handles this correctly, our VPN reviews note which ones publish real leak-testing results.

Which browsers are affected

Every major browser ships WebRTC on by default, but they don't all handle the local-IP part the same way, and none of them protect your public IP without help from your VPN.

How to test for it and fix it