WebRTC leak test

A WebRTC leak is when your browser hands a website your real IP address through the feature it uses for voice and video calls, even though your ordinary page traffic is going somewhere else. This test opens a WebRTC connection the same way a video call site would, collects every address your browser offers up, and compares them with the address our server actually sees. If a public address turns up here that you did not expect anyone to see, that is a leak.

Updated 11 August 2026

What this test checks

The test has two halves. First, our server notes the address your browser used to load this page. That is the address every site you visit can see anyway, with no tricks involved. Second, a small piece of code on the page asks your browser to get a WebRTC connection ready and list the addresses it would use for it. The two results are then put side by side.

• If WebRTC hands over nothing, or only a masked local name, there is nothing extra here for a site to pick up.
• If WebRTC hands over a public address that differs from the one our server sees, part of your traffic is taking a different route out.

Everything is worked out on our own servers. Visitor addresses are not stored, there are no third-party scripts on this page and no ads, so the result goes to your screen and nowhere else.

What WebRTC is, and why it knows your address

WebRTC is built into Chrome, Firefox, Safari, Edge and every other current browser. It lets two people connect directly for a voice call, a video call, screen sharing or a file transfer, without the data passing through a server in the middle. Browser meeting rooms, chat widgets with a call button and in-page voice chat all depend on it.

To connect two people directly, the browser first has to answer a simple question: where am I on the network? So it puts together a short list of possible addresses, which usually includes:

• the address your router gave your device inside your home or office network, something like 192.168.1.14 or 10.0.0.7;
• your public address – the one your internet provider gave you, which the browser finds by asking a helper server outside your network.

The catch is that any web page can start this process with a few lines of code and read that list. There is no permission prompt, no camera, no microphone, nothing for you to click. That is the only reason a test like this one is possible.

Why your real address can show even with a VPN on

Not every privacy tool covers every kind of traffic. Tools that work inside the browser alone change where your ordinary page requests go – the pages, the images, the scripts – because those all travel the same way. WebRTC does not. It talks to the network directly, and unless the tool specifically tells the browser to keep WebRTC in the same tunnel, that part can slip out through your provider instead.

VPN software that covers the whole computer normally handles it, but the old address can still turn up:

• a setting that lets certain apps skip the tunnel, so they keep using the ordinary connection;
• two live connections at once, such as Wi-Fi and a cable, where only one of them is covered;
• an IPv6 address the tunnel does not handle at all, while everything else goes through it fine.

That is why this test is worth running again after you change anything about your connection, not just once.

How to read your result

Three outcomes are normal, and only one of them needs anything from you.

• Nothing found. Your browser gave up no usable addresses through WebRTC. A site learns nothing from it beyond the address it already sees.
• Local address only. You see something like 192.168.x.x, 10.x.x.x, an address between 172.16.x.x and 172.31.x.x, or a random name ending in .local. That is simply how your own router numbers the devices in your home. It says nothing about who you are or where you live, and it is no use to anyone outside your network. Chrome and Edge replace it with the random .local name on purpose.
• Public address exposed. WebRTC returned a public address that differs from the one shown at the top of the page. This is the real leak: any site you open can read that address in a few lines of code and recognize you on your next visit.

How to turn WebRTC off

One honest warning first: WebRTC is what makes calls in the browser work. Turn it off and video meetings, voice chat and screen sharing inside the browser stop working until you turn it back on.

Firefox is the only major browser with a real switch:

1. Type about:config in the address bar and press Enter.
2. Accept the warning about advanced settings.
3. Search for media.peerconnection.enabled.
4. Switch it to false with the button on the right.
5. Come back here and run the test again.

Chrome has no on/off switch in its settings, and the hidden setting that used to exist was removed years ago. Two things still work: install an extension that sets Chrome's handling of WebRTC addresses to the strictest option, or, on a work computer, ask whoever manages it to apply the WebRtcIPHandling policy. Chrome already hides your local address by default, so a .local name in the result is normal, not a failure.

Edge is built on the same engine as Chrome, so the answer is the same: an extension or a managed policy, nothing in the settings menu.

Safari is stricter from the start. It does not hand the full list of addresses to a page that has no permission to use your camera or microphone, so an ordinary site usually cannot read your public address this way. On a Mac you can turn on the developer features in Safari settings, under Advanced, which adds a Develop menu with WebRTC options. The more useful habit, though, is to give camera and microphone access only to the sites you actually call from.

On phones and tablets there is no setting like this at all. If WebRTC leaks there, the fix has to happen at the connection level rather than in the browser.

What to do if the test finds a leak

1. Run the test once more. A single odd result can come from a connection that was still settling.
2. Open this page in a private window with extensions turned off. If the leak disappears, one of your extensions is causing it.
3. Check what your privacy tool actually covers. If it only redirects page requests inside the browser, WebRTC was never part of the deal.
4. Turn WebRTC off if you never make calls in that browser. In Firefox it takes half a minute; in Chrome and Edge you will need an extension.
5. If you are on Wi-Fi and a cable at the same time, disconnect one of them and test again.

If the result simply shows that the address from your provider is visible to every site you open, and you would rather it were not, a VPN extension for the browser is one simple way to change what those sites see. Ours is called AnonVPN, a Chrome extension we make. It will not make you anonymous – nothing will – but it does keep the address your provider gave you off the pages you visit.

Checking from a script

If you want the same information without opening a browser, api.ipgeo.ru returns it in a form a script can read: address, country, provider and network. There are no keys and no sign-up. It is handy for keeping an eye on a server, checking a router after a reboot, or confirming that a connection came up on the address you expected.

This page carries no advertising and no outside analytics, so nothing you check here follows you around afterwards.