What Is WebRTC and How Does It Affect Browser Privacy?

What WebRTC Actually Is

WebRTC stands for Web Real-Time Communication. Google open-sourced the project in 2011 after acquiring the VoIP engine company Global IP Solutions (GIPS), and it matured into a joint IETF/W3C standard — WebRTC 1.0 became an official W3C Recommendation in January 2021. Today it is built into every major browser engine: Chrome, Edge, Firefox, Safari, and Opera all ship full support.

Before WebRTC, real-time voice and video in a browser required plugins like Flash. WebRTC replaced that with three core JavaScript APIs:

• getUserMedia — accesses the camera and microphone (requires an explicit permission prompt).
• RTCPeerConnection — creates and manages the peer-to-peer connection (requires no permission prompt).
• RTCDataChannel — sends arbitrary low-latency data between peers.

That second bullet is the privacy crux. Camera access asks for consent; connection setup does not. Any script on any page can instantiate an RTCPeerConnection and start reading the network candidates your device generates — which is exactly how websites track you beyond cookies and fingerprints.

How WebRTC Discovers Your IP Address

Most devices sit behind a router using NAT (Network Address Translation), so they don’t know their own public address. To connect two peers, WebRTC uses the ICE framework (Interactive Connectivity Establishment), which gathers a list of “candidates” — possible addresses for the connection — using two helper protocols:

• STUN (Session Traversal Utilities for NAT): the browser asks an external STUN server, “what address do you see me coming from?” The answer — the server-reflexive candidate — is your true public IP and port.
• TURN (Traversal Using Relays around NAT): a fallback relay when direct connection fails.

The browser collects all of these candidates and hands them to JavaScript via the onicecandidate event. A tracking script only has to read that event to learn addresses your HTTP traffic never reveals. This is the technical heart of what a WebRTC leak is.

WebRTC Privacy Statistics & Charts

WebRTC is nearly universal in browsers, which is exactly why its leak surface matters. The figures below come from browser compatibility data, security reporting, and peer-reviewed VPN research.

Other numbers worth knowing: reporting in the years after the 2015 disclosure found roughly 20% of top VPN solutions still leaked customer IPs via the WebRTC bug, and modern Chromium only neutralized the local-IP half of the problem when it made mDNS obfuscation default (the old “Anonymize local IPs exposed by WebRTC” flag disappeared around Chrome 86). The public-IP half still depends on your VPN or browser configuration.

The WebRTC Leak, Explained

In January 2015, researchers published a simple proof-of-concept showing that a webpage could use RTCPeerConnection to read the real IP addresses of users sitting behind VPNs. The fallout was immediate because the leak worked in the most privacy-conscious setups and required nothing from the victim — no click, no permission, no download.

The leak has two halves:

1. Local IP disclosure: host candidates expose private addresses like 192.168.1.24, revealing your LAN topology and giving trackers a stable internal identifier that survives IP changes.
2. Public IP disclosure: STUN binding requests can return your true public address — the one assigned by your ISP — even while your normal HTTP traffic shows the VPN’s IP.

Browser vendors eventually mitigated the first half: Chrome and Safari now hide local IPs behind mDNS .local hostnames by default, and Firefox offers equivalent protections. But mDNS obfuscation does not, by itself, stop a misconfigured VPN tunnel from answering STUN requests with your real public IP. And it does nothing about the fact that a site can still observe your ICE behavior as a signal.

WebRTC vs. VPNs and Proxies

A VPN encrypts and reroutes your traffic, but WebRTC leaks survive in three common configurations:

• Split-tunnel or leaked UDP: the VPN tunnels TCP but drops or bypasses UDP, so STUN requests go out over your real connection.
• IPv6 leaks: the VPN tunnels IPv4 only; WebRTC happily uses the IPv6 path and hands over your real address.
• Reconnect gaps: during VPN drops without a kill switch, a persistent WebRTC session re-announces your real candidates.

This is why comparing an anti-detect browser vs. VPN vs. proxy matters: each tool covers a different layer. A VPN changes your route, a proxy changes one app’s route, and an anti-detect browser lets you set a policy for WebRTC per identity — for example, “block non-proxied UDP” so STUN can only ever see the proxy’s address. And remember that none of these tools touch your device fingerprint: a VPN does not change your browser fingerprint, so WebRTC control is only one layer of a complete identity.

How to Block or Control WebRTC in Every Browser

After changing anything, verify with a leak test that shows host, mDNS, and public candidates separately. If you also want to audit the rest of your exposure surface, our guide on what browser fingerprinting is covers the other half of the identity equation.

WebRTC in Anti-Detect Browsers and Isolated Profiles

For professionals managing multiple accounts, the question is not “should WebRTC be on or off?” but “what should WebRTC see for this identity?” That is the philosophy behind browser profile isolation: every profile gets its own cookies, storage, fingerprint, proxy — and its own WebRTC policy.

Typical per-profile policies in serious anti-detect tools include:

• Disabled: no peer connections at all; safest for pure browsing identities.
• Proxy-only UDP: STUN may run, but only through the profile’s proxy, so candidates match the identity’s geolocation.
• Local IP substitution: host candidates are replaced with values consistent with the profile’s story instead of your real LAN.

Consistency is the point. A profile that claims to be a Berlin user on a German residential proxy but answers STUN with a Texas ISP address is instantly flaggable. Per-profile WebRTC control keeps the network layer and the fingerprint layer telling the same story.

Is WebRTC “Bad”? A Balanced View

No. WebRTC is one of the most useful web standards of the last decade — it removed plugins, enabled end-to-end encrypted calls, and powers telehealth, remote education, and low-latency gaming. The privacy issue is not the technology; it is silent disclosure: a connection-setup protocol revealing network identity without user awareness or consent.

The healthy posture is control, not panic:

• Understand that WebRTC is one vector among many — cookies, pixels, CNAME cloaking, and fingerprinting complete the picture of whether you can really browse anonymously.
• Use mDNS-protected, updated browsers so local IPs are never broadcast in the clear.
• Use VPNs that explicitly handle UDP and IPv6, with a kill switch.
• Use per-profile WebRTC policies for any multi-account or high-privacy work.

WebRTC Privacy Checklist

• Run a WebRTC leak test and note which candidates (host / mDNS / public) your browser exposes.
• Confirm your browser is mDNS-protected (modern Chrome, Edge, Safari, Firefox).
• If on a VPN, verify it tunnels UDP and IPv6 and offers a kill switch; re-test with WebRTC enabled.
• Disable WebRTC in Firefox via media.peerconnection.enabled if you never use in-browser calls.
• In Brave, set WebRTC IP handling to “Disable non-proxied UDP” when proxying.
• For multi-account work, use an anti-detect browser with per-profile WebRTC policies (e.g., Incogniton).
• Re-test after every browser or VPN update — defaults change.

Frequently Asked Questions

Sources and Research Notes