WebRTC IP Leak Test: Check Browser Candidate Exposure

By Katia Belokon

Use the focused WebRTC test first

Best next step: run the WebRTC Leak Test and compare candidate categories before and after browser/VPN setting changes.

Broader context: if the route still looks inconsistent, check the VPN Leak Test, DNS Leak Test, and IPv6 Leak Test. Avoid treating one WebRTC result as a complete privacy review.

Quick Answer

A WebRTC IP leak test reviews browser candidate behavior in the current session. Focus on whether public, private/local, masked, or unknown candidates appear, and compare results after browser or VPN setting changes.

The test helps identify review points, but it does not certify the whole VPN, every app, every browser profile, or every future connection.

What WebRTC Actually Reveals

Public IP Address Exposure

WebRTC (Web Real-Time Communication) enables direct browser-to-browser communication for video calls, file sharing, and peer connections. To establish these connections, browsers use STUN (Session Traversal Utilities for NAT) servers to discover your public IP address and local network addresses. This discovery happens automatically in the background, without requiring user permission or showing visible indicators.

When you run a webrtc ip leak test, the tool creates a temporary WebRTC connection that queries STUN servers and collects every IP address your browser reveals. The test typically shows:

• Your public IPv4 address assigned by your ISP or visible network endpoint
• Your public IPv6 address if your network supports dual-stack connectivity
• Local network addresses, including common RFC 1918 private ranges such as 192.168.x.x, 10.x.x.x, and the private 172-dot-sixteen through 172-dot-thirty-one block
• Link-local IPv6 addresses that identify your device on the local segment

The public addresses matter most for privacy because they identify your network location to websites, trackers, and peer connections. Local addresses usually stay behind NAT and don’t directly expose your location, but they can still contribute to device fingerprinting when combined with other browser signals.

How WebRTC Candidate Routing Can Differ From a VPN Route

VPNs route your web traffic through an encrypted tunnel to a remote server, changing the public IP address that websites see. But WebRTC operates at the browser level and can query STUN servers directly, creating connections that use a candidate path that differs from the expected VPN route. This happens because:

• WebRTC uses its own network stack separate from normal HTTP/HTTPS traffic
• STUN requests can use UDP protocols that some VPN configurations don’t capture
• Browsers prioritize direct peer connections for performance, even when system-level routing has changed
• The WebRTC API executes before the VPN client can intercept the connection attempt

When a leak occurs, websites using WebRTC-based tracking can see both your VPN’s public IP (from normal page requests) and your real ISP address (from WebRTC STUN queries). This dual visibility may weaken the expected route separation that VPN users expect.

Running The Test Correctly

Before You Start

Establish a baseline before making any privacy changes. Visit MyIPScan and note your current public IP address, ISP name, and approximate location. This gives you a reference point for comparison. Then run a dedicated webrtc ip leak test using a tool that specifically queries WebRTC APIs and displays all discovered addresses.

Close unnecessary browser tabs, disable extensions temporarily, and ensure you’re not signed into accounts that might cache network information. The goal is to see what your browser reveals in a clean state, without interference from cached data or extension behavior.

Reading The Test Results

A typical test result shows multiple sections:

Result Section	What It Shows	Privacy Implication
Public IP (IPv4)	Your visible internet address	Reveals ISP, approximate location, and network identity
Public IP (IPv6)	Your IPv6 address if available	Can be more specific than IPv4, may persist across sessions
Local IP addresses	Private network addresses behind NAT	Contributes to fingerprinting but doesn’t reveal location
WebRTC status	Whether WebRTC APIs are enabled	Disabled WebRTC prevents all leak vectors

Compare the public addresses from the WebRTC test with the address shown by your standard IP checker. If they match and you’re not using a VPN, the result is expected. If they differ, or if your real ISP address appears alongside a VPN address, you have a review condition.

After Enabling Privacy Tools

Enable your VPN, proxy, or Tor connection, then run the same webrtc ip leak test again. A lower-risk browser-session result keeps visible public candidates aligned with the expected VPN route in both the standard check and the WebRTC test. no unexpected public ISP-route candidate in this browser session should appear.

If your real address still appears in the WebRTC section while the main IP check shows the VPN address, the result needs review. This split result is the most common failure pattern and requires immediate attention.

What The Test Cannot Show

Account-Level Identity

Changing your visible IP address through a VPN does not change your identity to services where you remain logged in. If you sign into the same email account, social media profile, or shopping site after connecting to a VPN, that service can still link your current session to your account history, previous locations, and stored preferences.

WebRTC leak tests measure network-layer visibility. They don’t detect application-layer tracking through cookies, authentication tokens, browser storage, or account telemetry. A clean WebRTC result means websites can’t see your real IP through that specific vector, but it doesn’t prevent recognition through dozens of other signals.

DNS Resolver Leaks

DNS (Domain Name System) queries translate website names into IP addresses. Even when WebRTC is properly contained, your browser or operating system might send DNS queries to your ISP’s resolver instead of through your VPN’s encrypted tunnel. This creates a separate leak vector that reveals which websites you visit, even if the actual connections use the VPN.

WebRTC tests don’t check DNS behavior. For complete coverage, run a separate DNS leak test to verify that your queries route through the expected resolver. DNS and WebRTC leaks are independent problems that require separate fixes.

Browser Fingerprinting

Your browser reveals dozens of configuration details that create a unique fingerprint: installed fonts, screen resolution, time zone, language preferences, installed plugins, canvas rendering behavior, audio context properties, and WebGL capabilities. These signals persist across IP address changes and can identify your device even when network-level identifiers change.

A webrtc ip leak test focuses on one specific signal—the IP addresses revealed through WebRTC APIs. It doesn’t measure the hundreds of other data points that contribute to browser fingerprinting. Treat network tests as one layer of privacy verification, not as proof of complete anonymity.

How to read this: WebRTC may expose public, local/private, masked, or unknown candidates depending on browser behavior, VPN routing, mDNS masking, IPv6, and current session state. A public candidate that does not match the expected route is a review condition, not a complete privacy verdict.

IPv6 Leaks Alongside IPv4 Protection

Many VPN services route IPv4 traffic correctly but fail to handle IPv6 connections. If your ISP provides IPv6 and your VPN doesn’t support it, WebRTC can reveal your real IPv6 address while your IPv4 traffic appears protected. This dual-stack leak is common and often overlooked because users only check the IPv4 result.

The fix is to either use a VPN that fully supports IPv6 or disable IPv6 at the operating system level. Leaving IPv6 enabled without VPN coverage creates a persistent leak vector that defeats the purpose of the privacy tool.

Local Network Addresses

Seeing local addresses like 192.168.1.x or 10.0.0.x in a WebRTC test is normal and usually not a privacy concern. These addresses identify your device within your home or office network but aren’t routable on the public internet. Websites can’t use them to determine your location or ISP.

Still, local addresses do contribute to device fingerprinting. The specific address, combined with other browser signals, can help trackers recognize your device across sessions. This is a lower-severity issue than public IP leaks but still worth understanding.

STUN Server Variability

Different WebRTC leak tests query different STUN servers. Some tests use Google’s public STUN servers, others use independent infrastructure, and some query multiple servers to catch edge cases. This means you might see slightly different results across testing tools, especially if your network or VPN handles different STUN endpoints inconsistently.

Run tests from at least two independent sources to confirm results. If one test shows a leak and another doesn’t, investigate which STUN servers each test uses and whether your VPN configuration treats them differently.

Fixing WebRTC Leaks

Browser-Level Controls

Modern browsers offer settings to limit or disable WebRTC functionality:

Firefox: Type about:config in the address bar, search for media.peerconnection.enabled, and set it to false to completely disable WebRTC. For a less aggressive approach, set media.peerconnection.ice.default_address_only to true to limit IP exposure without breaking WebRTC functionality.

Chrome and Edge: These browsers don’t offer built-in settings to disable WebRTC. Install a reputable extension like “WebRTC Leak Prevent” or “uBlock Origin” (which includes WebRTC protection options). Configure the extension to block or limit WebRTC IP exposure.

Safari: WebRTC is more restricted by default in Safari, but you can further limit it through Developer menu settings. Enable the Developer menu in Preferences, then use Develop > WebRTC > Disable ICE Candidate Restrictions to test different configurations.

VPN-Level Protection

Quality VPN services include WebRTC leak protection in their client software. This typically works by:

• Intercepting STUN requests and routing them through the VPN tunnel
• Blocking WebRTC traffic entirely when the VPN is active
• Modifying browser settings automatically when the VPN connects
• Implementing firewall rules that prevent WebRTC from bypassing the tunnel

Check your VPN client settings for options labeled “WebRTC leak protection,” “WebRTC blocking,” or similar. Enable these features and verify with a test. If your VPN doesn’t offer WebRTC protection, combine it with browser-level controls or consider switching to a service that addresses this vector.

Operating System Firewall Rules

Advanced users can create firewall rules that block STUN traffic outside the VPN tunnel. This prevents WebRTC from establishing direct connections that bypass your privacy tool. The specific implementation depends on your operating system and firewall software, but the principle is to deny UDP traffic to common STUN server ports (typically 3478 and 19302) except through the VPN interface.

This approach requires technical knowledge and can break legitimate WebRTC applications like video conferencing tools. Use it only if you understand the trade-offs and can troubleshoot connectivity issues.

Interpreting Results In Context

Location Accuracy Limits

IP geolocation databases map IP addresses to approximate locations, typically at the city or regional level. The location shown in a WebRTC leak test comes from these databases, which can be outdated, imprecise, or simply wrong. According to Cloudflare’s explanation of IP addresses, an IP address identifies a network endpoint but doesn’t contain precise geographic coordinates.

Don’t overreact if the displayed city is wrong by 50 miles or if the location jumps between nearby cities across repeated tests. The meaningful question is whether the IP address itself matches your expectation—whether it shows your ISP or your VPN provider, not whether the city label is pixel-perfect.

Shared Infrastructure And Exit Nodes

VPN services, mobile carriers, corporate networks, and cloud providers often route multiple users through shared IP addresses. When you connect to a VPN, you typically share an exit node IP with dozens or hundreds of other users. This is intentional—it makes individual activity harder to isolate.

A WebRTC test showing a shared VPN IP is working correctly. The test can’t distinguish between you and other users on the same exit node, which is exactly the privacy benefit you’re seeking. Don’t expect a unique IP address when using shared infrastructure.

Split Tunnel Configurations

Some VPN clients offer split tunneling, which routes only selected applications or websites through the VPN while sending other traffic directly to the internet. If split tunneling is enabled and your browser isn’t included in the VPN route, WebRTC tests will show your real IP address even though the VPN is connected.

Check your VPN client’s split tunnel settings. Ensure your browser is explicitly included in the VPN route, or disable split tunneling entirely if you want all traffic protected. Run the test again after adjusting these settings.

Testing Checklist

Follow this sequence for thorough verification:

1. Record your baseline public IP address without any privacy tools active
2. Run a webrtc ip leak test and save all displayed addresses (IPv4, IPv6, local)
3. Enable your VPN or privacy tool and wait for the connection to stabilize
4. Check your public IP again—it should show the VPN server’s address
5. Run the WebRTC test again and compare results to your baseline
6. Verify that no unexpected public ISP-route candidate in this browser session appears in the WebRTC results
7. Run a DNS leak test separately to check resolver behavior
8. Test from a clean browser profile without signed-in accounts
9. Repeat the WebRTC test from a second independent testing tool
10. Document which configurations pass and which reveal leaks

When Results Conflict

Different Tests Show Different Results

If one WebRTC leak test shows your real IP while another shows only your VPN address, the difference usually comes from which STUN servers each test queries or how aggressively each test probes WebRTC APIs. Some tests make multiple connection attempts using different protocols, while others perform a single quick check.

Trust the test that shows the leak. If any legitimate test can discover your real IP through WebRTC, assume that tracking scripts and sophisticated adversaries can do the same. Fix the underlying configuration rather than shopping for a test that gives you the result you want.

Mobile Versus Desktop Results

Mobile browsers often implement WebRTC differently than desktop browsers. iOS Safari, Chrome on Android, and mobile Firefox each have distinct WebRTC behaviors, permission models, and leak characteristics. A configuration that works on desktop might fail on mobile, or vice versa.

Test on every device and browser you actually use. Don’t assume that fixing a leak in desktop Chrome automatically protects you in mobile Safari. Each platform requires separate verification.

Advanced Considerations

WebRTC In Embedded Contexts

WebRTC doesn’t only run in your main browser. Embedded web views in mobile apps, Electron-based desktop applications, browser extensions, and even some email clients can execute WebRTC code. A leak test in your browser might show clean results while an embedded web view in a messaging app quietly reveals your real IP.

Comprehensive protection requires system-level controls—VPN clients that capture all traffic, firewall rules that block STUN requests outside the tunnel, or network-level filtering that prevents WebRTC connections entirely. Browser-level fixes only protect that specific browser.

Peer-To-Peer Application Behavior

Video conferencing tools, file sharing applications, and gaming platforms often use WebRTC or similar peer-to-peer protocols. These applications need to discover your real IP address to establish direct connections. If you block WebRTC completely, these applications may fail or fall back to slower relay servers.

Decide whether you need WebRTC functionality for legitimate applications. If you regularly use video calls, you might accept the leak risk during those sessions and disable WebRTC only for general browsing. If you never use peer-to-peer features, disabling WebRTC entirely is the safest approach.

FAQ

What does a WebRTC leak test actually check?

A WebRTC leak test creates temporary peer-to-peer connections using your browser’s WebRTC APIs and queries STUN servers to discover which IP addresses your browser reveals. The test collects your public IPv4 address, public IPv6 address if available, and local network addresses, then displays them so you can verify whether your real ISP address is exposed even when using a VPN or proxy. The test specifically targets the WebRTC communication channel, which operates separately from normal web traffic and can bypass VPN tunnels if not properly configured.

Can I use a VPN and still have a WebRTC leak?

Yes, WebRTC leaks commonly occur even with an active VPN connection because WebRTC operates at the browser level and can establish direct connections to STUN servers before the VPN client intercepts the traffic. Many VPN services don’t automatically protect against WebRTC leaks unless you enable specific settings in the VPN client or install browser extensions that block or limit WebRTC functionality. Always run a WebRTC leak test after connecting to your VPN to verify that only the VPN server’s IP address appears in the results, with no unexpected public ISP-route candidate in this browser session.

Should I completely disable WebRTC in my browser?

Disabling WebRTC can reduce this browser-session risk but breaks functionality in web applications that depend on peer-to-peer communication, including video conferencing tools, browser-based calling features, some file sharing services, and certain gaming platforms. If you never use these features, disabling WebRTC is the safest approach. If you occasionally need WebRTC functionality, use browser profiles—keep WebRTC disabled in your default privacy-focused profile and enable it only in a separate profile used specifically for video calls or other peer-to-peer applications.

Why does my WebRTC test show a different location than my actual location?

The location displayed in a WebRTC leak test comes from IP geolocation databases that map IP addresses to approximate geographic areas, typically at the city or regional level. These databases are often inaccurate, outdated, or based on the registered address of the ISP or network operator rather than your actual physical location. The important information is the IP address itself and which network it belongs to—whether it shows your ISP or your VPN provider—not the precise city label. Location accuracy varies widely across different IP ranges and geolocation providers.

Do I need to run both a WebRTC leak test and a DNS leak test?

Yes, WebRTC and DNS are separate leak vectors that require independent testing. A WebRTC leak test checks whether your browser reveals your real IP address through peer-to-peer connection attempts, while a DNS leak test verifies that your domain name queries route through your VPN’s DNS resolver rather than your ISP’s resolver. You can pass one test and fail the other because they measure different aspects of network behavior. focused browser-session review requires running both tests, ideally from a clean browser state, and confirming that both show only your VPN’s infrastructure with no unexpected public ISP-route candidate in this browser session.

What should I do if I find a WebRTC leak?

First, check your VPN client settings for WebRTC leak protection options and enable them if available. Second, install a browser extension specifically designed to block or limit WebRTC IP exposure, such as WebRTC Leak Prevent for Chrome or configure Firefox’s built-in WebRTC privacy settings through the about:config interface. Third, verify that IPv6 is either fully supported by your VPN or disabled at the operating system level to prevent IPv6 leaks. After making changes, run the WebRTC leak test again to confirm the leak is resolved. If the leak persists despite these steps, consider switching to a VPN service that properly handles WebRTC traffic or using a browser configuration that disables WebRTC entirely.