How to Disable WebRTC in Firefox, Chrome, Brave, and Safari (2026)

## TL;DR WebRTC is a browser feature for real-time video and voice calls. It can leak your real IP address - including the one behind your VPN - because it talks to STUN servers directly from inside the browser, bypassing the system network stack. This guide shows the exact, browser-by-browser way to disable or restrict WebRTC in Firefox, Chrome, Brave, Safari, and the hardened forks (Mullvad Browser, LibreWolf, Tor Browser). It also covers mobile, the mDNS .local mitigation, and what you break by turning WebRTC off. ## What WebRTC actually is and why it leaks WebRTC (Web Real-Time Communication) was added to browsers around 2012 to enable peer-to-peer video and audio in the browser without plugins. Google Meet, Discord's web client, Zoom in the browser, Whereby, Jitsi, and most modern "click to call" widgets are built on it. To make peer-to-peer connections work across NATs (which is most home internet), WebRTC uses **ICE** (Interactive Connectivity Establishment) and a helper protocol called **STUN** (Session Traversal Utilities for NAT). When a page initialises a WebRTC `RTCPeerConnection`, the browser sends UDP packets to one or more STUN servers - sometimes Google's, sometimes the page's own - and the STUN server replies with the IP address it saw. That reply contains: - Your **public IP** (which is what the STUN server saw) - Your **local network IPs** (which the browser includes so peers on your LAN can reach each other directly) The page can read both. Without a VPN, this just exposes your LAN structure. With a VPN, this is the leak: the STUN traffic can go out outside the VPN tunnel depending on routing, or the local network IP set still gets enumerated. Here is a minimal WebRTC IP-enumeration script of the kind tracking and fingerprinting libraries use: ```javascript // Minimal WebRTC IP-enumeration (the "WebRTC leak" attack) const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] }); pc.createDataChannel(''); pc.createOffer().then(o => pc.setLocalDescription(o)); pc.onicecandidate = (e) => { if (!e.candidate) return; const ip = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9:]+:[a-f0-9:]+)/i .exec(e.candidate.candidate); if (ip) console.log('Leaked IP candidate:', ip[1]); }; ``` That snippet runs in any browser tab in milliseconds, no permission prompt, no user interaction. It is what tracking scripts and IP-grabber sites use. ## How to test if you are leaking Before you change anything, measure. Open one of these from inside your VPN: - [browserleaks.com/webrtc](https://browserleaks.com/webrtc) - shows the public and local IPs WebRTC discovers - [ipleak.net](https://ipleak.net) - runs WebRTC, DNS, and IP checks in one page - [mullvad.net/check](https://mullvad.net/en/check) - Mullvad's own leak page, works whether you use Mullvad or not The results table you want to read looks like this: | Source | What you should see | What a leak looks like | |---|---|---| | Public IP (browser) | Your VPN exit IP | Your real ISP IP | | Local IP (WebRTC) | Random `.local` mDNS or VPN-side IP | Your real `192.168.x.x` or `10.x.x.x` | | DNS server | VPN's DNS | Your ISP's DNS | If the WebRTC public IP matches your VPN public IP, you are not leaking the public address. You may still be exposing the local network range, which is a smaller fingerprinting concern but real. ## Firefox Firefox has the cleanest disable path of any browser because it exposes WebRTC as a single `about:config` switch. **Full disable (breaks all WebRTC):** 1. Open a new tab and go to `about:config` 2. Accept the "I'll be careful" warning 3. Search for `media.peerconnection.enabled` 4. Double-click to set it to **false** That is it. WebRTC is now off in Firefox until you flip it back. Video calls in the browser will stop working. Discord-in-browser voice will not connect. Google Meet will show a generic "couldn't connect" error. **Partial mitigation (keeps WebRTC working, hides local IPs):** If you need WebRTC for calls but want to prevent the local-IP enumeration: 1. In `about:config`, search for `media.peerconnection.ice.no_host` 2. Set it to **true** This tells Firefox to not include host candidates (the local IPs) in ICE. Calls still work because ICE will fall back to server-reflexive candidates via STUN. The public IP behind your VPN is still visible (which is what you want - that's your VPN's IP), but your LAN IPs are not. **Bonus for paranoid users**: also set `media.peerconnection.ice.default_address_only` to true. This forces only the default network interface to be advertised, useful if you have multiple interfaces (e.g. a VPN tunnel and a physical NIC). ## Chrome and Chromium-based browsers Chrome, Edge, Opera, and Vivaldi share the same WebRTC implementation. None of them expose a native disable. You need an extension. **Option 1: WebRTC Network Limiter (Google's own extension)** Google publishes an extension that adds policy options for the ICE candidate types. Install from the Chrome Web Store, set it to "Use my proxy server" or "Use my proxy server (disable non-proxied UDP)". This is the closest Chrome gets to a Brave-style WebRTC IP handling policy. It does **not** fully disable WebRTC. **Option 2: uBlock Origin (advanced mode)** uBlock Origin has a built-in switch named `no-webrtc` that disables WebRTC entirely. 1. Open uBlock Origin's dashboard 2. Go to the "Switches" or "My filters" panel 3. Add: `no-webrtc: * true` That disables WebRTC globally. You can also flip it on per-site by clicking the uBlock icon and toggling the WebRTC switch in the Element-zapper / Element-picker row. **Option 3: WebRTC Control extension** Third-party extension that adds a one-click toggle in the toolbar. Convenient but you are now trusting a third-party extension with access to your network configuration, so prefer uBlock Origin if you already use it. **Bonus: Chrome enterprise policy** If you manage a fleet, set `WebRtcLocalIpsAllowedUrls` and `WebRtcIPHandling` policies via group policy / managed preferences. `default_public_interface_only` is the strongest policy without breaking calls; `disable_non_proxied_udp` is the strongest if you are forcing a proxy. ## Brave specifically Brave is the easiest Chromium-based browser because it exposes the underlying Chromium WebRTC IP Handling Policy as a settings toggle: 1. Open Brave Settings -> Shields -> Privacy and security -> WebRTC IP Handling Policy The four options: - **Default** - WebRTC behaves as Chromium ships it, includes public and private IPs - **Default Public and Private Interfaces** - default plus advertises private IPs (rare; do not pick this) - **Default Public Interface Only** - your recommended default if you use video calls. Hides the LAN IPs, public IP via STUN is still visible (which is your VPN IP if you are tunneled) - **Disable Non-Proxied UDP** - the strongest. WebRTC only works through a proxy if you have one configured, otherwise it cannot establish connections. Picks calls to die unless you proxy them, but no IP leak. For most people on a VPN, **Default Public Interface Only** is the sweet spot. For maximum privacy, **Disable Non-Proxied UDP** plus a SOCKS5 proxy is the move. ## Safari Safari on macOS hides WebRTC controls in the Develop menu, which is not enabled by default. 1. Safari menu -> Settings -> Advanced 2. Check "Show features for web developers" (older macOS: "Show Develop menu in menu bar") 3. Develop menu -> WebRTC -> uncheck **Enable Legacy WebRTC API** 4. Develop menu -> WebRTC -> check **Disable ICE Candidate Restrictions** if you want testing; **leave unchecked** for privacy Safari historically leaks less than Chrome because it does not include local IPs by default in the same way and it gates camera/microphone access more aggressively. It is not leak-free, but the floor is higher. **iOS Safari** does not expose any of these toggles in the iOS Settings app. The mitigation is **Lockdown Mode** (Settings -> Privacy and Security -> Lockdown Mode), which disables several web features including some WebRTC behaviors, at the cost of breaking many websites. It is overkill for most users but exists if you need it. ## Mullvad Browser, LibreWolf, Tor Browser These three Firefox forks ship with WebRTC restricted out of the box: - **Tor Browser**: WebRTC is fully disabled. Calls in the browser do not work, which is by design. The Tor Browser threat model treats real-time peer-to-peer connections as fundamentally incompatible with onion routing anonymity. - **Mullvad Browser**: Built in collaboration with the Tor Project. Same hardened Firefox base as Tor Browser, but without the Tor network. WebRTC is restricted to `default_address_only` mode, which means LAN IPs are not included. Full peer-to-peer calls require manual configuration changes. - **LibreWolf**: A privacy-respecting Firefox fork. WebRTC is enabled but `media.peerconnection.ice.no_host` is true by default, so LAN IPs are hidden but you can still place WebRTC calls. If you already use one of these three, you are doing the right thing. Verify with browserleaks.com but you should see no LAN-IP leakage. ## The mDNS .local change explained Chrome made a quiet, important change in 2019: instead of advertising raw LAN IPs (e.g. `192.168.1.42`) in ICE candidates, it now advertises a random `.local` mDNS hostname (e.g. `4e7f3b8a-...local`). The page sees a random hash, not your LAN IP. Other peers on your local network can still resolve that hostname via mDNS, so video calls between two devices on the same Wi-Fi still work. This is real progress. It mitigates the **local IP leak** vector. It does **not** mitigate the **public IP leak** vector via STUN, because the public IP reply from the STUN server is still readable by the page. Firefox added the same mDNS mitigation in 2021 by default. Safari has had similar behavior for longer. So the rough state of things in 2026: | Browser | LAN IP leak | Public IP leak (no VPN) | Public IP leak (with VPN) | |---|---|---|---| | Chrome | Mitigated (mDNS) | Yes (via STUN) | Depends on VPN routing | | Firefox | Mitigated (mDNS) | Yes (via STUN) | Depends on VPN routing | | Brave (default) | Mitigated | Yes | Depends | | Brave ("Default Public Interface Only") | Mitigated | Yes | VPN IP only | | Safari | Mostly mitigated | Yes | Depends | | Tor Browser | Disabled | N/A | N/A | | Mullvad Browser | Mitigated by default | Yes if WebRTC used | VPN IP only | The phrase "depends on VPN routing" matters: a VPN with a properly enforced kill switch and full UDP tunneling will route the STUN traffic over the tunnel and the STUN server will reply with the VPN exit IP. A VPN that splits UDP traffic, has a leaky kill switch, or does not route IPv6 may leak. This is why we recommend testing. ## Mobile **Android Chrome** does not expose `chrome://flags` for WebRTC IP handling on production builds. The best mitigation is to install a privacy-focused browser like Brave (which has the same WebRTC IP Handling Policy toggle on Android), Mullvad Browser for Android, or Firefox for Android with `media.peerconnection.enabled=false` via `about:config`. **Firefox Focus** for Android and iOS blocks WebRTC by default along with trackers and ad networks. Light-touch privacy mode for mobile. **iOS** is constrained because Apple forces all third-party browsers to use the WebKit engine. Brave, Firefox, DuckDuckGo on iOS all share Safari's WebRTC implementation. The only meaningful iOS mitigation is Lockdown Mode for high-threat users. ## What disabling WebRTC actually breaks Be honest about the tradeoff before you flip the switch: - **Google Meet, Zoom in browser, Whereby, Jitsi Meet in browser**: will fail to connect - **Discord voice/video in browser**: will not work (the Discord desktop app uses its own networking and is fine) - **WhatsApp Web calls, Telegram Web calls**: will not work - **Some browser-based games**: ones that use WebRTC data channels for low-latency peer connections will not work - **Screen sharing on most web meeting tools**: will not work - **Twitch low-latency mode** and some streaming overlays: may degrade If you make video calls frequently, the right answer is usually not to disable WebRTC fully. The right answer is: use Brave's "Default Public Interface Only" or Firefox's `media.peerconnection.ice.no_host=true`, run your VPN with a real kill switch, and test with browserleaks.com. ## The killswitch alternative If WebRTC matters for your work, the practical answer is a properly configured VPN with a system-level kill switch. NordVPN's CyberSec/Threat Protection and Mullvad's app-level kill switch both block all traffic - including WebRTC's UDP - when the tunnel drops, so even if WebRTC tries to leak, the packets cannot leave the machine. Mullvad on Linux uses `nftables` rules to block the physical interface entirely when the VPN drops. For the strongest setup: **Mullvad VPN + Mullvad Browser**. Mullvad Browser limits WebRTC to safe candidates by default, Mullvad VPN's kill switch catches anything that slips through, and the Mullvad account itself is anonymous. See our [VPN comparison](/blog/nordvpn-vs-protonvpn-vs-mullvad-2026) for the full picture. ## FAQ **Q: Does using a VPN automatically fix the WebRTC leak?** No. A VPN reroutes most traffic, but WebRTC can establish UDP connections from inside the browser process that may take a different route depending on your OS routing table. A VPN with a strict kill switch and full UDP routing typically prevents the leak; without those, the leak survives the tunnel. **Q: Is the mDNS .local thing enough? Can I just leave WebRTC on?** The mDNS mitigation removes one specific leak (your LAN IP). It does not remove the STUN-reflected public IP. If you are behind a properly configured VPN, the STUN reply is your VPN exit IP, which is fine. If you are not behind a VPN, the page learns your real public IP. Decide based on your threat model. **Q: Why does my video call work even after I disabled WebRTC in `about:config`?** You probably disabled it in one Firefox profile but the call uses another browser. Check `about:config` again in the actual Firefox you opened the call in. Or the meeting tool fell back to a non-WebRTC path (rare). **Q: Does Tor Browser leak via WebRTC?** No. Tor Browser disables WebRTC entirely. This is the entire reason your video calls do not work in Tor Browser. **Q: Are there any sites that detect "WebRTC disabled" and block me?** A few fingerprinting-heavy fraud-detection scripts treat "WebRTC disabled" as a signal of bot or VPN use. Banks rarely care. Anti-fraud services like Forter or Sift may flag the session. If you are doing legitimate banking, you may need to enable WebRTC temporarily for the session and disable it after. **Q: What about HTTP/3 and QUIC - do those leak IPs too?** HTTP/3 uses QUIC over UDP. It does not perform STUN-style external IP discovery, so it does not leak in the same way. WebTransport and WebRTC's data channels are the surface to worry about. **Q: Should I just use Mullvad Browser and call it done?** For most people who care about this, yes. Mullvad Browser ships with WebRTC restricted, fingerprinting resistance from the Tor Project codebase, no telemetry, and works with any VPN (or no VPN). It is the lowest-effort privacy upgrade in 2026. ## Action items 1. Open one of the three test pages above and see what your browser currently exposes. 2. Apply the relevant fix for your browser from this guide. 3. Re-test. Confirm public IP is your VPN exit IP and the local IP field shows `.local` or nothing. 4. If you frequently take video calls, switch to the partial mitigation rather than the full disable. 5. Combine with a VPN that has a real kill switch - see the [NordVPN vs ProtonVPN vs Mullvad comparison](/blog/nordvpn-vs-protonvpn-vs-mullvad-2026). 6. Run the [PrivacyScore browser test](https://privacyscore.dev) to see what else your browser is exposing - WebRTC is one signal, but [canvas fingerprinting](/blog/canvas-fingerprinting-explained) and the dozen other surfaces are still wide open by default.