WebRTC Leak Test
See exactly which network addresses your browser would hand to a peer through WebRTC, and whether any of them travel outside your proxy. Free, no signup, results stay on this page.
- Runs in your browser
- Contacts a public STUN server
- No signup
See which addresses WebRTC would hand over
The check opens a peer connection exactly as a video call would, collects the ICE candidates your browser produces, and sorts them into masked .local names, private LAN addresses and routable public ones.
Runs entirely in this browser. Nothing is uploaded, nothing is stored, no signup.
Now give every account its own device.
A clean browser is still one browser. Sendwin runs each profile in isolation with its own fingerprint, cookies and proxy, so the accounts you work on never look like they came from the same machine.
- Isolated profiles, each with its own fingerprint and cookies
- A proxy per profile, with the timezone bound to the proxy country
- Windows, macOS and Linux — plus cloud sessions when you need them
The free plan includes 10 minutes of cloud browsing a day.
How WebRTC ends up holding your address
WebRTC is the browser API behind video calls, voice chat and peer-to-peer file transfer. To connect two people directly it first has to work out how they can reach each other, so it asks the operating system for the network interfaces on this machine and asks a STUN server what address the connection appears to come from. Those answers are called ICE candidates, and any page can collect them with a few lines of JavaScript — no permission prompt, no camera, no microphone.
That matters because ICE candidates come from the network stack, not from the HTTP request. A proxy applied at the browser or extension level can carry your page traffic while WebRTC keeps describing the connection underneath it. This test opens a peer connection, gathers the candidates your browser produces, and sorts them into masked .local names, private LAN addresses and routable public addresses, so you can see which of those you are actually handing over.
Why a proxy does not automatically cover WebRTC
Your browser sends page requests through whatever proxy it is configured to use. WebRTC takes a separate path: it enumerates local network interfaces and queries a STUN server so a peer can find the shortest route to you. If that query is not forced through the same tunnel, the address it returns is the one your machine really exits from. This is how a single page load can record a proxy exit address in the server logs and a completely different address in an ICE candidate — and collecting both takes a site about ten lines of code.
mDNS names, private addresses and routable addresses
Not every address in the list is a finding. Modern browsers replace LAN addresses with a randomized name ending in .local, generated per origin, which lets a real peer connect while telling the page nothing — seeing those is the healthy result. Private RFC1918 addresses such as 192.168.x.x or 10.x.x.x describe your local network but are not reachable from the internet. Only a routable public address places your traffic. A dual-stack connection legitimately offers one routable IPv4 and one routable IPv6; two routable addresses in the same family is the pattern that means traffic can leave by more than one path.
What to do when a routable address is not your proxy's
Start by confirming which address your proxy actually exits from, then compare it with what this page lists. If the routable candidate matches, nothing is leaking. If it does not — or if an IPv6 address appears while your proxy only carries IPv4 — the fix belongs at the connection level rather than in the page. Route the whole browser through the proxy instead of a single tab, drop IPv6 on that connection if the proxy cannot carry it, or use a browser that binds WebRTC to the same proxy as the profile. Switching WebRTC off works too, at the cost of every call in that browser.
How the leak test runs
- 1
Gather the candidates
The page opens a WebRTC peer connection with a data channel and collects the ICE candidates your browser offers, exactly as a call would. It finishes in about four seconds.
- 2
Read the address list
Every candidate is classified as a masked .local name, a private LAN address or a routable public one. The routable rows are the only addresses a site can use to place you.
- 3
Compare against your proxy
Check each routable address against the exit address your proxy is supposed to have. Anything that does not match is a second path out of your machine.
Other free checks
A leaking address is one way a proxy setup fails. These cover the list it came from, the clock beside it and the rest of the fingerprint.
WebRTC leak FAQ
What a leak actually is, when a VPN covers it, and why a .local address is the result you want.
A WebRTC leak is when the browser hands out a network address that your proxy or VPN was supposed to hide. It happens because WebRTC discovers routes through the operating system's network stack rather than through the browser's HTTP proxy settings, so a page can read an address that never appears in your request headers. No permission prompt is involved, and no camera or microphone is touched.
A system-wide VPN usually does, because every socket on the machine leaves through the tunnel, including the STUN query. A browser extension or a proxy set only inside the browser often does not: page traffic goes through it while WebRTC keeps describing the connection underneath. The other common gap is IPv6 — if the tunnel carries only IPv4 and your connection is dual-stack, the IPv6 candidate is still your real address. Running the test is faster than reasoning about which case you are in.
You can, and it removes this exposure completely, but it also breaks every video call, voice chat and screen share in that browser. There is a smaller cost as well: sites can see that RTCPeerConnection is missing, and a browser with no WebRTC at all is unusual. If you only need the address hidden, routing WebRTC through the same proxy as the rest of the profile keeps the API working and gives nothing away.
That is mDNS masking, and it is the good outcome. Rather than publishing your LAN address, Chromium and Firefox generate a random hostname ending in .local for each origin, which lets a peer on your own network connect while telling the page nothing about it. The name differs per site and per session, so it cannot be used as an identifier.
Not by itself. ICE gathers candidates per address family, so a dual-stack connection normally offers one routable address of each. What matters is whether both belong to your proxy's exit. Two routable addresses within the same family is the real finding — a connection has one exit per family, so at least one of those is a path around the proxy.
The check runs in your browser and the results are not uploaded. It does talk to a public STUN server, because that is the only way to learn the address a peer would see, and it is the same server your browser already contacts during an ordinary call. Nothing is stored on our side, and reloading the page clears the result.
Each profile gets its own proxy, and WebRTC, timezone and locale follow that proxy rather than the machine underneath. The addresses a peer connection offers describe the profile's exit instead of your own connection. You can confirm it the same way you just checked this browser: open this page inside the profile and read the routable rows.
Still have questions? Talk to us →
How to read the address list
This test reads the candidates your browser produces right now, on this connection. It cannot tell you which address your proxy is supposed to be using — only you know that — and a firewall that blocks STUN can make a leaking setup look clean here. Treat the address list as the raw material for that comparison rather than as a pass or fail.
Bind WebRTC to the profile's proxy.
Every Sendwin profile carries its own proxy, and WebRTC, timezone and locale follow that proxy rather than the machine underneath. Free for 30 days on Windows, macOS and Linux.
30-day free trial · $0 today · cancel anytime — your profiles stay on your machine