The reason WebRTC can reveal your IP address isn't a bug — it's a byproduct of a feature working exactly as designed. Understanding the candidate-gathering process explains both why the exposure exists and what modern browsers do to limit it.
Why address discovery is necessary at all
To set up a direct connection between two browsers, each side needs to know which addresses the other can be reached at. WebRTC's ICE process gathers these "candidate" addresses — including your public IP, discovered via a STUN server — specifically so this connection-setup step can work.
What a page can observe
A web page running WebRTC code can, in principle, access the list of candidate addresses your browser gathers during this process — including a server-reflexive candidate showing your public IP, discovered independently of whatever your regular HTTP traffic shows (which matters specifically when a VPN is supposed to be hiding that same address).
How modern browsers limit this
Current browsers have added protections that didn't exist in WebRTC's earlier years — notably, masking local network candidates behind randomized .local hostnames (mDNS) rather than exposing your actual local IP directly to a page. This closes off one specific piece of information exposure, though it doesn't change how server-reflexive (public) candidate discovery works, which is the piece most relevant to VPN leak scenarios.
Why this still matters despite the improvements
The public-address discovery mechanism that can expose your real IP through a VPN hasn't been eliminated by these browser-level privacy improvements — it's still worth testing directly rather than assuming modern browser defaults fully solve the problem. See WebRTC Leak Test to check your own setup.
FAQ
Do all browsers handle this identically?
No — see Chrome, Firefox, Edge, and Safari WebRTC behavior guides for browser-specific differences.