b2KIT

WebRTC Leak Tester

Detect WebRTC IP leaks that can expose your real IP address even behind a VPN. Shows local, public, and ICE candidates.

Tested tool guide Tested browser tools Checked August 16, 2026

What WebRTC Leak Tester does and how it behaves

This tool opens a WebRTC peer connection in your browser, points it at a STUN server, and collects every ICE candidate the browser hands back: local host addresses, the server-reflexive address STUN sees as your public IP, and any relay address if a TURN server is in play. People running a VPN often expect a clean report and are surprised to still see their real public IP in a reflexive candidate - that happens when the VPN doesn't force browser traffic through its own tunnel, which is a gap in the VPN client, not something this page can patch.

How the result is produced

1

ICE candidate gathering via STUN

The tool creates an RTCPeerConnection configured with a public STUN server, opens a data channel to force candidate gathering, and calls createOffer/setLocalDescription. Each event fired at onicecandidate carries a candidate string encoding an IP, port, and type (host, srflx, or relay). The tool parses these strings and lists every unique address exposed, independent of what the address bar or VPN client reports.

2

mDNS hiding of local candidates

Current Chrome and Firefox replace the real local-network IP in host candidates with a randomly generated hostname ending in .local, resolvable only via multicast DNS on the same network. The tool cannot reverse this hostname back to a raw IP; it reports whatever the browser hands it. Seeing a plain private-range IP instead of a .local name usually points to an older browser, a changed flag, or a non-browser WebRTC client.

Good uses

  • confirming a VPN client actually routes browser WebRTC traffic through its tunnel before doing something sensitive over that connection
  • checking whether a browser's or extension's 'WebRTC leak protection' setting is working after you turn it on
  • verifying a leak is fixed after changing a browser flag (e.g. disabling WebRTC in Firefox) or switching browsers

Limits and checks

  • no visible local IP does not prove there is no leak - modern browsers mask it behind an mDNS .local hostname by default, this tool can't unmask that
  • results only reflect the browser tab running the test; other browser profiles, apps, or WebRTC-capable extensions can behave differently
  • if the browser or an extension blocks ICE gathering outright, the tool shows no candidates at all, which looks safe but actually means the test didn't run

Common questions

My VPN is on but I still see a public IP in the candidates - is that a leak?

Compare it to the exit IP your VPN reports elsewhere. If the candidate IP matches your VPN's exit IP, the STUN request went through the tunnel and nothing leaked. If it matches your ISP-assigned IP instead, your browser is reaching STUN outside the tunnel and that is a real leak.

Why don't I see my actual local network IP anymore?

Because current Chrome and Firefox versions replace it with a randomized mDNS hostname (something.local) by default as a privacy measure, not because this tool failed to detect it. This applies to the local host candidate only; it doesn't affect whether your public IP leaks via the reflexive candidate.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools