Everything you send or receive online is split into small pieces called packets. Packet loss is the share of those packets that never reach their destination. It is usually shown as a percentage: 1% packet loss means one packet in every hundred went missing.

What packet loss does to different apps

The internet has two main ways of carrying data, and they react to loss very differently.

  • Reliable traffic (TCP): web pages, downloads, streaming video and email. When a packet is lost, it is detected and sent again, so nothing goes missing. Each resend still costs time, and TCP also slows down to avoid making congestion worse. So loss mainly appears as lower speed and slower page loads, not as broken data.
  • Real-time traffic (usually UDP): voice calls, video calls, online games and cloud gaming. There is no time to resend a packet that is already late, so the app simply goes without it. Loss appears as robotic or choppy audio, frozen video and players who teleport.

That is why a connection can stream Netflix perfectly yet still break up on calls.

How much loss is acceptable?

On a healthy wired connection, packet loss should be 0% or very close to it most of the time. Rules of thumb:

Packet loss Effect
0% Ideal.
Under 1% Usually unnoticeable, though competitive gamers may feel it.
1–2.5% Noticeable in calls and games.
Over 2.5% Calls and games degrade clearly; downloads slow down.

A single test can catch a brief burst of loss or miss it entirely. If you suspect a problem, test several times at different times of day.

Common causes

  1. Weak or congested Wi-Fi. Wi-Fi resends many lost packets on its own, but interference can still cause loss and delay.
  2. Damaged or poor-quality cables between your router, modem and wall socket.
  3. Congestion. When a link is overloaded, routers drop packets on purpose to signal “slow down”. Some loss under heavy load is normal TCP behaviour. Persistent loss when the line is quiet is not.
  4. Faulty equipment. An overheating router, failing modem or noisy line, such as a corroded DSL connection.
  5. Problems further away, in your provider’s network or on the route to a particular service.

How SpeedCheckWeb measures packet loss

Browsers cannot send raw network packets, so a normal web request can never show packet loss, because lost data is silently resent. To measure loss honestly, SpeedCheckWeb opens a WebRTC data channel set up like UDP (unordered, with no resends), relays it through a TURN server, sends a numbered sequence of packets and counts how many come back.

This needs a relay service. When that service is not available for your test, the result shows “Not measured” rather than 0%, because 0% would be a claim we could not back up. The methodology page explains the method and its limits. For example, the result describes the path to the relay server, not to every website.

How to reduce packet loss

  1. Test with a cable. If loss disappears, the problem is Wi-Fi: move closer, change the channel or band, or add a mesh access point.
  2. Check cables and connectors, and try a different router port.
  3. Restart your modem and router, and check for firmware updates.
  4. Test at quiet and busy times. Loss that only appears in the evening points to congestion in your provider’s network.
  5. Contact your provider with your results if loss persists on a wired connection. Note the times, and include results from more than one test.

In short: packet loss is data that disappears on the way. Downloads hide it by resending, but calls and games suffer, so even 1–2% matters.

Sources

  1. RFC 7680 – A One-Way Loss Metric for IP Performance Metrics (IPPM)
  2. RFC 9293 – Transmission Control Protocol (TCP)

Figures from third parties can change; we review guides regularly. See our editorial policy.

Run a speed test