ByteScope

WebRTC Connection Tester

Not just "does WebRTC work" — see why it doesn't, and what to do about it.

Your files never leave your browser — all processing is local.

Gathering ICE candidates…

ICE candidates

Asking 2 STUN servers… (up to 5 s)

Network checks

Public IPWaiting for STUN…

IPv6Waiting for candidates…

NAT typeComparing STUN mappings…

UDPWaiting for STUN…

Loopback connection test

ConnectionWaiting for candidate gathering…

Ping RTTMeasuring DataChannel round trips…

ThroughputWaiting for the connection…

Honest label: this measures your machine's WebRTC stack (loopback baseline — SCTP, DTLS and the browser's send path), not your internet speed. A real speed test needs remote test servers, which this site doesn't have.

Report

IPs stay masked unless revealed above.

WebRTC local diagnosis — bytescope.dev/webrtc-test

Candidates: (gathering…)

About this tool

The local diagnosis runs the moment you open the page: ICE candidates are gathered from multiple public STUN servers and classified — host, server-reflexive, relay — each with a one-line explanation of what its presence means. By comparing the public ports mapped by two different STUN servers, the tool detects your NAT type: cone NATs are P2P-friendly, while a symmetric NAT means direct connections will often fail and you need TURN — the single most useful sentence in WebRTC debugging, stated plainly. No server-reflexive candidates at all means your network blocks UDP (common on corporate networks), and the diagnosis says so. A loopback test then actually connects two peer connections inside the page and measures real DataChannel throughput and latency.

The TURN validator is the feature WebRTC developers keep looking for: enter your turn:/turns: URL and credentials, and the tool forces a relay-only connection to prove whether your TURN server actually allocates — with UDP, TCP and TLS transports tested separately and failures diagnosed (bad credentials vs firewall vs DNS). A relay-forced throughput test measures how much bandwidth your TURN server can actually deliver — the number that decides whether relayed video looks good, and one almost no tool measures.

Everything runs in your browser. The connection tests talk only to the STUN/TURN servers you choose; nothing about your network is sent to us.

Frequently asked questions

What do host / srflx / relay candidates mean?
They're the addresses WebRTC can try: host = your local interface addresses (mDNS-obscured in modern browsers), srflx = your public address as seen by a STUN server (its presence means your NAT can be traversed), relay = an address on a TURN server that forwards traffic when direct paths fail. A healthy setup shows host + srflx; relay appears only when you configure TURN.
What is a symmetric NAT and why does it break P2P?
A symmetric NAT assigns a different public port for every destination you talk to, so the port a STUN server observed is useless to the actual peer — hole punching fails. The tool detects this by comparing mappings from two STUN servers: different ports → symmetric. Two symmetric-NAT peers essentially always need a TURN relay.
Why does my TURN server return no relay candidates?
The validator separates the causes: a 401/credential failure (wrong username/password or an expired time-limited credential), an allocation failure (server unreachable — firewall blocking the port, or wrong port/transport), or DNS failure on the hostname. Test UDP, TCP and TLS separately — corporate networks often allow only turns: on 443.
Is this a speed test of my internet connection?
No — and the page says so honestly. The throughput numbers measure the WebRTC path: your machine's WebRTC stack (loopback), your TURN server's capacity (relay-forced), or a specific peer-to-peer link. A general download/upload speed test needs dedicated test servers, which a serverless site can't honestly provide.
What does the two-browser test do?
It builds a real WebRTC connection between two devices without any signaling server: one side creates an offer as a compressed text blob, you send it over any messenger, the other side pastes it back an answer, and the connection comes up — then live stats show whether you're direct or relayed, round-trip time, bitrate and packet loss. It's both a demo of how WebRTC signaling works and a genuine connectivity test between two real networks.