WebRTC is a browser feature for real-time communication. As a side effect, it can reveal your real IP address to any website — and the leak happens even with a VPN connected if the VPN doesn't handle WebRTC at the network layer.
The test above runs the same code a website would, then compares what WebRTC discovers against your known public IP. If WebRTC finds an IP that isn't your VPN exit, that's a leak. Everything runs in your browser; nothing is sent to us.
The fix is a VPN that routes WebRTC's STUN lookups through the tunnel. Our free plan does this by default — there's no setting to enable, no extension to install.
What WebRTC is — and why it leaks
WebRTC is the browser feature behind video calls. It tries to find the most direct network path between peers, and that discovery process can reveal your real IP.
WebRTC (Web Real-Time Communication) is built into every modern browser. It powers Google Meet, Discord voice channels, browser-based video conferencing, peer-to-peer file transfer, and dozens of other features. The technology is genuinely useful — but it has a privacy quirk.
To establish a connection, WebRTC runs ICE candidate gathering. It asks the operating system "what IP addresses can someone reach me at?" — both local (192.168.x.x) and public (your real internet-facing IP). It collects this list by talking to STUN servers, which echo back what they see. Then it shares the list with the other peer.
The leak happens because any website's JavaScript can do this same gathering, even when you didn't ask it to start a video call. The website reads the discovered IPs and now knows the IP that should be hidden behind your VPN.
How this leak test actually works
It runs the same ICE gathering a malicious site would, against public STUN servers, then displays everything it discovers.
The test creates an RTCPeerConnection object configured with public STUN servers (Google's and Cloudflare's). It opens a data channel — a minimum trigger for ICE gathering — and then watches the onicecandidate event for the IPs WebRTC discovers along the way. The whole process takes one to three seconds.
Discovered IPs come in two flavours: host candidates (your local IPs, like 192.168.1.50) and srflx candidates (your public IP, as seen by the STUN server). Modern browsers anonymise local IPs by default using mDNS hostnames like xxx.local, which doesn't leak real network info. Public IPs are the privacy-critical ones.
We also fetch your public IP from /api/myip as a reference. If a WebRTC-discovered IP matches that reference, you're not leaking — both report the same IP because both go through your VPN. If they differ, you're leaking.
Interpreting the result
If the WebRTC public IPs match your reported IP, you're safe. If they differ, you're leaking your real IP.
The clean case: WebRTC reports the same public IP that /api/myip reports. Both numbers are your VPN's exit, and that's what every website you visit sees. Your VPN is doing its job.
The leak case: WebRTC reports a public IP that's different from the one /api/myip shows. The different IP is your real one — your ISP-assigned address, not the VPN's. Any website using WebRTC can read that IP from JavaScript, completely bypassing the VPN.
Local IPs in the result (host candidates) are usually fine. Modern browsers replace them with mDNS hostnames that look like a long random string ending in .local. Those don't reveal anything about your real network. If you see actual 192.168.x.x or 10.x.x.x in the host candidates, your browser has the mDNS protection turned off — a minor fingerprinting risk, not a leak of your real IP.
Why some VPNs fail at this
They route TCP through the tunnel but not UDP, or they don't bind every network interface to the tunnel.
A VPN client has two main approaches to routing your traffic. The clean approach is to capture every packet at the OS network layer and force it through the tunnel, no matter what protocol or interface. The lazier approach is to just install a default route through the tunnel and hope.
The lazy approach fails on WebRTC for two reasons. First, WebRTC uses UDP heavily for STUN, and UDP routing has more edge cases than TCP — some VPN clients don't handle them well. Second, some operating systems prefer specific interfaces for specific traffic types (mobile networks especially), and a VPN that only sets a default route gets bypassed.
The other failure mode is IPv6. If a VPN is IPv4-only and your network has IPv6 connectivity, WebRTC will happily try IPv6 STUN servers and reveal your real IPv6 address — completely outside the tunnel. Modern VPNs handle this by either tunneling IPv6 too or blocking it entirely.
How to fix a WebRTC leak
Use a VPN that handles WebRTC at the network layer. If you can't, disable WebRTC at the browser level.
The right answer is a VPN that captures all traffic — TCP, UDP, IPv4, IPv6 — and either tunnels it or drops it. OllaVPN's free plan does this by default. There's no setting to enable; the structural design prevents the leak class.
If you're stuck with a VPN that leaks and can't change, the browser-level fix is to disable WebRTC entirely. In Firefox, set media.peerconnection.enabled to false in about:config. In Chromium-based browsers, you'll need an extension — uBlock Origin has a "Prevent WebRTC from leaking local IP addresses" option in its settings. The downside is that you lose WebRTC features (video calls, P2P apps). Most users find this an acceptable trade if they can't fix the VPN side.
Frequently asked questions
What is a WebRTC leak?
WebRTC is a real-time communication feature built into every modern browser. It uses a process called ICE candidate gathering to find network paths between peers. A side effect: your browser can ask STUN servers for your public IP — and that lookup happens even when you have a VPN connected. If the browser doesn't route it through the tunnel, the site you're visiting can read your real IP from JavaScript, bypassing the VPN entirely.
Why does a VPN sometimes fail to protect against WebRTC?
The browser's WebRTC stack has its own ideas about which network interface to use. If your VPN doesn't reroute UDP traffic correctly, or if your browser tries IPv6 outside the VPN, your real IP leaks. Good VPN clients block WebRTC at the network layer to prevent this; lower-quality ones leave the door open.
How do I check if my browser is leaking?
Use the tool above. It runs the same WebRTC code a website would run, then compares the IPs it discovers against your known public IP. If the test finds an IP that isn't your VPN exit, that's a leak.
What's the difference between a local IP and a public IP in the result?
A local IP (like 192.168.1.50) is your address inside your home network. Sites can't directly use it. A public IP is what the wider internet sees — this is the one a VPN is supposed to replace. Modern Chrome and Firefox use mDNS hostnames for local addresses by default.
How do I fix a WebRTC leak?
Use a VPN that explicitly handles WebRTC at the network layer rather than relying on browser settings. As a backup, you can disable WebRTC entirely in some browsers or use an extension like uBlock Origin with WebRTC blocking enabled.
Does OllaVPN protect against WebRTC leaks?
Yes. OllaVPN's tunnel routes all UDP traffic — including the STUN lookups WebRTC uses — through the VPN. The browser doesn't even know there's a non-VPN path to leak over, so the leak class is eliminated structurally rather than papered over with browser settings.
Will this tool see my real IP if I'm leaking?
Yes — that's how the test works. The tool runs entirely in your browser, then displays the result to you only. We don't log the discovered IPs, transmit them to our servers, or share them. Open your devtools network tab while the test runs to verify nothing is sent.
Is WebRTC always a privacy risk?
Only when combined with a VPN that doesn't handle it. For normal browsing without a VPN, WebRTC just discovers the IP your ISP gave you — which is the same IP every other connection from your device uses. The risk is specifically that it can bypass a privacy tool that's supposed to hide that IP.