WebRTC Capability Test
Run a real local peer-to-peer loopback and confirm echoed messages actually came back — no leak testing.
Local loopback only — no STUN or TURN server
Local WebRTC Loopback
Two peers in this tab, 5 echoed messages, iceServers: [] — no STUN or TURN server is contacted
No loopback has been run yet. Running it creates two peer connections in this tab, negotiates locally, and exchanges 5 identified messages so each reply can be matched to the ping that produced it.
How to Test
- •Run the loopback: two peers are created in this tab, negotiate locally, and exchange five identified messages that the second peer echoes back.
- •Check the Echo Replies figure — only unique, correctly matched replies count. Duplicates and unrelated messages are reported separately and never counted.
- •Compare Handshake (time to "connected") with Echo RTT (the median round trip of those replies); they are separate measurements.
Browser Limitations
- •This is a local capability test. It is not a leak test and does not evaluate VPN or DNS behavior.
- •A pass covers this browser only: no microphone or camera is captured, and no request leaves the page — so it is not evidence that a call connects across the internet.
Troubleshooting Tips
- •Strict privacy extensions may block peer connections; disable them to retest.
About the WebRTC Capability Test
The WebRTC Capability Test runs a genuine local loopback: two RTCPeerConnection objects are created inside this tab with iceServers set to an empty list, an offer/answer exchange completes, and the second peer echoes back five individually identified messages. A run counts as a data exchange only when all five replies come back matched to the ping that produced them.
Because the receiving peer must be listening before the channel exists, the echo handler is attached before negotiation begins — and because a reply only means something if it can be tied to a request, each message carries its own identifier and is timed from its own send timestamp. Duplicate echoes and unrelated payloads are counted and ignored rather than rounded up into a success, and the handshake time is reported separately from the median round-trip time.
Tips for a reliable result
- Run the check in the browser you actually make calls in — capability differs between engines and profiles.
- Read the Echo Replies figure first. It counts unique matched echoes only; if it is below five, the step list says why the exchange did not complete.
- Compare Handshake with Echo RTT as separate measurements: a fast handshake with slow round trips, or the reverse, points at different things.
- Re-run after changing VPN, firewall or extension settings, since each can affect whether a peer connection is permitted at all.
Common problems and fixes
The run fails before the connection opens
Privacy-focused extensions and hardened browser builds disable RTCPeerConnection entirely. Disable them for this site and retest; if it still fails, the browser build does not offer WebRTC.
The connection opens but the echo exchange is incomplete
A connected peer with missing echoes points at the data channel rather than the connection: a blocked or throttled channel can open and then drop messages. Retry, and check extensions that modify page content or networking.
ICE candidates were rejected when added
The step list counts rejected candidates instead of hiding them. That normally indicates a mismatch between what was gathered and what the far side expected — often a proxy or an extension rewriting candidates.
The loopback passes but calls still fail
The local path works, so the failure is elsewhere: network filtering, TURN reachability, or the service’s own signalling. Use the failing call app’s network diagnostics next.
FAQ
Is this a WebRTC leak test?
No — by design. It checks local capability only and does not evaluate VPN or DNS behaviour. Use a dedicated leak test if that is your question.
Does a pass mean my calls will work?
It removes one failure cause and no more. A pass shows this browser can build a local peer connection and exchange data; internet calls additionally depend on the network path, relay reachability, and the service itself.
Does it use my microphone or camera?
No. The loopback adds no media tracks and requests no permission. If you want to know whether capture works, use the Microphone Test or Webcam Test, which do open a stream.
Why are duplicate replies not counted?
Because a repeated reply proves less than a matched one: it does not show that this specific ping made the round trip. Ignoring duplicates keeps the figure honest about how many distinct messages completed the exchange.
Does it contact any server?
No. Both peers are created with an empty iceServers list, so no STUN or TURN server is contacted and no address is sent anywhere. Only host candidates are gathered, locally.