Packet Loss Test

What a browser can and cannot measure

Packet loss is the percentage of individual packets that never arrive. Games and calls use UDP, where loss is not retransmitted — the packet is simply gone, and the receiver has to guess. Browsers have no access to UDP and cannot count those losses.

What a browser can do is send requests over a real path and count how many fail or time out. TCP retransmits lost packets, so a request usually still succeeds — but the round-trip time grows and, occasionally, the request fails outright. The figure here is therefore called request loss.

Why this is still useful

• A path with zero failures over 40 probes is very unlikely to be dropping packets routinely.
• Repeatable failures point at a real problem: interference, a saturated uplink, failing cabling or an unstable modem.
• The latency chart shows the retransmission cost: successful requests that took far longer than the median are the visible symptom of lost packets being resent.

For a direct measurement of UDP behaviour you need a native tool — mtr, Pathping on Windows, or the ping utility against a host that answers ICMP. Those are worth running alongside this page if you suspect loss.

Common causes and what to try first

For home connections, wireless interference and over-subscribed uplinks cause most loss. Try, in order: connect over Ethernet, power-cycle modem and router, check cable condition, then test again at a different time of day. If loss persists wired, contact your ISP with the timestamps and the failure counts from this page.