What Is a WebRTC Leak? How to Test and Fix It (2026 Guide)
Fast answer: Use this guide as a practical checklist for what is a webrtc leak? how to test and fix it (2026 guide). Start with the main browser tool, confirm the result with one focused follow-up test, then change only one device, browser, or setting at a time so you know what actually fixed the issue.
You fire up your VPN, the little green "Connected" light comes on, and you assume your real IP is hidden. It often is not. A WebRTC leak is a sneaky side-channel in every modern browser that can reveal your actual ISP-assigned IP — and sometimes your local network address — to any website that cares to ask. It happens independently of your VPN tunnel, which is why it catches so many people off guard.
This guide explains what a WebRTC leak actually is, how to test for one in under a minute, and the exact fix for Chrome, Firefox, Brave, and Safari in 2026. You will also learn the two things that are not leaks but get mistaken for leaks every day: .local mDNS addresses, and local LAN IPs on modern browsers.
- What is a WebRTC leak?
- How do I test for a WebRTC leak?
- Why does WebRTC leak my IP even with a VPN?
- How to fix WebRTC leaks in Chrome and Edge
- How to fix WebRTC leaks in Firefox
- How to fix WebRTC leaks in Brave
- How to fix WebRTC leaks in Safari
- Should you disable WebRTC entirely?
- What is mDNS and why does it show a .local address?
- FAQ
What Is a WebRTC Leak?
WebRTC (Web Real-Time Communication) is a browser API that powers video calls, voice chat, screen sharing, and peer-to-peer file transfers directly inside the browser — no plugin required. Google Meet, Discord web, WhatsApp Web calls, Zoom in the browser, and most customer-support chat widgets use it.
To build a peer-to-peer connection, WebRTC has to learn your IP addresses. It does that by querying STUN servers — public internet servers that report back the IP they see you coming from. Here is the catch: those STUN queries go out over UDP, and by default they bypass whatever SOCKS or HTTP proxy your browser is configured with. That means the STUN response can reveal your real public IP even while a VPN tunnel is supposedly protecting you.
A WebRTC leak happens when a website runs a few lines of WebRTC JavaScript, collects the IPs your browser discovered, and sends them back to its own server. You never see a permission prompt. You get no warning. The site simply learns your real IP while you think you are anonymous.
A WebRTC leak can expose three classes of address: your real public IPv4 (the one your ISP assigned), your real public IPv6 (commonly leaks even when IPv4 is protected), and your local LAN IP (192.168.x.x / 10.x.x.x). Modern Chrome and Firefox mask the local IP behind a hashed .local name — see the mDNS section below for why that is a good thing, not a leak.
How Do I Test for a WebRTC Leak?
Testing for a WebRTC leak takes about 30 seconds. There is no software to install. The test runs inside your browser and uses the same WebRTC API a malicious site would use — so whatever the test sees is exactly what any website can see.
Use the free WebRTC Leak Test on this site. Here is the protocol:
- Connect to your VPN first. Verify the VPN dashboard shows the country and server you selected.
- Open the WebRTC Leak Test page in the same browser you normally use.
- Click Start scan. The page queries Google's public STUN servers and lists every IP your browser returns.
- Compare the Public IP rows against your VPN dashboard. They should all match the VPN's exit IP, not your real ISP IP.
- Repeat the test with the VPN disconnected. This gives you a baseline — those are the IPs WebRTC exposes when you are not protected.
Run the test in every browser you use. A VPN that passes in Chrome can still leak in Firefox, because the two browsers implement WebRTC slightly differently. And run it on mobile too — WebRTC works the same in Chrome for Android and Safari on iOS.
Some older leak-test pages only read IPv4 public IPs and miss IPv6 entirely. If your ISP assigns you a native IPv6 address (most do in 2026), an IPv6-only leak will slip past a v4-only test. Our WebRTC Leak Test scans IPv4, IPv6, and local IPs in one pass so nothing hides.
Why Does WebRTC Leak My IP Even When I Am Using a VPN?
The short answer: WebRTC makes STUN requests over raw UDP, and many VPN clients route only browser-initiated TCP/HTTP traffic through their tunnel. The UDP STUN packet goes out your physical network interface, hits Google's STUN server, and the STUN response carries back your real IP — because as far as that server is concerned, the request came from your real IP.
Whether your VPN leaks depends on three things:
- Does the VPN client route UDP? Cheap and free VPNs often skip UDP routing to cut costs. Everything TCP-shaped goes through the tunnel; UDP STUN packets do not.
- Does it handle IPv6? A lot of VPNs tunnel IPv4 only. If your ISP gives you IPv6, the v6 address bypasses the tunnel entirely. This is the number-one cause of "I have a VPN but my real IP still leaks."
- Does the provider block non-proxied UDP at the kernel firewall level? The paranoid ones do (Mullvad, ProtonVPN, NordVPN). Anything that escapes the tunnel never even leaves the machine.
Best VPN for WebRTC leak protection
Based on the WebRTC handling each provider publicly documents in 2026, these are the VPNs that consistently pass leak tests out of the box:
- Mullvad — blocks non-proxied UDP at the firewall level. Nothing escapes unless explicitly whitelisted.
- ProtonVPN — handles IPv6 natively (or cleanly blocks it if the server does not support it). Tunnels UDP by default.
- NordVPN — explicitly tests against WebRTC leaks as part of their kill-switch behaviour.
- ExpressVPN — uses their "network lock" kill switch to drop any traffic that would escape the tunnel, including WebRTC STUN.
Free VPNs, browser VPN extensions, and most anti-virus-bundled VPNs are unreliable for WebRTC. Test your specific setup with the WebRTC Leak Test — do not trust the marketing.
How to Fix WebRTC Leaks in Chrome (and Edge)
Chrome has no native toggle to disable WebRTC in 2026. Google removed the old chrome://flags options years ago. That leaves three practical fixes:
Option 1: Install Google's official WebRTC Network Limiter
Google publishes an official Chrome extension called WebRTC Network Limiter on the Chrome Web Store. It does not fully disable WebRTC — it tells Chrome to only use proxied UDP and to not bind to non-default routes. In practice, that stops most leaks while keeping video calling functional.
- Open the WebRTC Network Limiter page on the Chrome Web Store.
- Click Add to Chrome. No configuration — it applies instantly.
- Retest with the WebRTC Leak Test.
Option 2: Use uBlock Origin's WebRTC setting
If you already run uBlock Origin, there is a built-in toggle that blocks local-IP WebRTC leaks without killing video calling:
- Click the uBlock Origin icon in the toolbar, then the gears icon to open the dashboard.
- Go to the Settings tab (called Privacy in some versions).
- Enable Prevent WebRTC from leaking local IP addresses.
- Click Apply changes.
Option 3: Switch to a VPN with built-in leak blocking
The cleanest fix is kernel-level: a VPN that refuses to route any UDP packet outside its tunnel. That prevents the STUN query from ever reaching Google's servers, so there is nothing to leak. Mullvad, NordVPN, and ProtonVPN all do this with their kill switch enabled.
The same three options work in Microsoft Edge — Edge is built on Chromium so the extension ecosystem and behaviour are identical.
How to Fix WebRTC Leaks in Firefox (about:config)
Firefox is the only major browser where you can fully disable WebRTC with a single setting — no extension required.
Retest with the WebRTC Leak Test — every field should now report "WebRTC is disabled" or return no IPs.
WhatsApp Web voice/video calls, Google Meet, Discord in the browser, Microsoft Teams browser calls, Zoom in the browser, Jitsi, and most support-chat widgets all rely on WebRTC. If any of those stop working after you flip the toggle, that is why. Flip it back to true for the call, then back to false after, or use a separate Firefox profile for video calls.
How to Fix WebRTC Leaks in Brave
Brave is the only major browser with a built-in WebRTC leak toggle in the settings UI. You do not need an extension or about:config hack.
- Open a new tab and go to
brave://settings/privacy. - Scroll to WebRTC IP handling policy.
- Change the dropdown to Disable Non-Proxied UDP.
- Close and reopen Brave, then retest with the WebRTC Leak Test.
"Disable Non-Proxied UDP" is the sweet spot: WebRTC still works for calls routed through a VPN proxy, but it refuses to send STUN queries over a direct (non-proxied) UDP connection. No leak, calls still functional.
How to Fix WebRTC Leaks in Safari (macOS + iOS)
Safari's WebRTC behaviour is stricter out of the box — local IPs are hidden by default and public IPs go through whatever system proxy is configured. But if you want an extra layer of control:
Safari on macOS
- Open Safari, then click Safari → Settings → Advanced.
- Check Show features for web developers at the bottom.
- A new Feature Flags (or "Develop" menu item) appears.
- Open it and search for entries containing
WebRTC. - Disable the ones related to mDNS ICE candidates or legacy WebRTC APIs if you want to lock things down further. Note these flags change between Safari versions; the defaults in Safari 17+ are already privacy-respecting for most users.
Safari on iOS / iPadOS
- Open the iOS Settings app, scroll to Safari.
- Scroll down to Advanced → Experimental Features.
- Find the WebRTC entries and toggle them off if you want to disable specific behaviours.
On iOS, the VPN itself does the heaviest lifting. Unlike desktop VPNs, iOS forces all traffic (including UDP) through the configured VPN profile when the VPN is connected — so iOS VPN leaks are rarer than desktop ones, but not impossible.
Should You Disable WebRTC Entirely?
Usually, no. Fully disabling WebRTC is a blunt tool — it stops the leak but also stops every WebRTC-dependent app in your browser.
| What breaks when you disable WebRTC | What still works |
|---|---|
| Google Meet (browser) | Google Meet (installed app) |
| Discord in the browser — voice and video | Discord desktop app |
| WhatsApp Web voice/video calls | WhatsApp Web messaging (no calls) |
| Microsoft Teams in the browser | Microsoft Teams desktop app |
| Zoom web client | Zoom installed app |
| Jitsi Meet, Whereby, most browser call tools | Any tool that uses the native app route |
| In-browser screen sharing | Screen sharing in installed apps |
For most people, the right move is not full disable — it is either picking a VPN that blocks WebRTC leaks at the network layer, or flipping Brave's "Disable Non-Proxied UDP" mode which keeps WebRTC usable while making it leak-safe.
If you are a journalist, activist, security researcher, or anyone whose threat model includes being deanonymized by a webpage, full disable is the correct call. Accept the broken video calls and use installed apps for those. For a normal privacy-minded user, a good VPN plus Brave is a better balance.
What Is mDNS and Why Does My Leak Test Show a .local Address?
If you run a WebRTC leak test on Chrome in 2026 and see a weird local-IP row like a1b2c3d4-5678-90ab-cdef-1234567890ab.local, you have not been hacked. That is mDNS (Multicast DNS) — a privacy mitigation Chrome added in version 76 (released August 2019) and every Chromium browser has used since.
Here is what is actually happening:
- Before mDNS, Chrome would expose your real LAN IP (e.g.
192.168.1.42) to any website doing WebRTC. This could be used to map your network topology or target router exploits. - With mDNS, Chrome generates a random hashed name that ends in
.localand exposes that instead of the real LAN IP. - The hash is unique per browser session, cannot be reversed back into a real IP, and means nothing outside your own LAN.
So seeing a .local address on a leak test is the fix working, not a leak. The leak would be if you saw your actual 192.168.x.x address instead.
On a WebRTC leak test result: your real public IPv4/IPv6 showing = leak. A .local hashed address showing = not a leak, that is the browser protecting you. A 192.168.x.x, 10.x.x.x, or 172.16–31.x.x raw IP showing = leak (old browser or no mDNS).
Watch: 3-minute WebRTC leak walkthrough
If you prefer a visual walkthrough, this short video covers the WebRTC disable flow in Firefox and the extension approach in Chrome:
FAQ — Quick Answers
Does incognito mode stop WebRTC leaks?
No. Incognito only stops the browser from saving history, cookies, and form data locally. It does not change any network-level behaviour. WebRTC exposes exactly the same IPs in an incognito window as in a normal one. If your setup leaks in one, it leaks in the other.
Can websites see my local IP address through WebRTC?
On modern Chrome, Edge, Brave, and Firefox — no. Local LAN IPs are hidden behind mDNS hashes (.local names) unless the site has been granted camera or mic permission. Older browsers (pre-2019) and some enterprise-locked-down browsers without mDNS can still expose raw 192.168.x.x addresses.
Does disabling IPv6 stop WebRTC leaks?
Partly. If your VPN tunnels IPv4 only, disabling IPv6 in your OS network settings prevents WebRTC from reporting your real IPv6 address. But it does not fix an IPv4 leak, and it can break some modern apps that expect v6 connectivity. A better solution is a VPN that handles IPv6 natively or blocks it at the firewall level.
Will a browser extension really stop all WebRTC leaks?
For the local-IP leak, yes — uBlock Origin's toggle and Google's Network Limiter both prevent local-IP enumeration. For the public-IP leak (the real privacy issue), extensions are less reliable than a network-layer fix from your VPN. Always retest after installing an extension.
My test shows "VPN IP" in the public field — is that safe?
Yes. If the public IP shown on the WebRTC Leak Test matches what your VPN dashboard says, WebRTC is going through the tunnel correctly and no leak is happening. That is the expected good result.
I run the test and it shows nothing at all — is that good?
If the scan returns zero IPs (or explicitly says "WebRTC disabled"), you have either disabled WebRTC in Firefox, or an extension like WebRTC Control is fully blocking the API. That is the most private possible state — just remember it will break any browser video-calling apps you rely on.
Does a browser fingerprinting blocker like Canvas Defender stop WebRTC leaks?
No. Fingerprinting blockers target canvas, WebGL, and font enumeration. WebRTC is a separate API and needs its own specific fix (the Network Limiter extension, uBlock's toggle, Firefox's about:config, or Brave's WebRTC IP handling policy).
Related tools & guides
- WebRTC Leak Test — free browser-based scan for IPv4, IPv6, and local-IP leaks.
- Input Latency Checker — the rest of our network diagnostics hub for keyboard, mouse, and connection delays.
- Webcam Test and Microphone Test — same
getUserMedia/ WebRTC APIs, used for checking your camera and mic work before a call. - Headphone & Speaker Test — also built on the browser's WebRTC audio stack.
- Secure Password Generator — all generation happens locally; nothing is sent to any server.
- Input Latency Checker Guide — how to measure and reduce keyboard/mouse delay.
- How to Test Your Microphone Online — sibling post on WebRTC-powered mic testing.
- Webcam Test Guide — verify your camera before calls.
Run the test now: Check your browser for WebRTC leaks — takes 30 seconds, no signup.
Quick Action Checklist
- Start with the simplest browser test that matches the task.
- Change one setting at a time so results are easy to interpret.
- Retest after cleaning, restarting, or changing devices.
- Use related tools to confirm the first result before making a decision.