WebRTC Leak Test
See every address WebRTC hands to websites — and whether one slips past your VPN.
Run the WebRTC leak test
Untick it for a baseline run without the VPN. The test contacts MySmartCoPilot’s server and Google’s public STUN server only when you press the button. No camera or microphone is used.
Testing…
Result
What websites see
What WebRTC reveals
ICE candidates
Every address the browser offered for a connection — what any page could read with a few lines of script.
| Type | Protocol | Address | Port | What it is |
|---|
What video-call sites see
Browsers show more to pages you allow to use your camera or microphone: the real local addresses and, in Chrome, Edge and Firefox, every network interface — RFC 8828 lets them treat that permission as your consent. A VPN that leaks only then leaks to every video-call site you use.
Your browser asks for microphone access (or the camera, if there is no microphone). It stays open only for the few seconds the addresses take to gather, then it is stopped; nothing is recorded or sent.
How to stop WebRTC leaks
Networks from the IPtoASN routing snapshot (public domain) that ships with the site. STUN server: stun.l.google.com.
About the WebRTC Leak Test
WebRTC is the part of your browser that makes video calls and file transfers work without plug-ins. To find a direct path to the other side, it collects ICE candidates — the addresses you can be reached at: this device’s own network addresses, and the public address a STUN server sees when the browser asks it. Any web page can start that process with a few lines of script, without asking you, and read every candidate. A WebRTC leak is a candidate that shows an address your VPN is meant to hide: your internet provider’s public IP, an IPv6 address outside the tunnel, or your local network address.
This test gathers the candidates against Google’s public STUN server, shows each one in plain words, and compares the public addresses with the address MySmartCoPilot’s server sees for your connection — the one websites see — network by network. It tells you which address policy your browser follows (the modes of RFC 8828), and its deeper test shows what pages see once you give them microphone or camera access, as video-call sites have — browsers show those pages more. Each result comes with the setting that fixes it in your browser.
How to use it
- Connect your VPN the way you normally use it. Leave I’m using a VPN or proxy right now ticked (untick it for a baseline run without the VPN).
- Press Run the WebRTC leak test. It takes a few seconds.
- Read the verdict, then compare What websites see with What WebRTC reveals: every public address should be the same one, or at least the same network.
- Open ICE candidates to see each address the browser offered and what it means.
- Optional: press Test with microphone permission and allow access when your browser asks — the test shows what video-call sites see. The microphone stays open only for the few seconds the addresses take to gather, then it is stopped; nothing is recorded or sent.
- Follow the steps for your browser under How to stop WebRTC leaks, then run the test again. Copy report or the downloads give you a record for your VPN provider’s support.
Examples
No WebRTC leak Websites see 198.51.100.24 (AS9009 M247) WebRTC reveals 198.51.100.24 via stun.l.google.com · local address hidden (….local)
The STUN server sees the VPN’s address, and the browser hides the local address behind a random name. Documentation addresses (RFC 5737) stand in for real ones.
WebRTC leak: your real IP address is exposed WebRTC reveals 203.0.113.9 (AS7922 COMCAST-7922), outside the network websites see (198.51.100.24, AS9009 M247)
Web pages go through the VPN, but the STUN requests (UDP) leave through the home connection. The VPN app’s leak protection or kill switch is the fix.
No WebRTC leak · With microphone permission: also 192.168.1.20 and 10.8.0.2 (local addresses)
Without permission the browser hides local addresses; with it, it shows every interface — here the home network and the VPN adapter.
Common uses
- Checking a VPN, a new VPN server or a VPN app update for WebRTC leaks before you rely on it.
- Finding out why a site still sees your home network although the VPN is on.
- Seeing what a video-call or meeting site can learn about your networks once you allow your microphone.
- Checking that a browser setting or extension that limits WebRTC really works.
What the candidates mean
- host: an address of this device’s own network interface. Shown as a random name ending in .local (multicast DNS), it is hidden; shown as
192.168.…,10.…or an IPv6 address, it is visible to the page. - srflx (server-reflexive): the public address a STUN server saw when the browser asked it (RFC 8489) — the address your connection uses on the internet. With a VPN it should be the VPN’s.
- prflx (peer-reflexive) and relay: addresses learned from a peer or a TURN relay during a real call; this test has no peer and no relay, so they rarely appear.
- UDP and TCP: the protocol. STUN answers come over UDP; TCP host candidates only show local addresses (RFC 8445).
The address modes of RFC 8828
RFC 8828 defines what WebRTC may expose. Mode 1 uses every network interface — allowed only with the user’s consent, which browsers tie to camera or microphone permission. Mode 2, the default without consent, follows the route your web traffic takes and shows that interface’s local address; Mode 3 shows no local address; Mode 4 sends WebRTC only through a proxy. Current Chrome, Edge, Firefox and Safari work in mode 2 for pages without permission and hide the local address behind a random .local name; the test names the mode your candidates fit, as a heuristic.
Why camera or microphone permission changes the result
Once a page may use your camera or microphone, browsers treat that as the consent RFC 8828 asks for: Chromium enumerates every network interface and stops hiding local addresses, Firefox drops its default-route-only rule and its address obfuscation, and Safari turns off its candidate filtering for that page. That is what makes calls work well — and it means a VPN that lets one interface reach the internet directly can leak to every video-call site you use, even when the normal test is clean. The deeper test shows exactly that; it needs your permission once and keeps the microphone open only while it gathers the addresses.
How it differs from the VPN Leak Test
The VPN Leak Test checks your whole connection: IPv4 and IPv6 exits, Tor, time zone and language, with WebRTC as one row. This page is about WebRTC alone: every candidate explained, the address policy, and what pages with camera or microphone permission see.
Limitations
- It tests this browser only; other apps on the device can bypass the VPN in their own ways.
- Networks are compared by their AS (the network that routes an address) from a routing snapshot; whether a network is a data centre or an internet provider is a heuristic, and some VPNs use home-broadband addresses.
- If a firewall, an extension or the VPN blocks UDP to the STUN server, WebRTC learns no public address from it — but the test then cannot show what a STUN server would see.
- DNS leaks are not part of WebRTC and are not tested here.
- MySmartCoPilot’s server answers a limited number of these tests per hour for each visitor.
Privacy
The test runs only when you press the button, and its results stay in your browser. Google’s STUN server (stun.l.google.com) sees your IP address, as with any video call. MySmartCoPilot’s server reads the address your request comes from and its country and network, sends them back to you only, and stores nothing. Network names are looked up in data files downloaded from MySmartCoPilot. The deeper test opens your microphone (or camera) only while it gathers the addresses — a few seconds — then stops it; it records and sends nothing.
Frequently asked questions
What is a WebRTC leak?
An address that WebRTC hands to web pages but your VPN is meant to hide — usually your internet provider’s public IP, found when the browser’s STUN request (UDP) leaves outside the tunnel, or an IPv6 address the VPN does not carry. Pages can read it silently.
Is it a problem if only my local IP address shows?
It does not reveal where you are, since addresses like 192.168.1.20 are used by millions of networks, but it helps sites recognise your device and learn about your network. Current browsers hide it unless a page has camera or microphone permission.
Should I switch WebRTC off?
Only if you never make calls in the browser. Video calls, screen sharing and some file transfers need WebRTC. Limiting it to the route your browsing takes (Firefox media.peerconnection.ice.default_address_only, Brave’s “Default public interface only”) and using a VPN with leak protection keeps calls working.
Why does the deeper test ask for my microphone?
Because browsers show more addresses to pages that have camera or microphone permission. The test needs that permission once to show what such pages see; the microphone stays open only for the few seconds of the test, and nothing is recorded. You can remove the permission in the site settings afterwards.
Does a WebRTC leak mean my VPN is broken?
It means the VPN does not catch all of this browser’s UDP traffic, or it lets some interface reach the internet directly. Turn on its leak protection or kill switch if it has one, and check its split-tunnelling settings.
Which STUN server does the test use?
Google’s public STUN server, stun.l.google.com — the one the WebRTC project’s own samples use. If your network blocks it, the test says that no STUN server answered and cannot show what a STUN server would see; sites that use another STUN server your network allows could still learn your public address.