Do modern browsers still leak local IPs over WebRTC?

Mostly no. Since around 2019, Chrome, Firefox, Safari and Edge replace local IP addresses in WebRTC candidates with anonymous mDNS names, so the old trick of reading someone's LAN address from JavaScript no longer works in a default browser.

Can WebRTC leak my IP when I use a VPN?

With a full-device VPN, generally no — STUN traffic rides the tunnel like everything else, so WebRTC discovers the VPN's IP. The real risk is browser-level tools such as VPN extensions or SOCKS/HTTP proxies, which usually don't carry UDP; STUN then goes out over your real connection and exposes your real public IP.

What is a WebRTC leak, and should you still worry about it?

Q: What is a WebRTC leak?

WebRTC is the browser technology behind in-page video calls. To connect peers directly it discovers your network addresses using STUN, and a page's JavaScript can read what it finds. A WebRTC leak is when that discovery reveals an IP address you meant to hide — classically your real public IP while using a browser proxy or VPN extension.

Q: How do I stop WebRTC leaks?

Prefer a full-device VPN over a browser extension, and test with a WebRTC leak page — the only addresses visible should belong to the VPN. For extra hardening you can disable WebRTC (media.peerconnection.enabled in Firefox) or use an extension that restricts it, at the cost of breaking in-browser calls.

A WebRTC leak is when the browser's real-time communication machinery reveals an IP address you meant to hide — and in 2026 the honest answer is: default browsers have fixed the worst of it, full-device VPNs are largely immune, and the risk that remains is concentrated in browser proxies and VPN extensions, which don't carry the UDP traffic WebRTC uses. This guide explains the mechanism, what changed, and how to test your own setup instead of trusting a headline from 2015.

Maintained by the ipconfig.io team · Reviewed 1 July 2026

How WebRTC discovers your addresses

WebRTC exists so two browsers can talk directly — video calls, screen sharing, file drops — without routing every packet through a server. To set that up, each browser has to figure out every address it might be reachable at. It collects candidates: local interface addresses, and the public address it discovers by asking a STUN server "what do I look like from the outside?"

The catch: a web page's JavaScript can initiate that discovery and read the candidates. No permission prompt, no camera access needed. That's the entire leak — a side channel where the browser volunteers addresses the rest of your setup was hiding.

What still leaks, and what doesn't

Setup	What WebRTC exposes today
Default browser, no VPN	Your public IP (which any site sees anyway) — local IPs are masked with mDNS names in modern browsers
Full-device VPN (native app)	The VPN's IP — STUN rides the tunnel with everything else. No real-IP leak
VPN browser extension / SOCKS or HTTP proxy	Often your real public IP — proxies carry TCP for pages, but STUN is UDP and goes out over the raw connection
Tor Browser	Nothing — WebRTC is disabled outright

Two things changed since the scare era. Browsers stopped exposing local addresses (they're replaced by anonymous .local mDNS names since roughly 2019), and mainstream VPN apps moved to full-tunnel designs that capture UDP. What did not change is the extension/proxy gap: anything that only proxies browser TCP leaves STUN free to use your real route.

How do I test for a WebRTC leak?

First establish what your tunnel shows at the IP layer:

bash

curl ipconfig.io

On VPN, that's the VPN's address — your baseline. Then open a WebRTC leak test page (BrowserLeaks' WebRTC test is the usual choice) in the browser you actually use, with your VPN or proxy active. Compare:

Every public address WebRTC finds matches the VPN IP → no leak.
Your real public IP appears in the candidates → your setup proxies pages but not STUN. That's the leak.

Test after browser updates and VPN client changes, not just once — this is configuration-dependent, and configurations drift.

How do I stop WebRTC leaks?

In order of effectiveness:

Use a full-device VPN app instead of a browser extension. This closes the gap structurally: STUN can only see the tunnel. Proton VPN's native apps tunnel all traffic including UDP and are audited no-logs. (Affiliate link; it helps keep ipconfig.io free. Any full-tunnel client closes this gap.)
Disable or restrict WebRTC if you don't use in-browser calling: in Firefox set media.peerconnection.enabled to false; in Chromium-based browsers use an extension that limits WebRTC's network access. The cost is that video calls in the browser stop working.
Re-test. Hardening you haven't verified is a hope, not a control.

Frequently asked questions

What is a WebRTC leak? The browser's peer-to-peer machinery (STUN candidate discovery) revealing an IP you meant to hide — readable by page JavaScript without any permission prompt.

Do modern browsers still leak local IPs? Mostly no — since ~2019, local addresses in candidates are masked with anonymous mDNS names in Chrome, Firefox, Safari and Edge.

Can WebRTC leak my IP through a VPN? Through a native full-device VPN, generally no. Through a VPN browser extension or SOCKS/HTTP proxy, yes — STUN's UDP traffic bypasses tools that only proxy browser TCP.

How do I stop it? Full-device VPN first, WebRTC restriction second, and verify with a leak test page — the only visible addresses should be the VPN's.

Next steps

Check if your VPN is leaking your real IP — the tunnel-level test this guide builds on.
What is a DNS leak? — the other quiet channel that undoes a VPN.
What can someone do with your IP address? — what's actually at stake when an address slips out.

What is a WebRTC leak, and should you still worry about it? ​

How WebRTC discovers your addresses ​

What still leaks, and what doesn't ​

How do I test for a WebRTC leak? ​

How do I stop WebRTC leaks? ​

Frequently asked questions ​

Next steps ​