Why packet loss needs its own test
Everything you send over the internet is split into small packets. When some of them go missing, web pages still load and downloads still finish, because TCP-based applications simply ask for the missing piece again. Games, voice chat and video calls cannot afford to wait, so they move on to the next packet. The result is an opponent teleporting, words getting swallowed or a frozen video frame. A packet loss test makes visible what a regular speed test hides.
How the measurement works
The test sets up a WebRTC data channel between your browser and the test server you select. The channel is configured for unordered delivery with zero retransmissions (maxRetransmits: 0), so a lost packet is never resent. That is very close to how UDP behaves, which is what most games and VoIP applications use. Because the connection is relayed through the server's own TURN service, it also works behind strict NAT and on many corporate networks.
Every packet carries a sequence number. The server echoes each one immediately and, at the end of the test, sends back the list of IDs it received. Your browser compares that list with what it sent and what came back:
- Packets that never reached the server count as upload loss.
- Packets that reached the server but never made it back count as download loss.
- Packets that returned, but too late to be useful, are flagged as late.
- Out-of-order and duplicate packets are tracked in separate counters.
Choosing the right settings
Packet size, rate and duration decide what kind of traffic the test imitates. The defaults suit most people, but if you are chasing a specific problem, try these profiles:
- Gaming: 64–128 bytes, 60–100 packets per second, 1–2 minutes.
- Voice calls: 160–200 bytes, 50 packets per second, 1 minute.
- Large packets: 1000–1200 bytes, 20–50 packets per second.
- Long-term monitoring: low rate, 5 minutes.
If loss rises with large packets but not with small ones, look at MTU settings or a capacity limit on the line. If short tests come out clean but long ones show occasional bursts of loss, the problem is likely intermittent: Wi-Fi interference, an overheating router or evening congestion.
What directional loss tells you
Knowing which direction packets are lost in is the fastest way to work out who needs to fix the problem. Issues inside your home, such as a weak Wi-Fi signal or a cloud backup saturating your upstream, usually produce upload loss. Download loss more often points to congestion in your ISP's network, line quality on DSL or cable connections, or a congested hop on the route to the server. If you see loss in both directions, check the link between your device and the router first, then the link between the router and the outside line.
Jitter, MOS and the connection grade
Packet loss should never be judged on its own. Jitter, the mean absolute difference between consecutive round-trip times, shows how erratic your latency is. High jitter forces applications to buffer, and packets that arrive after the buffer has played out are effectively lost. The MOS score combines latency, jitter and loss using a simplified ITU-T G.107 E-model to estimate how a voice call would sound: 4 or above is good, below 3.5 means clearly degraded quality. The A–F grade and the stability percentage bring all of this together in one summary.
Narrowing down the cause
- Run the test over Wi-Fi, then over a cable on the same device. A big difference means your wireless network is the culprit.
- Repeat with a different server location. If loss only appears on one server, the issue is on that route.
- Test in the morning and again in the evening. Loss that only appears at peak times points to network capacity.
- Download the results as CSV or JSON and attach them to a support ticket if needed.
For a quick overall check, use the ping test on our home page. If a particular game stutters, compare region latency on pages such as the Valorant ping test.