How to Run a WebRTC Leak Test

Every few years a browser feature turns out to matter more for privacy than anyone expected. WebRTC is one of them. It is the technology that lets a web page run a video call, a screen share or a voice chat directly in the browser without installing anything. To do that job, the browser has to work out which network addresses can reach your computer, and it can tell the page what it finds. When that list includes the public address your internet provider assigned, a VPN that hides your normal browsing can still appear to be bypassed for that one feature.

This article is about how to test WebRTC leaks properly: how to read the results in Chrome and Firefox, how to separate a harmless private address from a real exposure, and what to change when something does show up. For the concept itself, see what a WebRTC leak is; here the focus is on the test.

What a WebRTC leak test is actually looking for

WebRTC connects two ends using a process called ICE. In plain terms, your browser gathers a list of candidates, each one a possible way to reach it. The page can read that list with a few lines of script.

There are four kinds of candidate you may see:

• Host candidates. Addresses on your own device or local network, for example a private address such as 192.168.1.20. Defined as private ranges in the internet's address allocation rules, they mean little outside your home or office.
• Server-reflexive candidates. The public address a helper server (called a STUN server) sees when your browser contacts it. This is the one that matters most. If it is your provider's address while the VPN is on, that is the leak.
• Relay candidates. An address of a relay server used when direct connections fail. These appear only in some configurations.
• mDNS names. Modern browsers often replace your real local address with a random-looking name ending in .local, specifically to avoid revealing your private network layout.

A leak test page simply collects those candidates and prints them. The test does not prove that a particular site is spying; it shows what any site could read. The standard behind all this is described in the W3C WebRTC specification, and the MDN guide to the WebRTC API explains the same ideas in developer-friendly language.

Prepare a clean test: baseline first, extensions second

The result is only useful if you can compare it to something. Do this before you open the VPN.

1. Close the VPN and wait ten seconds.
2. Open the WebRTC test page in the browser you want to check, in a normal window.
3. Copy down the candidates: any public addresses, any private addresses, and any .local names. This is your baseline. The public address here should be your provider's.
4. Check which extensions are active. Ad blockers, privacy extensions and some VPN extensions change WebRTC behaviour. List them. For the first test, use a profile or a private window in which extensions are disabled, so you see the browser's own behaviour.
5. Note the browser version. Behaviour differs between versions, and you will want that detail if you retest later.

Doing the baseline gives you a clear rule for the main test: while the VPN is connected, the list must not contain your baseline public address.

If you also want to compare with a general leak check, run the steps in how to check for VPN IP address leaks in the same session. WebRTC leaks are separate from ordinary web-request leaks, and a clean result on one tells you nothing about the other.

Running the test in Chrome

Chrome and other Chromium-based browsers share most WebRTC behaviour. Follow this sequence.

1. Connect the VPN and wait until the app says it is connected.
2. Open a new incognito window. Extensions are off there by default unless you allowed them.
3. Load the WebRTC test page and wait for it to finish gathering. It can take a few seconds.
4. Read the list. For each line, ask: is this a private address, a .local name or a public address?
5. Compare any public address to the baseline you wrote down.
6. Refresh twice more. Candidate gathering can vary slightly from run to run.
7. Repeat with extensions enabled, one at a time, if you use any. A privacy extension that adjusts WebRTC may remove an address that the browser would otherwise show.

What you will usually see in current versions of Chrome is a .local name instead of your private address, plus one public address. With the VPN working correctly, that public address belongs to the VPN. If you see two public addresses, one IPv4 and one IPv6, check both against the baseline, because the second one is where leaks often hide. The older, shorter format is defined in RFC 791; the IPv6 behaviour is explained in the IP leak companion article.

Chrome does not give ordinary users a built-in switch to turn off WebRTC. Settings that restrict how addresses are exposed exist for extensions to use, which is why many leak fixes in Chromium browsers come as extensions. Treat those with the same care as any extension: read what permissions they ask for, as discussed in browser extension versus app.

Running the test in Firefox

Firefox exposes more of its own settings, which makes it useful for understanding the behaviour.

1. Connect the VPN and confirm it is active.
2. Open a private window.
3. Load the test page and let it gather candidates.
4. Read the list and compare to your baseline, just as in Chrome.
5. If you want to experiment, open the advanced configuration page by typing about:config in the address bar and accept the warning. Search for media.peerconnection.enabled.
6. Setting that value to false switches WebRTC off for the browser. Reload the test page: it should now report no candidates at all.
7. Set it back to true when you finish experimenting, unless you are sure you do not need browser calls. Video-meeting sites, voice chat and some file-sharing tools stop working when WebRTC is disabled.

Firefox also has settings that make the browser behave more conservatively with addresses without turning WebRTC off entirely. Search the advanced page for media.peerconnection to see them. Changing advanced settings is something to do carefully: note the original value before you edit, and if the browser behaves strangely, use the reset option on the same page.

Because Firefox lets you turn the feature off and on, it is a handy way to prove cause and effect: leak present with WebRTC on, absent with it off. That tells you the problem is WebRTC and not your VPN tunnel as a whole.

Reading the candidate list: a decision table

Here is how to classify what you see while the VPN is connected.

Candidate in the list	Example	Leak?	Reason
Random name ending in .local	a1b2c3.local	No	Browser is hiding your local address
Private IPv4 address	192.168.1.20 or 10.0.0.5	Usually no	Only meaningful inside your own network
Public address, same as VPN exit	Matches the normal IP check	No	Traffic shown as coming from the VPN
Public address, same as baseline	Your provider's address	Yes	Real address exposed to the page
Public IPv6 address, same as baseline	Long hex address	Yes	The IPv6 route bypasses the tunnel
No candidates at all	Empty	No	WebRTC disabled or blocked, calls may not work
Relay address	Not your provider's	No	Belongs to a relay service

Two cautions. First, one private address is not harmless in every setting: on a shared office network it reveals a little about how the network is laid out, which some people prefer not to share. Second, always compare against the baseline you recorded yourself; do not trust a number just because it looks unfamiliar.

Test a real call, not only a test page

A test page shows what could be read. A call test shows what actually happens. This extra step takes five minutes and catches a different set of problems.

• A two-person test. Ask a friend to join a browser-based video call while the VPN is on. Afterwards, check the test page again: some browsers expose different candidates while a call is active.
• Switching networks mid-call. Start a call on Wi-Fi, then switch to mobile data. WebRTC may renegotiate its route during the switch. Run the test page right after.
• Audio and video quality. If calls lag or stutter with the VPN on, that is not a leak, but it tells you the call is going through the tunnel. Latency explanations are in why internet speed changes with a VPN.
• Permission prompts. When a site asks for the camera or microphone, check that you recognise the site. WebRTC leak concerns are small compared with granting access to the wrong page.

For a remote worker, the safest habit is to run a quick test before an important client call rather than discover a problem during it.

What to change when a public address leaks

Move from the least disruptive to the most disruptive option.

1. Reconnect the VPN and retest. Gathering sometimes happens before the tunnel is fully up.
2. Update the browser. Newer releases tend to limit address exposure better.
3. Retest in a clean profile with no extensions. If the leak disappears, one of your extensions is the cause.
4. Use the browser's own privacy setting where one exists, for example the Firefox preferences discussed above, in the narrowest form that stops the exposure.
5. Use a dedicated privacy extension that restricts WebRTC address handling, if you work in a Chromium browser. Check its permissions and reputation first, and retest afterwards.
6. Switch off WebRTC entirely only if you never need calls in that browser. Consider using a second browser for meetings.
7. Use a system-wide VPN app instead of a browser add-on, so the tunnel covers the device rather than a single browser. The browser extension versus app comparison explains why. With XPASS, that means the free VPNclient app, which you sign in to with the details on your My Pass page; see the download page.

After each change, run the test again. Never assume a fix worked until the list proves it.

Common mistakes in WebRTC testing

• Testing with the VPN still connecting. Wait for a full connection.
• Treating every private address as a leak. Private ranges are not reachable from the wider internet.
• Forgetting IPv6. Look for both address types in the list.
• Trusting an old result. Browser updates, new extensions and new networks all change the picture.
• Disabling WebRTC and forgetting about it. Then a meeting fails on Monday morning and nobody remembers why.
• Installing the first extension a search shows. A tool that promises to fix privacy but asks for permission to read every page is a bigger risk than the leak.
• Believing a clean WebRTC test means total privacy. It covers one feature. Cookies, accounts and browser fingerprints still identify you; Cover Your Tracks shows how much a browser reveals beyond its address.

Summary

A WebRTC leak test collects the address candidates your browser offers to web pages and checks whether any public one matches the address you had before the VPN. Record a baseline first, test in a clean window, read the list line by line in Chrome and Firefox, and treat private and .local entries differently from public ones. If a real leak shows up, apply the gentlest fix that works, test again, and keep calls working by not disabling more than you need.

When you want a VPN to run these tests against, the pricing page lists the prepaid passes, which you can compare at your own pace.