WebRTC Test - TestMu AI (Formerly LambdaTest)

What is the WebRTC Test?

WebRTC (Web Real-Time Communication) is a browser API that enables peer-to-peer video calls, voice calls, and data sharing directly in the browser — without plugins. This WebRTC test tool runs entirely in your browser and checks several aspects at once: whether your browser supports the WebRTC APIs, which IP addresses WebRTC exposes about you (including potential leaks around VPNs), whether common STUN and TURN servers are reachable from your network, what ICE candidates your browser generates, which video and audio codecs are available, and whether your camera and microphone are accessible for real-time communication.

How to Use the WebRTC Test Tool

• Load the page: The tool automatically begins all non-camera tests as soon as the page loads. No input is required.
• Read the summary card: The top card shows whether WebRTC is supported and whether a public IP leak was detected by comparing your reported IP against the IP revealed via WebRTC.
• Review the STUN connectivity table: Each row shows whether a default STUN server is reachable, how long it took to get a server-reflexive candidate, and what public IP it returned. Add your own STUN server in the input at the bottom of the panel and click Probe.
• Test TURN (optional): Enter your TURN server URL, username, and credential and click Test TURN. The default free endpoint is pre-filled for convenience.
• Start the camera and mic test (opt-in): Click Start Camera & Mic Test to request permission. Your browser will show a permission prompt. Once granted, you will see a live preview, resolution, and an audio level meter. Click Stop Test to release the devices.
• Download or copy the report: Use the Diagnostic Report panel to copy or save all collected data as JSON for sharing with a network engineer or support team.

How WebRTC Reveals Your IP Address

When your browser creates an RTCPeerConnection, it gathers ICE (Interactive Connectivity Establishment) candidates to describe how another peer can reach it. This process queries STUN servers to discover your public IP address and also enumerates your device's local network interfaces.

• STUN servers return a server-reflexive (srflx) candidate that contains your true public IP — the one your router presents to the internet.
• If you are using a VPN, your VPN is supposed to redirect all traffic through an encrypted tunnel. However, some browsers will still discover your real IP via STUN queries, bypassing the VPN tunnel. This is a WebRTC IP leak.
• Chrome since version 48 obfuscates local IP addresses using mDNS hostnames ending in .local, so the host candidate appears as a random UUID rather than your actual private address.
• Firefox and Safari expose the real local IP in the host candidates by default, though Firefox allows disabling WebRTC entirely.

Understanding ICE Candidates: host, srflx, prflx, relay

host

A host candidate is the device's local network address — what the operating system returns for the active network interface. On Chrome, these are replaced with mDNS-protected hashes to prevent fingerprinting.

srflx (server-reflexive)

A srflx candidate is the public IP and port seen by the STUN server. It is the address your NAT router exposes to the internet. This is the value that causes a WebRTC leak when it differs from your VPN exit IP.

prflx (peer-reflexive)

A prflx candidate is discovered dynamically during the connectivity check phase. It represents the public address observed by the remote peer, and it is generated without a STUN server. Prflx candidates only appear once a live peer connection is being established.

relay

A relay candidate routes media through a TURN server. It is the fallback when direct peer-to-peer or STUN-discovered paths do not work — typically because your network is behind a symmetric NAT or a very restrictive firewall. Relay connections add latency because all media passes through the server.

What STUN and TURN Servers Do

Both server types solve the problem of two browsers communicating across NAT (Network Address Translation) boundaries, but they do so differently.

• STUN (Session Traversal Utilities for NAT): A lightweight server that tells your browser its public-facing IP and port. It does not relay media — it just provides discovery. STUN is used when both peers can reach each other directly after learning their public addresses.
• TURN (Traversal Using Relays around NAT): A media relay server that actively forwards data packets between peers. Required when STUN fails — for example, behind symmetric NAT or corporate firewalls that block UDP entirely. TURN runs over UDP, TCP, and TLS.
• When is TURN required? When both STUN and direct host connections fail — typically in enterprise networks, hotel Wi-Fi, or mobile data on certain carriers.
• Latency impact: STUN-only (direct) calls typically add 0–20 ms. TURN-relayed calls can add 50–200+ ms depending on server location.

Codec Support: VP8, VP9, H264, AV1, Opus Explained

• VP8: The original WebRTC video codec. Open-source, royalty-free, supported in all major browsers. Used by older versions of Google Meet and many WebRTC apps as a fallback baseline.
• VP9: Successor to VP8 with roughly 50% better compression at the same quality. Used by Google Meet for better bandwidth efficiency. Available in Chrome, Firefox, and Edge.
• H264 (AVC): The most widely deployed video codec. Required by Zoom, Microsoft Teams, and Safari. Hardware-accelerated on most devices, making it efficient even on mobile. Encumbered by patents but widely licensed.
• AV1: Next-generation open codec from the Alliance for Open Media. Significantly better compression than VP9 and H264. Starting to appear in Chrome and Firefox. Not yet universally supported.
• Opus: The standard audio codec for WebRTC. Highly adaptive — adjusts between 6 kbps and 510 kbps, covers both speech (SILK) and music (CELT). Used by Google Meet, Zoom, Microsoft Teams, and Discord.
• G.722, PCMU, PCMA: Legacy audio codecs included for backwards compatibility with telephony systems. Lower quality and efficiency than Opus.

How to Disable WebRTC in Chrome, Firefox, Edge, Safari, Brave, and Opera

Chrome and Edge

Neither Chrome nor Edge provides a native setting to disable WebRTC. The recommended approach is to install a browser extension such as "WebRTC Leak Prevent" or "uBlock Origin" (with WebRTC leak prevention enabled). These extensions can force Chrome to use only the VPN interface for ICE candidate discovery. Be aware that fully disabling WebRTC will break video-conferencing tools like Google Meet.

Firefox

• Type about:config in the address bar and press Enter.
• Accept the warning prompt.
• Search for media.peerconnection.enabled.
• Double-click to toggle the value to false.

Safari

• Enable the Develop menu: Safari menu → Settings → Advanced → check "Show Develop menu in menu bar".
• Click Develop in the menu bar → Experimental Features.
• Toggle off "WebRTC mDNS ICE candidates" or related WebRTC options.

Brave

Brave has built-in WebRTC protection. Go to the Shields panel (the lion icon) for any site and set Fingerprinting protection to "Strict". You can also go to brave://settings/privacy and set "WebRTC IP handling policy" to "Disable non-proxied UDP" to prevent IP leaks without fully disabling WebRTC.

Opera

Opera is Chromium-based and, like Chrome, has no native WebRTC kill switch. Use a browser extension from the Opera add-ons store that provides WebRTC IP leak prevention.

When You Should Care About a WebRTC Leak

• You are using a VPN to hide your real location or IP from websites and services.
• You are a journalist, security researcher, or activist who needs strict IP anonymity.
• You are testing whether a VPN product actually protects against WebRTC leaks before recommending it.
• Your organization requires that no internal IP information is visible to third-party web applications.
• You noticed a discrepancy between what a site "sees" as your IP and what your VPN dashboard reports as your exit IP.
• You use a privacy-focused browser profile and want to confirm WebRTC leak prevention is working.

Test WebRTC Apps at Scale with TestMu AI Agent Testing

A browser-side check confirms your own setup, but real-time video, voice, and data apps still have to work for every user on every browser, network, and device. TestMu AI (formerly LambdaTest) is an AI-native testing cloud where autonomous test agents validate WebRTC flows across 10,000+ real devices and 3000+ browsers, so you catch codec, NAT, and connectivity issues before your users do.

• Agentic test authoring: Describe a WebRTC call scenario in plain English and a TestMu AI agent turns it into an executable, self-maintaining test with no boilerplate scripting.
• Real device and browser coverage: Run the same call journey across 10,000+ real devices and 3000+ browsers to verify camera, microphone, and codec behavior on hardware your users actually own.
• Network condition testing: Replay calls under throttled bandwidth, packet loss, and restrictive NAT or firewall setups to confirm when STUN succeeds and TURN relay takes over.
• Self-healing automation: When UI elements or selectors change, the test agent adapts on its own and keeps your WebRTC regression suite green without manual upkeep.
• Faster debugging: Agents surface failing steps with video, network, and console logs, so you can pinpoint a dropped ICE candidate or a missing codec in minutes.

Ready to move from a single-browser spot check to full coverage? Explore TestMu AI agent testing and put your real-time communication app through its paces.

Frequently Asked Questions (FAQs)

What is a WebRTC test?

A WebRTC test checks whether your browser supports WebRTC, what IP addresses WebRTC exposes about you, whether STUN and TURN servers are reachable, what video and audio codecs your browser supports, and whether your camera and microphone work for real-time communication.

What does this tool check?

It checks WebRTC API support, your public and local IPs as seen via WebRTC, STUN/TURN server connectivity and latency, ICE candidate gathering, available video and audio codecs, and your camera and microphone (opt-in).

Does this tool send my IP address to a server?

No. All tests run in your browser. The only network call is a public IP lookup via api.ipify.org, used to compare your reported IP with the one WebRTC reveals. Nothing is logged on our side.

What's the difference between a local IP and a public IP in WebRTC?

A local IP (host candidate) is the address assigned to your device on your private network (e.g. 192.168.x.x). A public IP (server-reflexive / srflx candidate) is the address your router presents to the internet, discovered via a STUN server.

I'm on a VPN — why is my real IP still showing?

Some browsers leak your true public IP through WebRTC's srflx candidates even when a VPN is active. If the WebRTC public IP shown above differs from your VPN's exit IP, you have a WebRTC leak.

What is a STUN server, and why does WebRTC need it?

STUN (Session Traversal Utilities for NAT) servers help your browser discover its public IP and port so two peers behind NATs can connect directly. WebRTC needs this for peer-to-peer media without a relay.

What is a TURN server, and when is it used?

TURN (Traversal Using Relays around NAT) servers relay media when a direct peer connection is impossible (symmetric NATs, restrictive firewalls). If only relay candidates work for you, expect higher latency.

What are host, srflx, and relay ICE candidates?

Host candidates are your device's local network addresses. Srflx (server-reflexive) candidates are your public address as seen by a STUN server. Relay candidates route through a TURN server. Prflx (peer-reflexive) candidates are discovered during connectivity checks.

How can I disable WebRTC in my browser?

In Firefox, set media.peerconnection.enabled to false in about:config. In Brave, use Shields and Fingerprinting protection. In Safari, disable WebRTC in Develop and Experimental Features. Chrome and Edge have no native toggle; use an extension like "WebRTC Leak Prevent".

Why doesn't WebRTC work on my network?

Restrictive firewalls or symmetric NATs can block STUN/TURN traffic. If the STUN test fails for all servers and TURN also fails, your network is blocking the UDP/TCP ports WebRTC needs.

Which codecs does my browser support, and does that affect video calls?

Modern browsers support VP8, VP9, H264, sometimes AV1, plus Opus for audio. Compatibility matters: Zoom prefers H264, Google Meet uses VP8/VP9, Microsoft Teams uses H264. Missing a required codec can degrade or break a call.

Is this WebRTC test safe to run on a work computer?

Yes. The tool runs entirely in your browser and only reads diagnostic information. The camera and microphone test is opt-in and only starts after you click "Start Camera & Mic Test". No data leaves your device beyond the public IP lookup.