WebRTC Leak Test

A WebRTC leak is your real IP address being exposed through your browser while you are connected to a VPN. WebRTC powers browser-based video and voice calls, and to connect two people directly it asks a STUN server what your real IP address is. That request can travel outside the VPN tunnel, and the answer becomes readable by any website that asks your browser for it. There is no permission prompt and no visible sign that it happened, which is why a leak can run for months unnoticed.

Run the test at the top of this page with your VPN connected. The page scores the same address family as your connection IP. If the WebRTC row shows a different address from your connection IP, that difference is your real IP escaping the tunnel. If the addresses match, or the WebRTC row reads "Not exposed", nothing is leaking. A local address like 192.168.1.24 or an address ending in .local is your private network address and is not a meaningful exposure.

Only if it actively blocks WebRTC, and many VPNs do not. A VPN encrypts the traffic travelling through its tunnel, but WebRTC runs inside your browser and can reach a STUN server on its own unless something stops it. That is why you can see a leak on this page while your VPN says you are protected. With Windscribe the desktop app blocks these leaks automatically, and the browser extension does it through WebRTC Slayer.

It depends on what you are running. The Windscribe desktop app blocks WebRTC leaks automatically as part of how it routes and firewalls your traffic, so there is no toggle to find and nothing to configure. If you use the Windscribe browser extension on its own, without the desktop app, open the extension settings and enable WebRTC Slayer. Running both is fine, and the desktop app remains your protection either way.

It is safe for your device, but it has a cost. Turning WebRTC off entirely in your browser can break the apps that depend on it, including Zoom, Google Meet, Discord, and most browser-based calling and screen-sharing tools. That is the drawback of the manual browser fixes. Blocking the leak at the app level keeps your IP inside the tunnel without switching off the technology those calls need.

They both undermine a VPN, but they expose different things. A WebRTC leak reveals your real IP address, which points to your location and your internet provider. A DNS leak reveals which websites you are visiting, because the lookups for those domains escape the tunnel and reach your ISP instead of a private resolver. Different mechanism, different fix, and a clean result on one says nothing about the other, so it is worth running both tests. Windscribe protects against both.

No. The check runs entirely in your browser. Your browser gathers its own WebRTC candidates locally and compares them against your connection IP on your device. No result is written to a Windscribe server, nothing is logged against your account, and there is nothing for us to hand over later. You can re-run the test as often as you like.

Chrome, Edge, Firefox, and Opera all ship with WebRTC enabled, so they are the most common places a leak shows up. Safari is more restrictive and will not hand out candidates without media permission, which limits exposure out of the box. Brave includes built-in WebRTC handling options. Mobile matters too: the in-app browsers inside social and messaging apps run WebRTC as well, so it is worth testing there rather than assuming your phone is covered.

That is mDNS obfuscation, and it is a good sign. Modern browsers replace your real private network address with a random hostname so websites cannot use it to fingerprint your device or map your home network. It means your browser is doing the right thing. The row is shown here for completeness, but a .local value is not an exposure and needs no action.