What users notice
Games rubber-band, voice becomes robotic, video freezes, streams reduce quality and websites pause while missing data is retransmitted or ignored.
Dropped packets explained
What Is Packet Loss?
Packet loss occurs when some data never reaches its destination. Games may rubber-band, calls can clip or freeze, and pages may pause even when download speed appears normal.
Quick answer
Packet Loss Means Some Data Never Reaches the Destination
Internet traffic is divided into packets. Packet loss is the percentage of those packets that are dropped before arrival. Unlike high latency, which means data is late, packet loss means some data is missing.
What the percentage means
A repeated non-zero result shows delivery is not clean. The next question is whether packets are being lost on Wi-Fi, one device, the router, the access line or a remote route.
Packet loss % = missing packets ÷ packets sent × 100
Interactive classifier
Classify Your Measured Packet Loss
Enter a repeated test result to get a practical severity reading and the first comparison that will provide useful evidence.
Result-led diagnosis
Match the Packet-Loss Pattern to the First Useful Check
This matrix combines the symptom, most likely layer and next comparison so the page does not repeat separate Issue, Validation and Fix sections.
| What the Test Shows | Most Likely Layer | First Useful Check |
|---|---|---|
| Loss appears on Wi-Fi but disappears over Ethernet | Local wireless path. Weak signal, interference, retries, crowded airtime or mesh backhaul is dropping frames before they reach the broadband connection. | Keep Ethernet as the control and follow the Wi-Fi coverage and shared-airtime diagnostic guide in the affected room. |
| Loss remains over Ethernet and affects several devices | Router, modem, ONT, access line or provider route. Wi-Fi and one-device causes have been removed. | Replace the test cable, restart once, record hub or ONT lights and repeat the same test before provider escalation. |
| Only one device loses packets in the same location | Client hardware or software. Adapter drivers, VPNs, security scanning, CPU load or power-saving may be affecting that device. | Test a second device with the same connection and service before changing the router or broadband package. |
| Only one game, call platform or remote service is affected | Destination or route. The wider connection may be healthy while one server region or intermediary path is dropping traffic. | Compare another service and a nearer server region, then use the lag-spike guide if the problem is application-specific. |
| Loss begins only while uploads or downloads are active | Load-sensitive queue or hardware strain. Traffic pressure may be filling buffers or exposing a gateway processing limit. | Pause household transfers, repeat the test and compare with the bufferbloat explainer if loaded latency rises as well. |
| The same wired loss returns at similar evening times | Shared provider capacity or external routing. The pattern changes by time of day rather than room or device. | Repeat identical wired tests on at least two days and retain the time, loss percentage, latency and router status. |
Measurement matrix
Packet Loss Percentage Ranges and Likely Impact
Use repeated results as practical indicators rather than treating one short sample as proof. Real-time games and calls can expose small loss rates before ordinary browsing does.
| Measured Packet Loss | Practical Rating | Likely Real-World Impact | First Useful Check |
|---|---|---|---|
| 0% | Clean result | No packet-loss fault is visible in this sample. Remaining lag is more likely to involve latency, jitter, server distance or loaded responsiveness. | Repeat when the problem occurs, then check loaded latency or jitter rather than replacing equipment. |
| 0.1% to 1% | Low but relevant | Browsing may look normal, while games, voice and live video can develop occasional stutters, clipping or retransmission delay. | Compare the same test over Ethernet and on a second device. |
| Over 1% to 5% | Serious degradation | Rubber-banding, robotic audio, frozen video and slow interactive responses become increasingly likely. | Determine whether the loss is Wi-Fi-only, device-specific, load-sensitive or present across Ethernet and several services. |
| Over 5% | Critical fault | Real-time applications may become unusable and sessions can disconnect or fail to recover cleanly. | Collect repeated Ethernet evidence, check local hardware and line status, then escalate persistent network-wide loss. |
Controlled comparison
Run the Six-Step Packet Loss Check
Keep the test method consistent and change one variable at a time so every comparison removes a possible cause.
- Run a baseline packet-loss test.
Record the percentage, test duration, device, connection type and whether household traffic was quiet or busy. Use the LinkSpeed packet loss test as the repeatable starting point.
- Compare Ethernet with Wi-Fi.
Repeat the same test over a direct cable. If loss disappears, focus on coverage, interference, retries or mesh backhaul rather than the provider line.
- Cross-check another device.
If only one client is poor in the same location, investigate its adapter, drivers, VPN, security software and processing load.
- Compare one service with the wider connection.
Test another game, call platform or server region. A problem isolated to one destination is not proof of a home broadband fault.
- Repeat during quiet, loaded and peak periods.
Pause large transfers, then compare the issue under household load and at the time it normally appears.
- Route the proven pattern to the correct next guide.
Use the result paths below rather than applying Wi-Fi, router and provider changes together.
Use the result
Choose the Next Step That Matches the Proven Loss Pattern
This guide stays focused on measuring and locating missing packets. Detailed configuration and provider-specific actions remain in their specialist pages.
If only Wi-Fi loses packets
Keep Ethernet as the clean control and follow the Wi-Fi coverage and shared-airtime diagnostic guide for placement, interference, channel and mesh checks.
If Ethernet and Wi-Fi both lose packets
Check the test cable, router or ONT status and more than one device. Persistent loss across the whole connection is suitable evidence for provider escalation.
If only one service is affected
Compare another destination and server region. Use the lag-spike diagnostic guide for route and application-specific patterns.
If loss appears only under load
Pause background traffic and compare loaded latency, then read what bufferbloat is when queues or gateway strain appear with the packet drops.
If only one device is affected
Check adapter drivers, VPN routing, security scanning, power-saving and CPU load. A network-wide hardware change is unlikely to correct a single-client fault.
If peak-time wired loss repeats
Keep matching results from at least two days, including time, packet-loss percentage, latency, device and hub status before contacting the provider.
Detailed answers
Packet Loss FAQs
Use these answers to interpret the percentage, separate Wi-Fi from network-wide loss and decide when the evidence supports provider escalation.
What packet loss percentage is acceptable?
Zero percent is the target. Repeated loss below 1 percent can still disrupt games or live calls, while sustained results above 1 percent should be investigated over both Wi-Fi and Ethernet.
Can Wi-Fi cause packet loss?
Yes. Weak signal, interference, retries, crowded airtime and poor mesh or repeater backhaul can drop frames before traffic reaches the broadband line.
Why can a small amount of packet loss affect games and calls?
Games and live calls depend on timely continuous delivery. Missing packets cannot always be retransmitted without adding delay, so even a small repeated loss rate can cause rubber-banding, clipped audio or frozen video.
When should I contact my broadband provider about packet loss?
Contact the provider when repeated loss remains over Ethernet, affects several devices and services, persists after cables and local traffic are checked, or follows a repeatable time-of-day or line-status pattern.