The Browser-Level Privacy Gap That Most VPNs Don't Mention
You connected to your VPN, confirmed your public IP changed, and assumed you were private. Then you visited a site that ran a WebRTC probe, and it reported your real home IP address — the one assigned by your ISP — right alongside your VPN's IP. This is the WebRTC leak problem, and it affects every Chromium-based browser by default.
WebRTC (Web Real-Time Communication) is a browser API built for video calls, voice chat, and peer-to-peer file transfers directly between browsers without requiring a plugin. It is a legitimate and widely used technology. The privacy problem arises from how WebRTC discovers network paths: it uses a protocol called ICE (Interactive Connectivity Establishment) that queries STUN servers to identify all available network interfaces on your device, including local network addresses and your true public IP, bypassing the VPN tunnel entirely.
How the WebRTC IP Leak Mechanism Works
When a browser initiates a WebRTC session, it generates ICE candidates — a list of network paths that could be used for the peer-to-peer connection. The process works as follows:
- The browser contacts one or more STUN servers (Session Traversal Utilities for NAT) to discover its externally visible IP address from the perspective of the STUN server.
- The browser also enumerates local network interfaces and includes those addresses as ICE candidates.
- These candidates — including both local private IPs and the external public IP seen by the STUN server — are sent to the remote peer as part of the connection negotiation.
- Critically, the STUN binding requests travel through UDP on a separate path from your normal browser traffic, which means they bypass the routing rules that push your other traffic through the VPN tunnel.
The result is that your real ISP-assigned public IP appears in the ICE candidates even when a VPN is active, because the STUN request used a direct UDP path that the VPN did not intercept. Any webpage running JavaScript with WebRTC access can read these candidates and therefore determine your real IP without your knowledge.
How to Check If You Have a WebRTC Leak Right Now
With your VPN connected, navigate to a WebRTC leak testing page. The test attempts to establish a WebRTC connection and reads the ICE candidates your browser reports. If you see an IP address that belongs to your ISP's block rather than only the VPN server's IP, you have an active leak. Note both the public IP leak and any local (private) IP leak — the latter reveals your internal subnet range, which can be used for network fingerprinting.
How to Disable WebRTC in Firefox
Firefox provides a direct configuration option to disable WebRTC entirely:
- Type
about:configin the address bar and press Enter. - Accept the warning about advanced settings.
- In the search bar, type
media.peerconnection.enabled. - Double-click the preference to toggle its value from
truetofalse.
This completely disables WebRTC in Firefox. Video calling features on sites that use the browser's WebRTC API will stop working, but all other browsing is unaffected. If you need WebRTC for specific sites and want to control it per-site rather than globally, the Firefox extension uBlock Origin can block WebRTC on a per-domain basis.
An alternative that preserves WebRTC functionality while preventing IP leaks is to set media.peerconnection.ice.default_address_only to true in about:config. This restricts WebRTC to using only the default network interface rather than enumerating all available IPs, which prevents local IP disclosure and typically prevents real public IP exposure through the tunnel.
How to Disable WebRTC in Chrome and Chromium-Based Browsers
Google Chrome does not expose a native WebRTC disable flag in its UI. The most reliable approach is using a browser extension:
- WebRTC Leak Prevent: Available from the Chrome Web Store. It uses the Chrome extension API to modify how WebRTC handles IP enumeration, restricting it to the default route only. After installing, open the extension options and set the IP handling policy to Disable non-proxied UDP for maximum protection.
- uBlock Origin: In addition to its ad-blocking function, uBlock Origin has a WebRTC IP leak prevention option. Go to the uBlock Origin dashboard, find the Settings tab, and enable Prevent WebRTC from leaking local IP addresses.
Chrome's built-in privacy options in Settings > Privacy and Security do not include a WebRTC control, so an extension is mandatory for Chrome users.
How to Disable WebRTC in Microsoft Edge
Edge is Chromium-based and inherits Chrome's WebRTC behavior. The same extensions available for Chrome work identically in Edge. Additionally, Edge has a native option:
- Navigate to
edge://flags. - Search for WebRTC.
- Look for the flag Anonymize local IPs exposed by WebRTC and set it to Enabled.
This flag restricts local IP enumeration but does not fully disable WebRTC. For complete leak prevention in Edge, pair this flag with a WebRTC control extension.
How to Disable WebRTC in Safari
Safari's WebRTC implementation is more restrictive than Chrome's by default. Apple built in IP handling policies that do not enumerate all network interfaces in the same aggressive manner. For most users, Safari on macOS and iOS does not exhibit the same WebRTC leak behavior as Chrome. If you want to verify this, run a leak test with Safari before taking any additional steps.
Comparison: WebRTC Control Methods by Browser
| Browser | Native Disable Option | Extension Available | Default Leak Risk | Recommended Action |
|---|---|---|---|---|
| Firefox | Yes — about:config | Yes (uBlock Origin) | High without config change | Set media.peerconnection.enabled to false |
| Chrome | No | Yes (WebRTC Leak Prevent) | High | Install WebRTC Leak Prevent, set to disable non-proxied UDP |
| Edge (Chromium) | Partial (flags) | Yes (Chrome extensions) | High without changes | Enable anonymize flag + install extension |
| Safari | No control needed typically | Limited | Low by default | Run leak test; action usually not required |
| Brave | Yes — Shields setting | Optional | Low — blocked by default in Shields | Confirm Fingerprinting protection is set to strict in Shields |
VPN-Level Mitigation
Some VPN clients include WebRTC leak protection at the network driver level, inserting routing rules that force all UDP traffic — including STUN requests — through the VPN tunnel. This approach can be effective, but it depends on correct implementation. A VPN with this feature should still be tested using a WebRTC leak tool to confirm the protection is working. Browser-level fixes and VPN-level mitigations are complementary rather than redundant.
Common Misconceptions
WebRTC Only Leaks If You Use Video Calling
The WebRTC API is initialized in browsers regardless of whether you are actively using video or audio features. Any JavaScript on a webpage can call the WebRTC APIs to probe for ICE candidates without the user's awareness and without establishing any visible call. The leak occurs at the API access level, not at the application usage level.
HTTPS Prevents WebRTC IP Leaks
HTTPS encrypts the content of your traffic and authenticates the server you are connecting to. It has no effect on the WebRTC API, which operates independently of the HTTP request/response cycle. Your IP can be leaked via WebRTC on an HTTPS site just as readily as on an HTTP site.
Using a VPN Automatically Fixes WebRTC Leaks
Most VPN clients route TCP and UDP traffic through the tunnel, but WebRTC STUN requests travel via UDP on a code path that many VPN implementations do not intercept. The VPN changes your apparent IP for general browsing while the browser's WebRTC implementation simultaneously reports your real IP via a separate channel. Both fixes — VPN and WebRTC disable — are necessary for complete IP masking.
Disabling WebRTC Breaks All Browser-Based Video Calls
Disabling WebRTC entirely does break services that rely on browser-native WebRTC for video calling — Google Meet, WhatsApp Web, and similar tools will not function without it. However, there is a middle-ground option: restrict WebRTC to the default network interface only rather than disabling it outright. This prevents IP leakage while preserving functionality for applications that need the API.
Pro Tips
- Run a WebRTC leak test as the first step after setting up any VPN. Do not assume the VPN handles it. Test first, configure as needed, then re-test to confirm the fix worked.
- Test with WebRTC protection enabled and VPN disconnected. This confirms the WebRTC restriction is working independently of the VPN and gives you a baseline expectation of which IPs should appear in results.
- Use Brave Browser if you want WebRTC protection without additional configuration. Brave's Shields feature blocks fingerprinting APIs including WebRTC IP enumeration by default, making it the lowest-friction option for privacy-conscious users who do not want to install extensions or modify about:config.
- Audit browser extensions that have access to your network requests. Some extensions with broad permissions can themselves leak your IP through their own network calls. Audit what extensions you have installed and remove any that request more network access than they functionally require.
- For maximum protection on Firefox, set both the peerconnection flag and the ice default address flag. Disabling
media.peerconnection.enabledblocks WebRTC entirely; settingmedia.peerconnection.ice.default_address_onlytotrueas a supplementary measure ensures that if the first setting is ever reset, the fallback still restricts IP exposure. - Re-test after every browser update. Browser updates can reset flags or change how WebRTC is handled internally. A fix that worked in the previous version may need to be reapplied after a major update.
After fixing your WebRTC settings, confirm your real IP is no longer visible — verify your IP and WebRTC status here.