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.

Once the two-browser connection is up, it's useful for more than diagnosis: send files of any size straight from one browser to the other over the encrypted DataChannel — chunked with backpressure, with live progress and speed on both sides, and no server (ours or anyone's) ever holding your data. And instead of copy-pasting the connection blobs between devices, you can show them as QR codes — long offers split into a short auto-cycling frame sequence — and scan them with the built-in camera scanner on browsers that support the BarcodeDetector API.

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.

Is the file transfer really private? How big can files be?

The file goes browser-to-browser over WebRTC's encrypted DataChannel (DTLS) — there is no upload step and no server copy to leak or expire; on a direct connection your data never leaves the path between the two machines (relayed connections pass through your TURN server, still encrypted). Files are sent in 64 KB chunks with backpressure, so size is limited by the receiving browser's memory (the file is assembled there before saving) rather than by the transfer itself — hundreds of megabytes are routine.

How does the QR code exchange work, and why multiple frames?

A compressed offer blob is around 1,900 characters — it technically fits in one QR code, but codes that dense scan poorly from a screen. So longer blobs are shown as a short sequence of easier codes that cycle automatically with a part indicator; the scanner collects frames in any order and reassembles the blob. Scanning uses the browser's native BarcodeDetector API (Chrome and Edge) — where it's missing, scan with your phone's camera app or fall back to copy-paste, which always works.