WebRTC Leak Test

WebRTC can hand a website addresses your browser would not otherwise send — including the one behind your VPN. This WebRTC test asks three STUN servers run by Cloudflare and Google, shows every address that came back and what each one is, and compares them with the address a website already sees. When it cannot test something, it says so instead of showing you a green tick.

Run in your browser against Cloudflare and Google STUN · nothing is stored · candidate types from RFC 8445

What a website sees anywayIPv4IPv6Finding your connection…

Every address WebRTC produced

Every address WebRTC produces appears here, one row each, as the STUN servers answer.

No address WebRTC finds is sent to us. Your browser asks the STUN servers itself, the way any video call does. To show what a website sees, the page asks ipify.org and our own server for your addresses and their networks, as the DNS Leak Test does.

What is a WebRTC leak?

WebRTC is the browser feature behind video calls. To connect two people directly it collects every address your machine can be reached on and offers them to the page — including addresses your browser would never send in an ordinary request.

The collection is called ICE candidate gathering, specified in RFC 8445. Your browser lists the addresses on your own network interfaces, then asks a STUN server "what address do you see me coming from?" and adds that too. Any page on the internet can start this with a few lines of JavaScript and read every candidate as it arrives, with no permission prompt — that is the design, because a call has to work without one.

It becomes a leak when one of those addresses is something you were hiding. A VPN changes the route your browser's requests take, but WebRTC can ask the operating system about every interface, so on a machine where the physical connection is still up, the real address can appear alongside the VPN's. Nothing has gone wrong: the feature is doing exactly what it was designed to do.

What any page can startone gathering, step by step

The whole script

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

What it printed

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

What each line is

hostOn this machine8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localMasked by your browser
srflxSeen by a STUN server203.0.113.7Routable on the internet

One gathering on a home connection, with documentation addresses. The private address never leaves the browser as itself; the STUN server sees the router's public side, not the machine, and both answers go to whatever script asked.

WebRTC leak test result showing every ICE candidate with its type, what each address is, and the verdict — A test run: what each STUN server answered, every address WebRTC exposed, what kind of address it is, and whether it is one the website already sees. Select a number to see what each part shows.

How to check for a WebRTC leak

Start the test above. It gathers candidates from three STUN servers, works out what each address is, and compares the routable ones with the address a website already sees.

Three results are possible, not two. No leak means every routable address WebRTC produced is one the site already has. Leak means at least one is not — or that an address on your own machine was offered directly. Could not test means WebRTC is switched off, blocked, or no STUN server answered, and it is the result most tools quietly turn into a pass.

Run it twice if you use a VPN: once with it off to see your ordinary addresses, once with it on. The second run is the one that matters, and the difference between them is the answer. The page keeps the first result so you can compare without writing anything down.

Three results, not twowhat each one means

No leak
Every routable address WebRTC produced is one a website already has.
WebRTC gave
- 198.51.100.23Seen by a STUN serverAlready seen by websites
- 8b7f4e2a-….localOn this machineMasked by your browser
A website sees
198.51.100.23
Leak
At least one address is not one the site already has, or an address on your own machine was offered directly.
WebRTC gave
- 198.51.100.23Seen by a STUN serverAlready seen by websites
- 2001:db8:4a1f:7c00::1cOn this machineNot seen by websites
A website sees
198.51.100.23
Could not test
WebRTC is off or blocked, or no STUN server answered. Nothing was measured.
stun.cloudflare.comNo answer
stun.l.google.comNo answer
What most tools show here~~No leak~~

Run it twice

VPN off

WebRTC gave203.0.113.7

A website sees203.0.113.7

No leak

VPN on

WebRTC gave198.51.100.23203.0.113.7

A website sees198.51.100.23

Still there with the VPN on

Leak

Each result with a run that produces it. With the VPN off, WebRTC's address and the website's are the same; with it on they should both change, and one that stays is the answer.

Does a VPN stop a WebRTC leak?

Not by itself. A VPN changes where your traffic goes; WebRTC can ask your operating system what interfaces exist, and the physical one is usually still there.

The IETF's own description is exact: "if the client tries to hide its physical location through a Virtual Private Network (VPN), and the VPN and local OS support routing over multiple interfaces, WebRTC can discover not only the public address for the VPN, but also the ISP public address over which the VPN is running". Both addresses are offered, and a page that is looking can read both.

Some VPN clients close the gap by routing all traffic at the operating-system level, or by shipping a browser extension that restricts WebRTC. Both work, and both are things to check rather than assume — which is what this page is for. A VPN whose own leak-test page says you are protected is not independent evidence.

A VPN on, the Wi-Fi still uptwo interfaces, two answers

What the page receives

198.51.100.23srflxSeen by a STUN serverthrough the VPNAlready seen by websites
203.0.113.7srflxSeen by a STUN serverthrough the Wi-Fi, outside the tunnelNot seen by websites

RFC 8828

What closes the gap

Routing at the operating-system levelNothing leaves outside the tunnel, so a STUN server can only see the VPN's address.
The VPN's browser extensionIt restricts WebRTC inside the browser, so the other interface is never asked.
Then check, don't assumeRun this test with the VPN on. A VPN's own leak-test page is not independent evidence.

The case the IETF describes in RFC 8828: the VPN and the operating system route over more than one interface, so WebRTC finds the VPN's public address and the provider's address under it.

Host, server-reflexive and relay: which candidate is which?

A host candidate is an address on your own machine. A server-reflexive one is what a STUN server saw — the public side of your NAT. A relay candidate is a TURN server's address, not yours.

The distinction matters, and most leak tests throw it away. A server-reflexive candidate carrying your public IPv4 is usually not news: it is the same address the website gets from the connection you are already making. A host candidate carrying a routable address is a different thing — that is an address on the machine itself, offered directly to the page. It identifies this machine, not just your household's router, and it changes when the network changes.

The page shows the type beside every address, along with the transport, the port and the related address a reflexive candidate names. A relay candidate is the TURN server's own address and reveals nothing about you; this test uses no TURN server, so one appearing would mean something else on the page configured it.

One candidate, field by fieldas a page receives it

candidate:1467250027Foundation
1Component
udpTransport
1686052607Priority
203.0.113.7Address
54400Port
typ srflxType
raddr 0.0.0.0 rport 9Related address
generation 0Extension

Blanked to 0.0.0.0, port 9, where local addresses are masked

The four types

typ hostOn this machine
An address on one of your own network interfaces.
A private one is masked. A routable one is the device itself: the most serious finding.
Most serious when routable
typ srflxSeen by a STUN server
Your router's public side, as a STUN server saw it.
Usually the address a website already has from your connection.
Usually not news
typ prflxSeen by the other side
Your router's public side, as the other end of a call saw it.
Found only while connecting to the other side, so a test without a call never sees one.
Only during a call
typ relayA relay server's own address
A TURN server's address, relaying traffic for you.
The server's address, not yours. This test uses no TURN server, so one here was configured by something else.
Nothing about you

The candidate's address is compared with what a website sees; its type says how serious a difference is. Definitions from RFC 8445, section 4.

What is an mDNS .local address, and does it protect me?

Modern browsers replace your private addresses with a random name ending in .local before offering them to a page. It works — for private addresses. It was never meant to hide a public one.

Chrome has done this by default since version 76 and Firefox has media.peerconnection.ice.obfuscate_host_addresses set to true: instead of 192.168.1.20 a page gets something like 8b7f4e2a-….local, which means nothing to anyone outside your network. Safari goes further: until a site has camera or microphone permission, it offers no host candidates at all. The test above recognises those and reports them as the protection working, not as a finding.

The IETF draft that defines it is explicit about what it does not do: "an address that is already exposed to the Internet does not need to be protected by mDNS, as it can be trivially observed by the web server". So a server-reflexive candidate still carries your public IPv4, and — the part that surprises people — a machine with a routable IPv6 address can still offer that address as a host candidate. There is one more hole worth knowing: Chrome turns the protection off for any site that already has camera or microphone permission, so a video-call site you have used before sees your real local addresses.

What the .local name replacesand what it leaves alone

What your browser has

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

What the page gets

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

What each browser does by default

ChromeVersion 76, August 2019
Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
SafariNo host candidates until a site has camera or microphone permission

The mechanism is an IETF draft, last revised in December 2021 and never published as an RFC. draft-ietf-mmusic-mdns-ice-candidates-03

An address WebRTC could offerMasked?

192.168.1.20Your private IPv4, as a host candidateMaskedReplaced with a random name: the page learns nothing about your network.

203.0.113.7Your public IPv4, as the STUN server's candidateShownAlready public, so it stays. Only the related address is blanked.

2001:db8:4a1f:7c00::1cA routable IPv6, as a host candidateShownPublic too, so the masking was never meant to cover it.

2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07A temporary IPv6 addressMay be shownThe draft lets a browser leave it unmasked, by choice.

192.168.1.20Any local address, on a site with camera or microphone permissionMasking offChrome turns the masking off there: the site sees your real local addresses.

The masking hides what only your own network knows. What a website could see anyway, it leaves as it is: by design, not by mistake.

Why IPv6 is the leak that is left

A global IPv6 address belongs to one machine rather than to a household behind NAT, and mDNS deliberately leaves it alone. It is the most identifying thing WebRTC still hands out.

With IPv4 your home router's NAT puts everything behind one address, so a server-reflexive candidate tells a page roughly what your ordinary connection already tells it. IPv6 has no NAT: each device has its own routable address, and a host candidate carrying it names the device, not the line. If your VPN carries only IPv4 — many do — that IPv6 address is also outside the tunnel entirely.

Privacy extensions help, because a temporary IPv6 address rotates. They don't hide it, though: the mDNS draft says such addresses may be left unobfuscated. The test above marks a routable IPv6 host candidate as the most serious thing it can find, and the IPv6 test will tell you whether your connection has IPv6 at all.

Who an address namesthe same three devices, twice

IPv4, behind NATIPv6, no NAT

Laptop192.168.1.202001:db8:4a1f:7c00::1c

Phone192.168.1.212001:db8:4a1f:7c00::2b

TV192.168.1.222001:db8:4a1f:7c00::3d

Router203.0.113.7One address for the whole lineOne address per device

A global IPv6 address, in two halves

2001:db8:4a1f:7c00Network prefix: your line /64:8d3:5e2f:a41c:9b07Interface identifier: this device

Stable2001:db8:4a1f:7c00::1c
Temporary: rotates2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

A VPN that carries only IPv4

IPv4198.51.100.23Inside the tunnel
IPv62001:db8:4a1f:7c00::1cOutside the tunnel

Behind IPv4 NAT a household shares one address; on IPv6 every device has its own, and a host candidate offers it directly. The test treats a routable IPv6 host candidate as the most serious finding.

How to stop a WebRTC leak in each browser

Firefox has preferences that work. Edge has an enterprise policy. Safari already restricts candidates. The browser extensions people still recommend no longer do anything.

In Firefox, about:config → media.peerconnection.ice.default_address_only sends only one address instead of all of them, and media.peerconnection.ice.relay_only restricts gathering to relay candidates, which breaks direct calls but hides everything else. Both are off by default; the mDNS masking of private addresses (media.peerconnection.ice.obfuscate_host_addresses) is already on. In Edge, the WebRtcLocalIpsAllowedUrls policy controls which sites may see local addresses; Microsoft's own documentation notes that adding a site "weakens the protection". Chrome has no equivalent setting for an ordinary user. Safari is the strictest without asking: without camera or microphone permission, WebKit offers only server-reflexive and relay candidates and no host candidates at all.

Two things still widely recommended are dead. uBlock Origin's "Prevent WebRTC from leaking local IP addresses" option was removed in version 1.38, with the note that it is "no longer necessary in modern browsers, except for Firefox for Android". And Google's WebRTC Network Limiter extension, still listed in the store, cannot run: Manifest V2 extensions have been disabled for every Chrome user since Chrome 138 in July 2025. If a page tells you to install either, that page has not been updated in years.

What each browser offerschecked against each vendor's documentation

FirefoxPreferences that work
about:config
- media.peerconnection.ice.obfuscate_host_addressesDefault trueMasks private addresses. Already on.
- media.peerconnection.ice.default_address_onlyDefault falseSet it to trueSends one address instead of all of them.
- media.peerconnection.ice.relay_onlyDefault falseSet it to trueRelay candidates only. Hides the most, and breaks direct calls.
EdgeEnterprise policy
WebRtcLocalIpsAllowedUrls
Lists the sites that may see local addresses.
Not configured: local addresses stay masked.
Microsoft's own note: adding a site weakens the protection.
Windows and macOS, version 80 and later
ChromeNo setting
No setting for an ordinary user.
Private addresses masked by default since version 76.
Not on a site with camera or microphone permission.
SafariStrict by default
Without camera or microphone permission, only STUN-server and relay candidates.
No host candidates at all.

Advice that no longer works

~~Prevent WebRTC from leaking local IP addresses~~
uBlock Origin
Removed in version 1.38
No longer necessary in modern browsers, uBlock Origin said, except Firefox for Android.
~~WebRTC Network Limiter~~
Google · Chrome Web Store
Still listed, cannot run
Manifest V2 extensions have been disabled for every Chrome user since Chrome 138, July 2025.

Each vendor's own documentation, read on the day this page was checked. A page that still tells you to install either of the last two has not been updated in years.

WebRTC leak, DNS leak and IP leak: what is the difference?

They are three different ways a VPN can be bypassed. A WebRTC leak shows an address; a DNS leak shows who answers your lookups; an IP leak is the plain case where your traffic never entered the tunnel.

A WebRTC leak is about addresses your browser volunteers through a feature designed to volunteer them. A DNS leak is about which resolver answers your lookups: your traffic can go through the VPN while your lookups still go to your provider's resolver, which tells that provider every site you visit. Our DNS leak test checks that with our own nameserver, so it can see exactly which resolvers asked.

An IP leak in the general sense is the address a website simply sees, which you can check on what is my IP or what is my ISP. Run the three together after any VPN change: they fail independently, and a clean result on one says nothing about the others. The VPN test does that in one run: the address websites see in both IPv4 and IPv6, WebRTC, and DNS on its own button, ending in one verdict.

Three ways around a VPNeach one fails on its own

IP leak
What leaksThe address every request carries
Who learns itEvery site you visit
Check it withWhat Is My IP What Is My ISP
DNS leak
What leaksWhich resolver answers your lookups
Who learns itYour provider, for every site you look up
Check it withDNS Leak Test
WebRTC leak
What leaksAddresses your browser offers a page
Who learns itAny page that asks, with no prompt
Check it withWebRTC Leak Test

They fail independently: a clean result on one says nothing about the other two. Run all three after any change to your VPN.

Why this test asks more than one STUN server

Because "no address came back" and "no address exists" look identical, and only one of them is good news.

A corporate firewall, a restrictive VPN or a network that blocks UDP can stop a STUN server answering. A test that asks one vendor and sees nothing has learned nothing — yet the usual response is to show a green tick. This one asks Cloudflare's documented STUN endpoint and Google's, reports each separately, and says it could not test when none of them answered.

The choice of servers is deliberate. Cloudflare publishes stun.cloudflare.com:3478 as part of a product, so there are terms to read. Google's stun.l.google.com:19302 is documented only as the default of Google's own WebRTC validator, with no published terms, so it is used as a second opinion rather than the sole source. Twilio's needs credentials, and Mozilla documents no public STUN server, despite how often one is quoted.

Public STUN serversand which ones this test asks

CloudflareAsked
stun.cloudflare.com:3478
A documented endpoint, part of a product, with terms to read.
GoogleAsked, as a second opinion
stun.l.google.com:19302
Documented only as the default of Google's own WebRTC validator. No published terms.
TwilioNot asked
global.stun.twilio.com:3478
Needs credentials from Twilio's API: not open to every page.
MozillaNot asked
No public server
Documents no public STUN server. Firefox ships with no default ICE servers at all.

When a server says nothing

AnsweredAnsweredThe result stands

AnsweredSilentThe result stands; the silent server is named

SilentAnsweredThe result stands; the silent server is named

SilentSilentCould not test

Two operators, asked separately. One silent server is named and the result stands; when none answers, nothing was measured, and the test says so instead of showing a pass.

Is my IP address personal data?

In the EU, a dynamic IP address is personal data for a website operator who could identify you with information the provider holds. The Court of Justice decided that in 2016.

The case is Breyer, C-582/14, decided on 19 October 2016, and the Court's press release sums it up: "the dynamic internet protocol address of a visitor constitutes personal data, with respect to the operator of the website, if that operator has the legal means allowing it to identify the visitor concerned with additional information about him which is held by the internet access provider". The same press release notes that a site may have a legitimate interest in keeping some of it to defend itself against attack.

Which is the whole reason this page does its work in your browser. The ICE candidates are gathered by your browser, compared in your browser, and shown to you; no address WebRTC finds is sent to us, so there is nothing of it for us to keep, hand over or lose. You can watch the network panel while the test runs.

The Breyer rulingCourt of Justice of the European Union

C-582/14Breyer v Bundesrepublik DeutschlandOctober 19, 2016

The website operatoran address and a time, from its logs203.0.113.7 · 14:02:37
the legal means to obtain it
The internet access providerwho was using that address at that time203.0.113.7 · 14:02:37 →
Personal data, for that operator

The Court's press release: a site may have a legitimate interest in keeping some of it to defend itself against attacks.

On this page

Your browser

Gathers
Classifies
Compares
Shows

See your public address, as in any call
dnsrobot.netNo candidate is sent

Case C-582/14, Breyer. A dynamic IP address is personal data for a website operator that has the legal means to identify you with the provider's records. This page keeps the candidates in your browser.

WebRTC leak test: questions and answers

What is a WebRTC leak?

WebRTC is the browser feature behind video calls. To connect two people directly it gathers every address your machine can be reached on and offers them to the page, with no permission prompt. It becomes a leak when one of those addresses is one you were hiding — typically your real address while a VPN is on, because WebRTC can ask about every network interface rather than only the one your browsing uses.

How do I test for a WebRTC leak?

Start the test on this page. It asks three STUN servers from two operators, lists every address WebRTC produced with what kind of address each one is, and compares the routable ones with the address a website already sees. If you use a VPN, run it once with the VPN off and once with it on: the difference between the two runs is the answer.

Does a VPN stop a WebRTC leak?

Not on its own. A VPN changes where your traffic goes, but WebRTC can ask the operating system what interfaces exist, and the physical connection is usually still one of them. The IETF's own text says WebRTC can discover "not only the public address for the VPN, but also the ISP public address over which the VPN is running". Some VPN clients close the gap; this test tells you whether yours did.

What does a .local address in the results mean?

That is mDNS, and it is good news. Modern browsers replace your private addresses with a random name ending in .local before offering them to a page, so a site learns nothing about your home network from them. Chrome has done it since version 76 and Firefox does the same; Safari goes further and offers no host candidates at all until a site has camera or microphone permission. The test reports them as the protection working, not as a finding.

If mDNS hides my local IP, am I safe?

Partly. mDNS was designed to hide private addresses and explicitly not to hide one that is already public — the IETF draft that defines it says so. Your public IPv4 still appears as a server-reflexive candidate, and a machine with a routable IPv6 address can still offer that address directly. Chrome also turns the protection off for any site that already holds camera or microphone permission.

Why does the test sometimes say it could not test?

Because that is the truth. If WebRTC is switched off, blocked by an extension or a policy, or no STUN server answered — a firewall, a restrictive VPN, a network that blocks UDP — then nothing was measured. Most tools show a green tick in that situation, which is the single most misleading thing a leak test can do. This one says what happened and names which servers were silent.

How do I disable WebRTC in Firefox?

Firefox's documented preferences restrict WebRTC rather than switch it off. In about:config, media.peerconnection.ice.default_address_only sends one address instead of all of them, and media.peerconnection.ice.relay_only restricts gathering to relay candidates: that hides the most, but it breaks direct calls. The masking of private addresses, media.peerconnection.ice.obfuscate_host_addresses, is already on by default. Run the test again after each change to see what it bought you.

How do I stop WebRTC leaks in Chrome?

Chrome gives an ordinary user no setting for it; the mDNS masking of private addresses is on by default and that is the protection you get. Edge, which shares Chrome's engine, has the WebRtcLocalIpsAllowedUrls enterprise policy. The extensions still widely recommended do not work: uBlock Origin removed its WebRTC option in version 1.38, and Google's WebRTC Network Limiter cannot run since Manifest V2 was disabled in Chrome 138.

What is the difference between a host candidate and a server-reflexive one?

A host candidate is an address on your own machine. A server-reflexive candidate is what a STUN server saw — the public side of your NAT, which is usually the address the website already has from your connection. A routable host candidate is the more serious finding, because it is an address on the device itself, and on IPv6 it identifies the device rather than the household.

Is a WebRTC leak the same as a DNS leak?

No. A WebRTC leak reveals an address; a DNS leak reveals which resolver answers your lookups, which tells your provider every site you visit even when the traffic itself goes through the VPN. They fail independently, so a clean result on one says nothing about the other. Run our DNS leak test as well after any VPN change.

Does this test send my IP address anywhere?

Only where any website would see it. Your browser contacts the STUN servers, as any video call does: that is the test. To learn what a website sees, the page asks ipify.org and our own server for your addresses and their networks, as the DNS Leak Test does. The addresses WebRTC finds stay in your browser: none is sent to us. Watch your network panel while the test runs.

Is my IP address personal data under EU law?

For a website operator in the EU, a dynamic IP address is personal data when that operator has lawful means to identify you with information the internet provider holds. That is the Court of Justice's decision in Breyer, C-582/14, from October 2016. It is one reason this page keeps the WebRTC part of the test in your browser rather than on a server of ours.

Missing something?Suggest a feature or a new tool

WebRTC Leak Test

What is a WebRTC leak?

How to check for a WebRTC leak

Does a VPN stop a WebRTC leak?

Host, server-reflexive and relay: which candidate is which?

What is an mDNS .local address, and does it protect me?

Why IPv6 is the leak that is left

How to stop a WebRTC leak in each browser

WebRTC leak, DNS leak and IP leak: what is the difference?

Why this test asks more than one STUN server

Is my IP address personal data?

WebRTC leak test: questions and answers

What is a WebRTC leak?

How do I test for a WebRTC leak?

Does a VPN stop a WebRTC leak?

What does a .local address in the results mean?

If mDNS hides my local IP, am I safe?

Why does the test sometimes say it could not test?

How do I disable WebRTC in Firefox?

How do I stop WebRTC leaks in Chrome?

What is the difference between a host candidate and a server-reflexive one?

Is a WebRTC leak the same as a DNS leak?

Does this test send my IP address anywhere?

Is my IP address personal data under EU law?

VPN Test

DNS Leak Test

IPv6 Test

IP Lookup

What Is My ISP

DNS Lookup

What is a WebRTC leak?

How to check for a WebRTC leak

Does a VPN stop a WebRTC leak?

Host, server-reflexive and relay: which candidate is which?

What is an mDNS .local address, and does it protect me?

Why IPv6 is the leak that is left

How to stop a WebRTC leak in each browser

WebRTC leak, DNS leak and IP leak: what is the difference?

Why this test asks more than one STUN server

Is my IP address personal data?

WebRTC leak test: questions and answers

What is a WebRTC leak?

How do I test for a WebRTC leak?

Does a VPN stop a WebRTC leak?

What does a .local address in the results mean?

If mDNS hides my local IP, am I safe?

Why does the test sometimes say it could not test?

How do I disable WebRTC in Firefox?

How do I stop WebRTC leaks in Chrome?

What is the difference between a host candidate and a server-reflexive one?

Is a WebRTC leak the same as a DNS leak?

Does this test send my IP address anywhere?

Is my IP address personal data under EU law?

Related tools

VPN Test

DNS Leak Test

IPv6 Test

IP Lookup

What Is My ISP

DNS Lookup