Skip to content

WebRTC Leak Test

The addresses WebRTC hands any page, against the IP this site sees.

WebRTC leak test

Asking your browser for the addresses WebRTC shares…

The IP this site sees

Address
Network
VPN, proxy or hosting

From the connection your browser opened to this page, like any site sees it.

The addresses WebRTC shares

Read in your browser; one request goes to Cloudflare's public STUN server, which answers with the public address it sees. Nothing is sent to us.

This WebRTC leak test shows whether your browser hands your real IP address to websites through WebRTC while you are on a VPN. It runs as soon as the page opens: your browser asks Cloudflare’s public STUN server which public address it sees, lists the local addresses it would share, and the test compares them with the address this site sees. What WebRTC reveals stays in your browser; nothing the test finds is sent to us.

What Is a WebRTC Leak?

WebRTC is the part of your browser that makes direct connections for video calls, voice chat and file transfers. To connect two browsers, each one gathers a list of addresses it can be reached at, called ICE candidates: its addresses on the local network (host candidates), its public address as a STUN server sees it (server-reflexive, or srflx) and, where one is set up, a relay server’s. Any web page can ask for that list with a few lines of JavaScript, without a permission prompt.

A leak happens when that public address is not your VPN’s. If the browser’s STUN request goes out around the tunnel, or over a connection the VPN does not cover, such as IPv6 when the VPN only carries IPv4, the STUN server sees your real address and the page can read it. Your VPN still hides your traffic; WebRTC just tells the page who you are. How browsers should handle these addresses is set out in RFC 8828.

How the Test Works

  1. Your browser opens one WebRTC connection and asks Cloudflare’s public STUN server (stun.cloudflare.com) which public address it sees. The test waits up to six seconds for the answers.
  2. It lists every address WebRTC shared: public ones, local network ones, carrier (CGNAT) ones, and local addresses hidden behind a random .local name.
  3. It compares the public addresses with the one this site sees from your connection, and checks whether that address belongs to a VPN, proxy, Tor, relay or hosting network.

The test only calls something a leak when both are true: WebRTC shows a different public address in the same IP version, and the address this site sees is a VPN, proxy or hosting address. That is the case where WebRTC gives away the address your VPN was meant to hide.

How to Read the Result

  • No WebRTC leak: WebRTC shows the same public address this site sees, and your local address is hidden. Nothing to fix.
  • Leak: WebRTC shows a different public IP: you are on a VPN or proxy, and WebRTC reveals another address, most likely your real one. Fix it with one of the steps below.
  • WebRTC shows a different public IP (without a VPN): both addresses are usually yours, for example a second connection, a mobile network or a router that sends calls another way.
  • Possible leak over the other IP version: this site sees you over IPv4 (or IPv6) and WebRTC also found an address in the other version. If your VPN should hide that one too, it is leaking there.
  • No public IP leak, but your local address is visible: the browser shows your device’s address on your home or office network instead of a random .local name.
  • WebRTC returned no addresses, or is not available: WebRTC is switched off or blocked by a setting, an extension or your VPN app, so no page can read your address through it.
  • Test finished, but we could not read the address this site sees: the page could not get your public address from our server, so it cannot compare. Check the public addresses WebRTC found against the one your VPN app shows.

How to Fix a WebRTC Leak

  • Your VPN app first: look for a WebRTC or leak protection setting, and for IPv6 leak protection. Fixing it in the app covers every browser on the device.
  • Firefox: open about:config, search for media.peerconnection.enabled and set it to false. It switches off WebRTC connections entirely (Mozilla’s WebRTC privacy notes), so calls in the browser stop working until you turn it back on.
  • Chrome and Edge: Chrome has no built-in switch. Install the WebRTC Network Limiter extension, which changes how WebRTC traffic is routed. Edge can install it from the Chrome Web Store once you allow extensions from other stores (Microsoft’s guide).
  • Brave: open brave://settings/privacy and set the WebRTC IP handling policy to “Default public interface only” or “Disable non-proxied UDP”. Neither exposes a local address, and the second keeps WebRTC to your proxy or TCP (Brave’s WebRTC settings).

Then press “Run the test again”. If the result is now “No WebRTC leak”, “WebRTC returned no addresses” or “WebRTC is not available in this browser”, the fix worked. Our guide on checking whether your VPN is working covers the other tests: your IP before and after connecting, DNS leaks and the kill switch.

Frequently Asked Questions

What is a WebRTC leak test?

A check of the addresses your browser’s WebRTC shares with any web page, compared with the address the site sees. If you are on a VPN and WebRTC shows a different public address, your real one is leaking. This page runs the test as it opens and again whenever you press the button.

Does a VPN stop WebRTC leaks?

Many do, but not all, and not always over IPv6. A VPN that routes all traffic through its tunnel also carries the browser’s STUN request, so WebRTC sees the VPN’s address. Apps that leave some traffic outside the tunnel, or carry only IPv4, can leak. The only way to know is to test while connected. To see whether your current address is a known VPN address, use the VPN and proxy detector.

Why does the test show a different IP without a VPN?

Because both addresses are usually yours. A device with two connections (Wi-Fi and mobile data, or IPv4 and IPv6), or a router that sends call traffic another way, can show a second public address. Without a VPN there is nothing to hide, so it is shown as a warning, not a leak.

Should I disable WebRTC?

Only if you need to and do not use calls in the browser. Switching it off stops the leak for certain but breaks video and voice calls and some file-sharing sites in that browser. A VPN app with WebRTC protection, or Brave’s or the extension’s routing setting, fixes the leak and keeps calls working.

Why is my local address shown as a .local name?

Current browsers replace your device’s local network address with a random name ending in .local (mDNS), so pages cannot read it. That is the good result. If the test shows a real local address such as 192.168.1.20 instead, your browser is older or set to expose it.

Is a WebRTC leak the same as a DNS leak?

No. A WebRTC leak reveals your IP address to the page you are on. A DNS leak sends the names of the sites you visit to your internet provider’s DNS servers instead of your VPN’s. A VPN can have either, both or neither, so test them separately; our guide to checking that your VPN works covers both.

What is a STUN server?

A server that tells a device which public address its traffic comes from, so two browsers behind routers can find each other for a call. This test uses Cloudflare’s public STUN server. The address it reports is the one any page with WebRTC can learn.

Does this test send my IP address to you?

The page asks our server for the address it sees from your connection, which every site you visit sees anyway (the same address the IP lookup shows), and whether it is a VPN or proxy address. The addresses WebRTC finds stay in your browser: the only other request the test makes is to Cloudflare’s STUN server.

Related Tools

The VPN and proxy detector tells you whether the address the site sees is recognised as a VPN, and the user agent tool shows the other details your browser shares with every site.