See which IP addresses WebRTC hands to websites, and whether your VPN is being bypassed
Runs in your browser. Nothing you type is sent anywhere. Updated on 24 Oct 2026.WebRTC can tell any website up to 2 kinds of address - your device's local one and your public one, as a STUN server sees it. This test gathers the addresses your browser hands out, locally by default, and shows whether one of them bypasses your VPN.
Open the page: the device-only check runs by itself and lists the addresses WebRTC offers.
Turn your VPN on, then press Check with a public STUN server.
Read the verdict and the line saying which address our server sees; a public address in the table that is not that one means WebRTC goes around the VPN.
Press Copy result to save the verdict and the address list.
WebRTC is the part of a browser that makes video calls and peer-to-peer connections work. To connect two browsers directly it collects "ICE candidates": the addresses at which this device might be reachable. Any web page can ask for them, without a prompt, and that is where the leak comes from.
There are three kinds you will see. A host candidate is an address on one of this device's own network interfaces. Current Chrome, Edge, Firefox and Safari hide a private host address behind a random name ending in .local (an mDNS name), so a page no longer learns your 192.168 address. A server-reflexive (srflx) candidate is your public address as a STUN server on the internet reports it. A relay candidate is the address of a TURN server that forwards traffic.
For a VPN user the risk is the srflx candidate. If the browser sends its STUN request outside the VPN tunnel, the address that comes back is your real connection, and a site that runs this check learns where you are despite the VPN.
By default this test uses no STUN server, so nothing leaves your device and only host candidates can appear. Press "Check with a public STUN server" to repeat it with Google's STUN server at stun.l.google.com, port 19302. That sends one small request to Google, which sees your address as any website does, and it shows the public address WebRTC would reveal. The page can also ask our own server which address it sees and compare the two: if they differ while you are on a VPN, WebRTC is leaking.
To stop a leak, turn on your VPN's WebRTC protection, use Firefox's media.peerconnection.enabled setting, or install an extension that limits WebRTC to the proxied route. Then run the test again.
A WebRTC leak happens when a web page learns an address your VPN was supposed to hide. The browser asks a STUN server for its public address so peer-to-peer calls can connect, and if that request travels outside the VPN tunnel, the reply is your real address. Any page can ask for it without a permission prompt.
Not by default. The first run uses no STUN server, so candidates are gathered on your device only. The optional public STUN check sends one request to Google's stun.l.google.com, and the comparison asks our own server which address it sees. Both are off until you press the button.
Browsers now replace your private network address with a random name ending in .local, known as an mDNS candidate. The page sees the random name, never the real 192.168 or 10.x address, and the name changes between sessions. Seeing only .local host candidates means your local address is protected.
Without a VPN, the public address WebRTC reveals is the same one every website already sees from your connection, so nothing extra leaks. The test matters when a VPN or proxy is on: then WebRTC should show the VPN's address, or no public address at all.
Turn on the WebRTC or leak protection setting in your VPN app first. In Firefox, setting media.peerconnection.enabled to false in about:config disables WebRTC entirely. Chrome and Edge need an extension that restricts WebRTC to the proxied route. Run this test again afterwards to confirm the change worked.
The three are ICE candidate types from RFC 8445. Host is an address on this device's own network card. Srflx, server-reflexive, is your public address as a STUN server reports it. Relay is the address of a TURN server that forwards the traffic. Only srflx and raw host addresses can leak anything.
Still stuck? Ask about WebRTC Leak Test and anybody who knows can answer. No account needed.
On the related tools: JWT Decoder – Paste a token to read its header, payload and expiry · Passphrase Generator – Three to ten random words you can actually remember · Bcrypt Generator – Generate a bcrypt hash for a test user or a config file.