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.
Packet loss test
Fires 40 probes and measures how many never come back. Runs in your browser — no signup.
Every video stream is chopped into thousands of small packets. Packet lossis 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 1–2% loss shows up as macroblocking and audio glitches; more than that and the connection collapses. Loss also compounds with jitterand 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 port checker and NAT type test to find it before load-in.
Broadcast tolerances are far tighter than web browsing. Here's what your number means for a live stream:
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.