If your understanding of WebRTC privacy risk is based on advice from a few years ago, it's worth an update — browsers have made real, substantive changes to how WebRTC handles address exposure since the topic first became widely discussed.
mDNS host candidate masking
One of the more significant changes: browsers now commonly mask local network (host) candidates behind randomized .local hostnames using mDNS, rather than exposing a device's actual local IP address directly to a web page. This closes off a specific category of information exposure that was a legitimate concern in WebRTC's earlier implementations.
Permission model changes
Browsers have also tightened permission requirements around camera and microphone access that WebRTC typically needs for its primary use cases — though this doesn't change address-discovery behavior specifically, it reflects a broader trend toward more deliberate user consent for WebRTC-adjacent functionality.
Relay policy differences
How aggressively different browsers prefer relay (TURN) candidates over direct connections — which affects what addresses actually get exposed during connection setup — varies and continues to evolve across browser versions and vendors.
Why "every browser behaves alike" is no longer a safe assumption
Given how much has changed, and how differently browser vendors have implemented these changes, assuming uniform WebRTC privacy behavior across Chrome, Firefox, Edge and Safari is no longer reliable — see the browser-specific guides for Chrome, Firefox, Edge, and Safari for what to actually expect from each.
FAQ
Does this mean WebRTC leaks are no longer a real concern?
The public-address (server-reflexive) discovery mechanism that matters most for VPN leak scenarios is still present — testing your own setup with a WebRTC Leak Test remains the reliable way to know, rather than assuming based on general browser improvements.