WebRTC Test

Test your browser for WebRTC IP leaks — check whether WebRTC exposes your real IP address even when using a VPN or proxy. Free browser-based WebRTC leak detection tool.

Why Run a WebRTC Test?

Detect VPN bypass leaks: WebRTC uses STUN servers to discover network paths — this process can reveal your real public IP address even when all other traffic routes through a VPN tunnel, defeating the anonymity you expect.
Find local IP exposure: WebRTC ICE candidates can expose private/local IP addresses (192.168.x.x, 10.x.x.x) even without a VPN — this fingerprinting data can identify your device on shared networks or reveal your home network range.
Verify VPN effectiveness: Not all VPNs block WebRTC leaks — some route WebRTC traffic outside the VPN tunnel by design for better call quality, inadvertently exposing your real IP during privacy-sensitive browsing.
Browser privacy hardening validation: After changing browser settings or installing privacy extensions, run a WebRTC test to confirm the changes actually prevent IP disclosure — many settings changes require verification to ensure they took effect.
Journalism and sensitive communication: Journalists, activists, and privacy-conscious users who rely on VPNs for source protection must verify WebRTC doesn't bypass their anonymity measures before conducting sensitive research.

Run Check

How to Run the WebRTC Test

Open the test without VPN: First run the test with your VPN disconnected — this establishes your real public IP address as the baseline for comparison.
Connect your VPN and retest: Enable your VPN, then run the WebRTC test again — a leak-free VPN should show only the VPN's IP address in the WebRTC candidates, not your real IP.
Read the ICE candidates: The test lists all IP addresses discovered via WebRTC's ICE (Interactive Connectivity Establishment) protocol — look for your real ISP-assigned IP appearing alongside or instead of the VPN IP.
Check local IP candidates: Local IPs (starting with 192.168, 10, or 172.16-31) are normal in the candidate list — the critical check is whether your real public IP from step 1 appears in step 2's results.
Fix leaks if found: If a leak is detected, see the remediation steps below — browser settings changes or VPN provider switching may be required.

Real-World Use Case

A freelance journalist covering a sensitive political story in a country with internet surveillance connects through a reputable VPN service before accessing sources online. Before starting research, they run the WebRTC test and discover their real IP address (assigned by their home ISP) appears in the WebRTC ICE candidates despite the VPN being active. Their VPN application doesn't route WebRTC traffic through the tunnel. The test immediately identifies the risk — if they had proceeded without this check, their real location could have been revealed to sites monitoring WebRTC requests. They disable WebRTC in Firefox via about:config (setting media.peerconnection.enabled to false) and verify the fix eliminates the leak before continuing their research.

Best Practices

Test before and after VPN connection: Always establish a baseline (real IP) before connecting the VPN, then compare — this confirms you're identifying actual leaks versus expected behavior.
Test in the same browser you'll use for sensitive work: Different browsers have different WebRTC implementations — a leak in Chrome doesn't mean the same leak exists in Firefox, and vice versa.
Disable WebRTC entirely if video calls aren't needed: In Firefox, navigate to about:config and set media.peerconnection.enabled to false — this eliminates all WebRTC leak risk at the cost of losing browser-based video call capability.
Use WebRTC-aware VPNs or browsers: Brave browser blocks WebRTC by default in its Shields settings; some VPN providers have dedicated WebRTC leak prevention — verify with a test after enabling.
Re-test after browser updates: Browser updates sometimes reset privacy settings or change WebRTC behavior — run a WebRTC test after each major browser version update to verify your configuration still holds.

Performance & Limits

Detection scope: Tests for public IP leaks via WebRTC STUN requests and local IP disclosure via ICE candidate enumeration.
Browser compatibility: Works in all modern browsers that support WebRTC (Chrome, Firefox, Safari, Edge) — browsers without WebRTC support will show "WebRTC not available."
Test duration: ICE candidate gathering typically completes in 3-8 seconds depending on network conditions and number of network interfaces.
STUN servers used: Multiple public STUN servers are queried to ensure thorough detection — different STUN servers may reveal different IP addresses depending on routing.
Limitations: Cannot detect WebRTC leaks in other applications (Zoom, Discord, etc.) — only tests the browser's WebRTC implementation.

Common Mistakes to Avoid

Testing without establishing a baseline: Without knowing your real IP first, you can't verify whether what appears in WebRTC results is a leak — always test without VPN first.
Assuming local IPs are leaks: Private IP addresses (192.168.x.x, 10.x.x.x) appearing in WebRTC results are normal behavior — the security concern is your real public ISP-assigned IP appearing when a VPN is active.
Using browser extensions as the only fix: WebRTC-blocking extensions can be bypassed by some websites — browser-level settings changes (about:config in Firefox) or VPN-level solutions are more reliable than extension-based blocking.
Concluding one test is sufficient: Run the WebRTC test multiple times and across different networks (home Wi-Fi, mobile hotspot, office) — leak behavior can differ based on network configuration and routing.

Privacy & Security

Test runs locally in your browser: The WebRTC test uses your browser's built-in WebRTC API to gather ICE candidates — no external service receives your IP data except the STUN servers used by WebRTC itself (which is exactly what leaks IP addresses).
Results not stored: IP addresses discovered during the test are displayed only in your browser — they are not logged, stored, or transmitted to this site's servers.
STUN server queries: STUN servers used during ICE gathering do receive connection requests — this is the inherent mechanism of WebRTC and why the test reveals leaks.
No account required: Run the WebRTC test without registration or any personal information.

Frequently Asked Questions

What is a WebRTC leak and why does it matter?

A WebRTC leak occurs when your browser's WebRTC implementation reveals your real public IP address through the ICE (Interactive Connectivity Establishment) protocol, even when you're connected to a VPN. WebRTC needs to discover network paths for peer-to-peer communication (video calls, file sharing) and uses STUN servers to find your external IP — this process bypasses VPN tunnels because it's handled at the browser API level, not the network routing level. The leak matters because it deanonymizes you: anyone who can monitor WebRTC connections (surveillance, website operators using WebRTC APIs) can learn your real IP, location, and potentially ISP identity despite your VPN showing a different IP for regular HTTPS traffic.

How do I fix a WebRTC leak in Firefox?

In Firefox, navigate to about:config in the address bar, accept the warning, and search for "media.peerconnection.enabled" — set it to false to completely disable WebRTC. This eliminates all WebRTC leak risk but also disables browser-based video calls (Google Meet, Jitsi). For a more surgical fix that preserves video call functionality: search for "media.peerconnection.ice.default_address_only" and set it to true — this restricts ICE to only the default network interface, preventing local IP leakage while maintaining basic WebRTC functionality. Re-run the WebRTC test after making either change to confirm the fix is effective before relying on it for sensitive browsing.

Does my VPN protect against WebRTC leaks?

Not automatically — VPN protection against WebRTC leaks depends on the VPN implementation. VPNs that route WebRTC traffic through the tunnel protect against public IP leaks but may still expose local IP addresses via ICE candidates. VPNs that don't handle WebRTC specially leave all WebRTC traffic outside the tunnel, causing complete public IP leaks. Brave Browser blocks WebRTC IP leaking by default. Some VPN providers (Mullvad, ProtonVPN) explicitly document WebRTC leak prevention — verify with this test regardless of claims. The safest approach: disable WebRTC in Firefox or use Brave Browser rather than relying on VPN-level WebRTC protection, which is inconsistently implemented.

What does it mean if I see multiple IP addresses in the WebRTC test?

Multiple IPs in WebRTC results is normal — the ICE protocol discovers all possible network paths and lists them all as "candidates." You'll typically see: your local/private IP (192.168.x.x or 10.x.x.x from your router), possibly your IPv6 address, and your public IP address. When using a VPN, you may see the VPN's virtual interface IP (e.g., 10.8.0.1) alongside local IPs — this is expected and not a leak. The leak concern is specifically when your real public IP (matching what you see without VPN) appears in the list while your VPN is active. If only VPN IPs and private IPs appear when the VPN is connected, your VPN is preventing the WebRTC public IP leak.