How to Stop WebRTC Leaks in 2026
TL;DR: WebRTC is the video-call API baked into every browser, and by default any website can use it to silently discover your real public IP — even while you're connected to a VPN. Budget VPNs leak. Premium VPNs usually don't. Test yourself with our WebRTC Leak Test, then jump to the section for your browser below.
📋 Contents
What is a WebRTC leak, really?
WebRTC (Web Real-Time Communication) is the browser API that powers Google Meet, Discord calls, Jitsi, and
in-browser video. To connect two peers across the internet, WebRTC has to know each peer's real network
address — including addresses behind NATs, mobile carriers, and VPNs. It discovers those addresses using a
simple protocol called STUN: the browser sends a short packet to a public STUN server
(typically stun.l.google.com) and the server replies with "the IP I saw you come from."
That discovered IP becomes part of what WebRTC calls an ICE candidate. And here's the catch: every
website running JavaScript can create an RTCPeerConnection and read those candidates — without
ever asking for microphone or camera permission, without a popup, without any visual indication.
⚠️ The core problem
WebRTC was designed to punch through NAT so that peer-to-peer video calls would "just work." That design goal is directly at odds with privacy: the same mechanism that helps you connect to a colleague also tells a tracker on any tab what your real IP is.
Why your VPN often can't fix it
When you install a VPN client, it typically does one of two things:
- Full-tunnel VPN — the OS routes all outgoing traffic, TCP and UDP, through the tunnel. If the VPN stays up, WebRTC's UDP packets go through the tunnel too, and STUN sees the VPN's exit IP. No leak.
- Browser-extension VPN or split-tunnel — only HTTP(S) from specific processes is tunneled. WebRTC's STUN packets are UDP initiated by a different code path inside the browser, and they may bypass the tunnel entirely. STUN sees your real IP. Big leak.
Free browser-extension VPNs are the worst offenders. You see a "VPN active" badge in your toolbar, and every
fetch() your page makes does go through the VPN. But WebRTC's discovery packets don't, and your
real IP is one new RTCPeerConnection() away from any script that wants it.
Paid full-tunnel clients (Mullvad, ProtonVPN, NordVPN, ExpressVPN with their "kill switch" enabled) generally block non-proxied UDP at the OS firewall level. On those, WebRTC can't leak because the packets simply never reach a STUN server.
Step 1: Test first, fix second
Before you change any browser setting, run a test. Fixes vary by browser and VPN, and you want a before/after so you know which one actually worked.
🕵️ Run a WebRTC leak test
Our WebRTC Leak Test runs 100% in
your browser, talks to public STUN servers (Google and Cloudflare), and shows every IP your browser would
expose. It flags srflx (public, via STUN) candidates in red — those are the leaks.
If the test shows only .local or private (10.x, 192.168.x, 172.16–31.x) addresses, you're fine —
modern browsers mask local IPs behind mDNS hostnames and private addresses aren't routable. If you see a
public srflx address, keep reading.
Fix: Chrome & Edge
The problem: Chrome removed the chrome://flags/#disable-webrtc flag years ago.
There is no built-in toggle to disable WebRTC. You need an extension or a VPN that handles it at the network layer.
Option A — Extension (quickest): Install WebRTC Network Limiter (by Google) or uBlock Origin with its "Prevent WebRTC from leaking local IP addresses" setting enabled in Advanced mode. uBlock Origin is the safer pick because it's open-source and doesn't require granting broad permissions.
Option B — Policy (for managed devices): Set
WebRtcLocalIpsAllowedUrls to an empty list and WebRtcIPHandling to
disable_non_proxied_udp via Chrome's enterprise policy. This is the nuclear option but it
survives reinstalls.
Option C — Use a full-tunnel VPN. This is the recommended approach. Disabling WebRTC breaks video calls; making the VPN block non-proxied UDP doesn't.
Fix: Firefox
Firefox has a built-in kill switch. Type about:config in the address bar,
accept the warning, and search for media.peerconnection.enabled. Toggle it to
false. WebRTC is now fully disabled.
For finer control, set these too:
media.peerconnection.ice.default_address_only→true(if you want to keep WebRTC but only expose the default route)media.peerconnection.ice.no_host→true(suppresses local-network candidates entirely)
If you re-enable media.peerconnection.enabled later (for a video call), remember to toggle it
back to false afterward. There's no UI reminder.
Fix: Brave
Brave ships with the fix built in. Open
brave://settings/privacy → scroll to "WebRTC IP handling policy" → set it to
Disable non-proxied UDP. This keeps WebRTC working over proxies/VPNs but stops it from
bypassing them.
The default on new Brave installs is already "Default" (which does leak), so this is a one-time change worth making even if you don't use a VPN — it prevents ad scripts from quietly pinging STUN.
Fix: Safari
Safari masks local IPs by default (uses mDNS, like Chrome/Firefox) but still allows public IP discovery via WebRTC. There is no in-app toggle on the stable channel.
On macOS: open Safari → Settings → Advanced → enable "Show features for web developers." Then Settings → Feature Flags → toggle off anything labeled "WebRTC Platform UDP Sockets" or "WebRTC H.265 codec." This is imprecise (Apple renames flags frequently), so the more reliable fix is a full-tunnel VPN.
On iOS: you cannot disable WebRTC in Safari. You can only use a VPN profile (a proper system VPN, not the fake "VPN-in-an-app" kind) that routes all UDP through the tunnel.
Fix: At the VPN / OS level (the robust option)
Disabling WebRTC inside a browser is a workaround. The robust fix is at the OS firewall level: block non-tunneled UDP so that even if WebRTC tries to phone STUN, the packets never leave your machine.
Which VPNs handle this correctly out of the box:
- Mullvad — kill switch is on by default, blocks all traffic outside the tunnel including STUN. Clean, no-logs operator based in Sweden.
- ProtonVPN — enable "Kill switch" and "Permanent Kill Switch" in the client. Blocks non-tunneled UDP.
- NordVPN — enable "Internet Kill Switch" (app-level is not enough; use the system-level option).
- IVPN — kill switch and WebRTC blocking are both defaults.
- WireGuard with AllowedIPs = 0.0.0.0/0, ::/0 — if you roll your own, this config plus a matching firewall rule does the same job.
⚠️ Watch out for browser VPN extensions
Extensions labeled "VPN" that you install from the Chrome Web Store are almost always proxies, not VPNs. They only cover HTTP traffic from specific Chrome APIs. WebRTC UDP bypasses them completely. If privacy matters, use a full-tunnel VPN client installed from the vendor's site.
What breaks when you disable WebRTC
Disabling WebRTC is not free. Here's what stops working:
- Browser video calls: Google Meet, Jitsi, Whereby, Jitsi, Zoom's web client, Discord's browser voice, Slack huddles, Teams web.
- P2P file-sharing in the browser: tools like WebTorrent, Magic Wormhole Web, some browser-based send-file services.
- Some audio services: anything using
getUserMediafor low-latency audio (browser-based instruments, voice demo widgets).
This is why the "VPN + kill switch" approach is the better long-term fix. Video calls keep working because WebRTC still runs — it just runs through the tunnel, so STUN sees the VPN's IP and everyone is happy.
Final checklist
- ✅ Run the WebRTC Leak Test before and after any change.
- ✅ If you're on Firefox or Brave, flip the built-in setting; no extension needed.
- ✅ If you're on Chrome/Edge/Safari, prefer a full-tunnel VPN over an extension.
- ✅ If you use a VPN, enable its kill switch and verify it blocks non-tunneled UDP.
- ✅ Re-test every time you update the browser or VPN client — settings sometimes reset.
- ✅ If WebRTC has to stay enabled for work (video calls), accept that public IP exposure and compensate elsewhere (e.g., a separate browser profile for sensitive browsing).
FAQ
What is a WebRTC leak?
A WebRTC leak is when your browser reveals your real public IP address to a website via the WebRTC API, even while connected to a VPN. It happens because WebRTC uses STUN servers to discover the best peer-to-peer path, and any script on the page can read the discovered IP silently.
Do all VPNs leak WebRTC?
No. Well-configured full-tunnel VPNs (Mullvad, ProtonVPN, NordVPN with kill switch on) block non-proxied UDP at the OS level, which prevents the leak entirely. Browser-extension VPNs almost always leak because they don't cover UDP traffic.
How do I disable WebRTC in Firefox?
Open about:config, search for media.peerconnection.enabled, and toggle it to
false. This disables WebRTC entirely, so video calls through Google Meet, Discord, and
similar services will stop working until you toggle it back.
Does incognito / private mode prevent WebRTC leaks?
No. Private browsing only prevents history, cookies, and cache from being saved locally. WebRTC still functions normally and can still expose your IP. You need to either disable WebRTC or use a VPN that blocks non-tunneled UDP.
How can I check if my VPN is blocking WebRTC?
Connect to the VPN, then run the WebRTC Leak Test. If the public IP shown matches your VPN exit IP (check with What's My IP), your VPN is catching WebRTC traffic. If the WebRTC test shows your real ISP IP while What's My IP shows the VPN IP, you have a leak.
🛠️ Useful tools for WebRTC privacy
Run these free browser-based tools to check your current exposure:
About FunWithText
We build free, privacy-focused text tools and network diagnostics. Most of our tools run in your browser — your data stays on your device. Our mission is to make privacy tooling accessible to everyone.
Read More Articles →