Packet loss test
Because ping can't see what's actually breaking your stream. A venue firewall can pass ping and web traffic perfectly while silently dropping the packets your encoder sends, and you only find out 200 viewers in. This test measures that loss before you go live.
Connection
How many probes never come back within two seconds. HTTP timeouts, not UDP loss: good for spotting a lossy path; the UDP probe is a later tool.
No measurement yet. Forty probes, usually under a minute. No account needed.
Your runs of this tool
Every video stream is chopped into thousands of small packets. Packet loss is the percentage that never arrive, dropped by a congested link, an overloaded switch, weak Wi‑Fi, or a firewall that quietly discards them. The receiver can't rebuild the picture from packets it never got, so the stream stutters, freezes, blocks, or drops.
Live protocols like SRT, RTMP and WebRTC have no time to wait for a re-send. The show is happening now. Even a small amount of loss shows up as macroblocking and frozen frames; a little more and the connection collapses. Loss also compounds with jitter and latency, which is why a link that “speed-tests fine” can still fail on event day.
Ping and most speed tests run over TCP/ICMP. But SRT and WebRTC stream over UDP. Plenty of venue firewalls pass TCP and ICMP flawlessly while dropping or throttling UDP, so ping reads a perfect 0ms, the speed test looks great, and your encoder still can't hold a connection. TCP open + UDP blocked = your problem is right here. That gap is exactly why we built these tools. Pair this with the inbound port reachability check and NAT type test to find it before load-in.
Broadcast tolerances are far tighter than web browsing, so the test grades your loss for you.
The verdict row under the figures grades the loss against the readiness checklist and says what a live stream needs. Read the loss next to the probe count: a few lost probes in a long run is a different room from a burst in a short one.
Loss on a wired link is worth a second run before the show. Loss that comes and goes usually points at Wi-Fi or a busy uplink; loss that stays points at a firewall or a congested path.
Built by broadcast engineers
Built by engineers who run live productions, after a venue firewall silently dropped our UDP mid-show and ping never saw it. Every check measures the real thing, not a marketing number.
What to do next
Loss is what ruins a stream mid-show, and it is the fault a bandwidth number will never show you.
Jitter Test. Measure timing variance between packets. High jitter = unstable streams.
Run Jitter Test11 free tests grouped by the job you arrived with: your connection, the network path, the stream setup, the programme timing.
Browse all tools