WebRTC IP Leak Test

Check, entirely inside your browser, whether WebRTC is exposing an IP address that bypasses your VPN or proxy — a real leak — versus simply showing the same public IP the website can already see. We compare what WebRTC finds against your actual exit IP, so you do not get the false alarm that older testers raise for everyone without a VPN. Modern mDNS obfuscation is correctly treated as protected.

Ready to test Tap the button below to gather WebRTC candidates from your browser.

🔒 The test runs in your browser. The addresses WebRTC finds are read in JavaScript only to show them to you and are never sent to us or stored. A public STUN server is contacted only to trigger candidate gathering — it never receives your discovered addresses. We make one request to our own /api/ip edge endpoint, which just echoes back the public IP your connection already exposes so we can compare it to what WebRTC found; it is not logged.

What is the WebRTC IP Leak Test?

This WebRTC IP leak test checks, entirely inside your own browser, whether WebRTC is exposing a public IP address that bypasses the VPN or proxy you are relying on. WebRTC is the feature browsers use for real-time calls and peer-to-peer data, and to set up a connection it gathers a list of network ICE candidates that can include the IP addresses of your device. Any web page can read those candidates with a few lines of JavaScript. The important nuance most testers get wrong: finding a public IP is only a leak when it is a different address from the one the site already sees. If you are not using a VPN, your public IP is what every website observes anyway, so WebRTC revealing that same address tells a site nothing new. A true leak is when WebRTC surfaces an address that slips past your tunnel.

How to use it

Tap Start test. The page creates a temporary WebRTC connection, collects ICE candidates for a few seconds, and at the same time asks our own edge for the public IP your connection actually exits from.
Read the verdict at the top. It is a pass when no public IP is exposed or when WebRTC only shows the very same public IP the site can already see; it is a leak only when WebRTC reveals a different public IP that bypasses your exit.
Look at the list of addresses below it. Each one is labelled as an obfuscated mDNS name, a private LAN address, or a routable public IP, and you can copy any value with one tap.
If the result shows a real leak, follow the fix steps, change your setup, and run the test again to confirm the leak is gone. The whole thing takes a second and nothing is saved.

The method behind it

The test opens an RTCPeerConnection pointed at a public STUN server, creates a data channel, builds an offer, and calls setLocalDescription. That sequence forces the browser to begin ICE gathering and fire an onicecandidate event for every candidate it finds. Each candidate is a short text line; this page extracts the IPv4 and IPv6 addresses from it with a regular expression, then closes the connection. In parallel it makes a single request to our own /api/ip edge endpoint, which simply reflects back the public IP your connection exits from — the address every website you visit already sees.

Every discovered address is classified locally. A value ending in .local is an mDNS host candidate — the browser deliberately hides your real LAN IP behind a random ephemeral hostname, so it is reported as protected, not leaked. Addresses inside the private ranges are labelled local. Anything else is a routable public address, which we then compare against your exit IP. If the public IP WebRTC found matches your exit IP (an exact match for IPv4, or the same /64 network for IPv6, since IPv6 privacy extensions rotate the low bits), it is the same address the site already sees and is not a leak. If it is a different public IP, WebRTC has surfaced an address that bypasses your exit, and that is a genuine leak. If your exit IP cannot be reached, we report the public IP as a neutral finding rather than guessing either way.

The STUN server is contacted purely to make the browser gather candidates. It is never sent the addresses the browser finds, and none of the results ever leave your device beyond the unavoidable exit-IP lookup, which only echoes an address the network already exposes.

How to read the result

mDNS (.local): a privacy-protected placeholder. Your real LAN IP is hidden — this is the safe modern default and is not a leak.
Local / private: an internal address such as 192.168.x or 10.x. It only identifies a device on your own network and is not routable on the public internet.
Public, matching your exit IP: the same address the website already sees. Without a VPN this is normal and exposes nothing new, so it is not a leak.
Public, different from your exit IP: WebRTC found an address that bypasses your tunnel. If you are using a VPN or proxy, this is a real leak — fix it with the steps below.

How to fix or prevent a leak

Use a VPN or a browser extension that blocks or proxies WebRTC traffic.
Keep your browser's default mDNS obfuscation enabled so your real LAN IP stays hidden.
Disable WebRTC where you do not need it — for example via about:config in Firefox, or a privacy extension in Chromium browsers.
Re-run this test afterward to confirm WebRTC only surfaces your VPN's public IP — which then matches your exit IP — or no routable public IP at all.

Common use cases

Verifying a VPN covers WebRTC: confirm the tunnel hides your address for peer-to-peer traffic, not just ordinary page requests.
Confirming mDNS is on: check that your browser is obfuscating the real LAN IP behind a .local name.
Testing a privacy extension: run the test before and after enabling a WebRTC blocker to see the difference.
Quick device check: on any device, see what a website could learn about your network through WebRTC.

Why use this one

Many WebRTC testers raise a red alarm the moment any public IP appears in the candidates — which means they scare every visitor who is not using a VPN, since that person's public IP naturally shows up and is exactly what every site already sees. Older testers also flag a harmless .local mDNS candidate as a leak. This tool gets both right. It separates obfuscated mDNS names and private LAN addresses from routable public IPs, and then compares any public IP against your real exit address: the same IP is not a leak, only a different one that bypasses your tunnel is. The result is a single, honest verdict instead of a false alarm. It runs in your browser, the discovered IPs never touch a server of ours, the only network call simply echoes the public IP your connection already reveals, and it pairs a real leak with concrete fix steps. It stays minimal and mobile-friendly so you get the answer in one tap and move on.

This tool is part of a small set for seeing what your connection and browser reveal. To check the public address servers actually see, use What Is My IP; to inspect the identification string your browser sends, use What Is My User Agent; and to see the display your device reports, use What Is My Screen Resolution.

Frequently asked questions

What is a WebRTC leak?

WebRTC is a browser feature for real-time audio, video, and data. To connect peers it gathers ICE candidates, which can include your device's local and public IP addresses. A WebRTC leak happens when a website reads those candidates with JavaScript and learns your real IP even though you are behind a VPN or proxy — because WebRTC can find an address that bypasses the tunnel. This test checks for exactly that.

I see an address ending in .local — is that a leak?

No. A *.local value is an mDNS host candidate, the privacy protection modern browsers turn on by default. Instead of revealing your real LAN IP, the browser shows a random ephemeral .local hostname that means nothing to a remote site. Seeing only .local and your VPN's public IP means your real local IP is NOT exposed, so this test reports no leak.

Does this tool send my IP anywhere?

No. The whole test runs inside your browser. The RTCPeerConnection gathers candidates locally and this page reads them in JavaScript only to show them to you. We contact a public STUN server purely to trigger candidate gathering — it is never sent your discovered addresses, and none of the results are uploaded to us or stored.

How do I fix or prevent a WebRTC leak?

Use a VPN or browser extension that blocks or proxies WebRTC, keep your browser's default mDNS obfuscation enabled, or disable WebRTC entirely where you do not need it (for example via about:config in Firefox, or a privacy extension in Chromium browsers). Re-run this test afterward to confirm only your VPN's public IP — or no routable public IP at all — appears.

The test says WebRTC is unavailable — what does that mean?

Your browser either does not support RTCPeerConnection or has WebRTC disabled or blocked by a setting or extension. That is the safest possible state for this leak vector: with no WebRTC, there are no candidates for a site to read, so there is nothing to leak.