Packet Loss: What It Is, What Causes It, and How to Fix It

The Problem That Hides Behind a Fast Connection

A speed test tells you your connection can move a lot of data. It says nothing about whether every piece of that data actually arrives. Those are two different questions, and packet loss lives entirely inside the second one.

This is why packet loss is so confusing to run into. Your download speed looks fine. Web pages load. Then a voice call turns robotic. Your character in a game snaps back through a doorway you already walked through. The video freezes while the audio keeps talking. And a request to a server just quietly fails and has to be retried. Nothing about the big bandwidth number predicted any of that, because bandwidth measures capacity while packet loss measures delivery. Think of a wide road: it does not guarantee that every car reaches the other end.

Maybe you landed here because something keeps stuttering, dropping, or failing on your connection. A speed test cannot explain it. This guide will help you reason about it. We will cover what packet loss actually is, why a fast connection can still suffer from it, and how much loss genuinely matters. Most usefully, we will work out how to tell where your own loss is coming from, before you spend money or time on the wrong fix.

What Packet Loss Actually Is

A network breaks everything you send or receive into small units called packets. A video call, a game update, a web page, a file download: none of them travel as one continuous stream. Each one breaks into many packets. Every packet carries a little header. It describes where the packet came from, where it is going, and how it fits back together. Routers and switches along the way read those headers and pass each packet toward its destination. There, the pieces reassemble into the original data.

Packet loss is what happens when some of those packets never arrive. They leave your device, or leave a server heading toward you, and somewhere along the path they are dropped. We measure loss as a percentage of packets that failed against the total sent. Send 100 packets, have 2 go missing, and you have 2 percent packet loss over that sample.

Two details matter more than the basic definition, and most explanations skip them.

Loss Has a Direction

Packets flow both ways, and loss can happen in either direction independently. Upstream loss affects the data leaving you, which is what other people receive. Downstream loss affects the data arriving at you. Picture a video call where others say you sound choppy but you hear them clearly. That points at upstream loss on your side. The reverse points downstream. This one distinction rules out half the possible causes the moment you notice which direction is affected.

Loss Has a Location

A network can drop a packet at many points between you and whatever you are connecting to. It might die inside your home, at your Wi-Fi, or at your router. It might die on the line to your provider, deep in the provider’s network, out on the wider Internet, or at the destination server itself. “I have packet loss” is only a symptom. Where the packets are dying is the actual problem, and the two are not the same thing.

Why a Fast Connection Can Still Lose Packets

Bandwidth and reliable delivery are separate properties. It is completely normal for one to be excellent while the other is poor. You can have a gigabit plan and still experience rubber-banding, voice breakup, frozen video, buffering, laggy interactions, and failed requests. Your bandwidth does not govern any of those symptoms. What governs them is whether packets arrive, when they arrive, and whether they arrive consistently.

A speed test also flatters an unreliable connection by design. It runs for a few seconds, pushes a large flow of data to measure throughput, and reports a peak. Packet loss is often intermittent, arriving in short bursts tied to interference, congestion, or a struggling piece of hardware. A five-second test can easily land in a clean window and miss the loss entirely. It can also push so hard that it masks the small, timing-sensitive failures that actually ruin a call. The number it produces is real. But it answers “how much data can this connection move right now,” not “does this connection deliver reliably minute after minute.”

That gap is why packet loss deserves watching over time rather than a single instant. We will return to it when it comes to testing.

Packet Loss Is Not Latency, and It Is Not Jitter

Packet loss, latency, and jitter get lumped together because they often appear together and produce overlapping symptoms. They describe genuinely different things, and telling them apart is what lets you diagnose accurately instead of guessing.

Latency, usually reported as ping, is how long a packet takes to make a round trip. It is a measure of delay. A packet can take a long time and still arrive perfectly intact, which is high latency without any loss. If your core complaint is that everything feels a beat behind rather than broken, latency is the more likely culprit. Our guide to high ping and how to fix it covers that side in depth.

Jitter is the variation in latency from one packet to the next. If packets arrive spaced 20 ms, then 60 ms, then 15 ms apart, the delivery is uneven even when the average looks healthy. Real-time audio and video depend on a steady rhythm, so jitter produces stutter and distortion on its own, no loss required.

Packet loss is neither of these. It is data that does not arrive at all. A connection can have low latency, low jitter, and still drop packets. That combination feels distinct: brief hard failures rather than general sluggishness. The three can and often do occur together, and a connection in real trouble usually shows all three. But they measure separate problems. Treating them as one blurred idea of “lag” is exactly what makes network issues so hard to fix.

Why Lost Packets Hit Some Apps Harder Than Others

The same one percent of packet loss can be invisible in one application and ruinous in another. The reason comes down to how the application handles missing data. That mostly depends on which transport protocol it uses.

TCP Traffic: The Data Always Arrives, Just Slower

Most everyday traffic runs over TCP, including web pages, file downloads, and email. TCP guarantees delivery. When a packet goes missing, TCP notices and resends it, so the data always arrives complete. The cost of that guarantee is time. The connection has to notice the gap and resend the packet. And because TCP delivers data in order, everything queued behind the missing packet waits for that piece to arrive. This effect has a name: head-of-line blocking. On a connection with meaningful loss, the result rarely looks broken. It shows up as a download that crawls, a page that stalls halfway, or a stream that buffers. The data all shows up eventually. It is just slow to assemble.

UDP Traffic: A Late Packet Is Worse Than a Lost One

Real-time applications behave differently, because for them a late packet is often worse than a missing one. Online games, most voice and video calls, and live streaming tend to run over UDP, which does not retransmit. UDP sends each packet and moves on, leaving recovery to the application. That is a deliberate choice. In a fast game or a live call, a packet that arrives 300 ms late is useless, because the moment it described has already passed. Dropping it and moving to the next update keeps things current.

So these apps add their own tricks on top of UDP. They send the latest full state, predict movement on the client, or add redundant data so a lost packet can be rebuilt. Those techniques hide small amounts of loss remarkably well, but they have limits. Push the loss high enough and you see it directly. That is the rubber-banding, the warping, the syllables that drop out of a call, the video that smears and freezes.

This is why packet loss bites hardest in gaming, voice, and video. It is also why someone can insist their Internet is “fast” while one real-time app is unusable. The bandwidth is fine. The loss is simply landing on the one kind of traffic that cannot wait for a retransmission.

How Packet Loss Is Measured, and What the Percentages Mean

Packet loss is a percentage over a sample: the share of packets that failed to arrive out of all that went out. The tricky part is that the percentage alone does not tell the whole story. Reading it as a hard grade is a common mistake.

Here is a practical sense of the ranges, with the important caveat that these are general guidance rather than fixed scientific thresholds:

• 0 percent is the ideal, and healthy connections spend most of their time here, especially on wired links to nearby destinations.
• Under 1 percent is generally acceptable and often unavoidable across a long Internet path. Most applications absorb this without you noticing.
• 1 to 2 percent is where real-time applications start to suffer. Web browsing and downloads may still feel fine thanks to TCP, but games and calls can show audible or visible glitches.
• 2 to 5 percent is disruptive for anything interactive. Calls break up, games become frustrating, and even TCP traffic slows noticeably as retransmissions pile up.
• 5 percent and above is a serious problem that affects most uses of the connection, not just the sensitive ones.
• 10 percent and above usually indicates something genuinely wrong, such as failing hardware, a bad cable, saturated capacity, or an unhealthy link, and it warrants direct investigation.

Why the Percentage Alone Can Mislead

The caveat matters because context changes everything. A short, intense burst of loss can be far more destructive than the same overall percentage spread evenly. Losing five packets scattered across a minute is minor. Losing five packets in a single clump can drop a call or desync a game, even though both might report a similar average. Duration matters too. A brief spike during a Wi-Fi hiccup is very different from steady loss that never clears. Protocol matters as well. Two percent loss might be a non-event for a TCP download and a dealbreaker for a UDP voice call at the very same moment. A single loss figure, with no sense of how it is spread over time, is only half the picture.

What Causes Packet Loss

Packets get dropped for a handful of recurring reasons. More than one can be in play at once, which is part of why diagnosis takes a little structure.

Congestion

Network congestion is the most common cause. Every link and every router has a finite capacity. When more traffic arrives than a point on the path can handle, the excess has to go somewhere. Once the queues fill, packets get discarded. This is why loss often appears at peak evening hours. It also shows up during a large upload or download that saturates your line. Congestion on an overloaded segment of a provider’s network does the same. Congestion loss tracks load. It worsens when the network is busy and clears when things quiet down.

Wi-Fi interference and weak signal are the dominant cause of loss inside homes. Wireless is a shared, noisy medium, and it gets its own section below.

Local Hardware and Cabling

Overloaded or failing network hardware drops packets when a router, switch, or modem cannot keep up or is starting to fail. An older router running hot and short on headroom will shed packets under load. Failing hardware can drop them even when the network is quiet, which is a useful tell.

Damaged or poor cabling causes loss that people rarely suspect, because a cable either looks fine or sits out of sight. A bent, pinched, cheap, or aging Ethernet cable can corrupt or drop packets. So can a corroded connector or a damaged coaxial or fiber line. Corrupted packets fail their integrity check on arrival, so the receiver discards them, which registers as loss.

Modem or ONT problems sit at the boundary between your home and your provider. When the device that terminates your connection is failing, misconfigured, or seeing a poor signal, loss shows up on everything behind it.

Beyond Your Home

ISP and upstream network problems happen beyond your equipment, inside your provider’s network or at the connections between networks. A congested or misconfigured link at that level produces loss you cannot fix from home. You can, however, gather the evidence that proves it.

Routing and peering issues occur out on the wider Internet. Traffic crosses multiple networks to reach a destination. Two of those networks might meet at a congested handoff, or a route might send your packets down an overloaded path. Either way, loss appears in the middle of the journey even though both endpoints are healthy.

Server-side or destination problems are the cause people forget. If the service you are reaching is overloaded, rate-limiting, or having its own trouble, you will see loss to it no matter how perfect your connection is. Loss that shows up with one specific game, site, or service, and nowhere else, frequently points here.

Software on the Path

VPNs add a hop and a server to your route. A well-run endpoint close to you may add almost nothing. A distant, overloaded, or unreliable one can introduce loss and latency that were not there before. If loss appeared when you turned a VPN on, test with it off.

Firewalls and security software occasionally drop legitimate packets, through aggressive filtering, a misconfiguration, or software that inspects traffic on the device. This is less common than the causes above, but worth checking when loss follows one machine rather than the whole network.

Why Wi-Fi Is a Special Case

Wired networks move electrical or optical signals along a controlled path. Wi-Fi broadcasts through open air that it shares with everything else nearby, and that difference introduces a whole set of ways for packets to go missing.

Wireless signals weaken with distance and with every wall, floor, appliance, and body between your device and the router. A weak signal means more corrupted frames, more retransmissions at the wireless layer, and eventually dropped packets. The 2.4 GHz band reaches farther but is crowded with neighboring networks, cordless phones, microwaves, and countless smart-home gadgets, so interference is common. The 5 GHz and 6 GHz bands are cleaner and faster but do not travel as far or punch through walls as well. A device parked at the edge of usable range, or competing with a congested channel, will drop packets. It looks exactly like a network problem, but it is really a wireless one.

This is also why Wi-Fi loss is so often intermittent. A microwave runs for two minutes, a neighbor’s network gets busy, someone walks between you and the router, and loss spikes briefly then vanishes. That pattern is a strong hint that the problem is your wireless environment rather than anything upstream. It leads directly to the single most useful diagnostic test you can run.

Can Packet Loss Happen on Ethernet?

Yes, and when it does it usually means something more concrete than a Wi-Fi problem, which is what makes wired testing so valuable. Ethernet removes the entire category of wireless variables, so loss that persists on a cable points to a smaller and more actionable set of causes: a bad or damaged Ethernet cable, a failing port on your router or the device, a struggling or overheating router, a modem or ONT problem, or something upstream at your provider.

A faulty cable is the first thing to rule out because it is cheap to test and more common than people expect. Swap it for a known-good one and retest. If wired loss disappears, the cable was the culprit. If it persists across different cables and ports, the problem lives in the hardware or beyond your home, and you have already narrowed the search considerably.

Finding Where Your Packet Loss Is Coming From

The generic advice to “restart your router” is not diagnosis. It is a guess that occasionally works and teaches you nothing when it does not. A far better approach is to isolate the problem by testing each part of the connection in turn. Work from the parts you control outward to the parts you do not. Every layer you clear removes a set of possible causes.

A sensible progression looks like this:

Application or Internet problem → Test stability over time → Compare Wi-Fi and Ethernet → Check the local network → Check the router and modem → Check the ISP and upstream path → Check the destination or service

Start by confirming it is really loss, and over time

Before chasing hardware, confirm that packet loss is actually present and get a sense of how it behaves. A single instantaneous measurement is nearly useless here, because intermittent loss hides between samples. You want to observe the connection over a stretch of time, watching for loss alongside latency and jitter. That shows whether it is steady, bursty, tied to a time of day, or triggered by activity. This is exactly the kind of picture a stability test produces, and it is the right first move. Run a StabilityTest and let it watch the connection rather than judging it from one quick number.

Compare Wi-Fi against Ethernet

This is the highest-value test in the whole process, because it splits the problem cleanly in two. Run your check over Wi-Fi, then connect the same device by Ethernet and run it again under similar conditions. If the loss vanishes on the cable, your problem is wireless: signal, interference, or range, and the fixes live in that domain. If the loss persists on Ethernet, you have ruled out Wi-Fi entirely. You can stop troubleshooting your wireless setup, which is where most people waste their time.

Check whether it is one device or all of them

When several devices lose packets, a shared cause sits at the router or beyond. A single affected device points at that machine instead: its network adapter, its drivers, its security software, or its cable. This test costs nothing and eliminates an entire branch of possibilities.

Check whether it is one destination or many

Loss that appears everywhere points at your own network or your provider. Loss that appears only with one particular game, site, or service, while everything else is clean, points at that destination or the route to it. It is not your connection. Testing against a couple of different, reliable destinations quickly tells you which world you are in.

Look at where along the path it happens

Readers comfortable going deeper have more tools: ping, traceroute, pathping on Windows, and MTR on macOS and Linux. Each shows behavior hop by hop along the route to a destination. Used well, they help localize a problem. Used naively, they mislead, because they are widely misread, so it is worth knowing what they can and cannot prove.

The critical caveat is that routers treat diagnostic replies as a low priority. Generating the responses these tools rely on falls to a router’s control plane. That work is often rate-limited and sometimes disabled entirely, even while the router forwards ordinary traffic perfectly well. The practical consequence is simple. A single middle hop can show loss or a latency spike that does not continue downstream. That is almost always a measurement artifact, not a real problem. Real, forwarding-level loss shows up as loss that persists from a given hop all the way through to the destination, and the destination itself struggles too. A clean destination with a noisy middle hop is not your smoking gun. This single misunderstanding accounts for a large share of incorrect conclusions people draw from traceroute output, so read the end of the path, not the middle.

How to Fix Packet Loss

Once you know roughly where the loss lives, the fix follows from the location. Trying fixes in the right order beats trying all of them at random.

When the Loss Is Wireless

Address the wireless environment directly. Move closer to the router, or reduce the obstacles between you and it. Reposition the router to a central, open spot rather than a cabinet, a corner, or the floor. Switch to a less congested channel, or to the 5 GHz or 6 GHz band if your device and range allow it. For a device far from the router, a wired connection, a mesh node, or a well-placed access point solves what channel tweaks cannot. And for the devices that matter most, such as a gaming console or a desktop, plugging in over Ethernet removes the problem at the source.

When the Loss Is in Local Hardware

Work through it methodically. Replace a suspect Ethernet cable with a known-good one, then try a different port. If your router runs hot, is several years old, or drops packets under load, it may be the bottleneck. Replacing aging equipment is a real fix rather than a shot in the dark. A restart genuinely helps when a device has drifted into a degraded state after long uptime. But if loss returns quickly, the restart only masked a deeper fault. Keeping router firmware current can also resolve bugs that cause exactly this kind of instability.

When the Loss Is Congestion

Reduce whatever is saturating the link. A large upload, a cloud backup, or a big download can fill your connection and push loss onto everything else. Pausing that background traffic during a call or a game often clears it immediately. If your connection simply carries more than it can handle at peak times, a plan with more capacity or better queue management on the router can help. This overlaps with the causes behind high ping, since congestion tends to raise latency and drop packets together.

When Software or the Far End Is the Cause

If a VPN or a piece of security software introduced the loss, test with it disabled, or switch to a closer, more reliable endpoint. If the loss followed a single application, updating it, reinstalling it, or checking its own status beats touching your network at all. And if the problem is your provider or the destination, no local change will fix it. Recognizing that early saves a great deal of wasted effort.

When the Problem Is Probably Your ISP

Some evidence points cleanly past your own equipment. The strongest single signal is that loss persists over Ethernet once you have ruled out your cables and hardware. That eliminates everything inside your home you can control.

Several other signs reinforce it. Loss that hits every device rather than one has a shared cause. Loss that worsens predictably at peak evening hours suggests congestion on a shared segment of the provider’s network. If it appears even to nearby, reliable destinations, that rules out a distant-server explanation. And loss that arrives alongside rising latency and occasional connection drops often reflects an unhealthy line or an overloaded upstream link rather than anything in your living room.

None of this is worth taking to your provider on the strength of one bad moment. Support conversations go far better with evidence than with frustration. The evidence that helps is a record over time: when the loss happens, how consistent it is, whether it tracks the time of day, whether it occurs on a wired connection, and whether latency and drops come with it. A history that shows the pattern is what turns “my Internet feels bad” into something a provider can actually investigate.

When the Problem Is the Destination, Not You

It is worth stating plainly, because it saves people from tearing their own network apart chasing a problem that was never theirs. If loss appears only with one specific service and nowhere else, the cause is usually that service. The route to it may be where packets are dropped. Game servers get overloaded. Websites have bad days. A particular route between your provider and one destination can be congested while every other path is clean.

The test is the one described earlier: check the same connection against several different, dependable destinations. If they are all clean and only one target shows loss, you have your answer, and the fix is patience or a different server rather than new hardware. This is also why comparing behavior across destinations belongs early in any serious diagnosis.

Measuring Reliability Instead of Just Speed

The thread running through all of this is that packet loss is a reliability problem, and reliability can only be seen over time. A speed test asks how fast your connection is in a brief window. The more useful question, when things keep stuttering and failing, is how dependably your connection behaves minute after minute, and that is a different measurement entirely.

Watching packet loss on its own is helpful, but watching it alongside latency, jitter, and connection drops is what produces a real picture of connection quality. Those metrics interact. Congestion tends to raise latency and drop packets together. A failing link may show loss and drops at once. Seeing them side by side over a period of time is what separates “my connection is unreliable” from a specific, fixable diagnosis. If you want that fuller view of how your connection is actually behaving, run a StabilityTest and let it observe the pattern rather than the moment.

Frequently Asked Questions

Is 1 percent packet loss bad?

For web browsing, streaming, and downloads it is usually fine, because TCP quietly retransmits the missing data. For real-time applications like gaming and voice or video calls, 1 percent is where problems begin to show, especially if the loss arrives in bursts rather than spread evenly. So the honest answer depends on what you are doing and how the loss is distributed. Even so, 1 percent is the threshold where sensitive applications start to notice.

Is 2 percent packet loss bad?

For interactive and real-time use, yes. At 2 percent, calls tend to break up, games feel unreliable, and even TCP traffic slows as retransmissions accumulate. It is not catastrophic for a simple download, but it is enough to make anything latency-sensitive frustrating, and it is worth diagnosing rather than ignoring.

Is some packet loss normal?

A very small amount across a long Internet path is normal and expected, and well-designed applications absorb it without any visible effect. Consistent zero loss is realistic on a healthy wired connection to a nearby destination. Occasional, tiny loss on a long route is not a sign of a broken connection. The concern is loss that is frequent, sustained, or bursty enough to affect what you are doing.

Can packet loss happen with fast Internet?

Yes, and it happens often, because bandwidth and reliable delivery are separate properties. A high-speed plan tells you how much data your connection can move, not whether every packet arrives. You can have hundreds of megabits available and still lose packets to Wi-Fi interference, congestion, a failing cable, or a problem upstream. That is exactly why a fast speed test can coexist with a stuttering call or a rubber-banding game.

Does Wi-Fi cause packet loss?

Wi-Fi is one of the most common sources of packet loss in homes. Wireless shares open airwaves with other networks and devices, and signal weakens with distance and obstacles, so interference and range problems regularly cause dropped packets. The quickest way to confirm it is to compare the same test over Wi-Fi and over Ethernet. If the loss disappears on the cable, your Wi-Fi environment was the cause.

Can a bad Ethernet cable cause packet loss?

Yes. A damaged, pinched, poorly made, or aging cable can corrupt or drop packets, and corrupted packets are discarded when they fail their integrity check on arrival. A cable can look fine while performing badly. Swapping in a known-good one is among the first and cheapest tests to run when loss persists on a wired connection.

Can a router cause packet loss?

It can. A router that is overloaded, running hot, low on headroom, or beginning to fail will drop packets. Sometimes it happens only under load, sometimes even when the network is quiet. Outdated firmware can cause it too. If several devices lose packets and the loss persists over Ethernet, the router is a prime suspect, and restarting, updating, or replacing it are the logical steps.

Does packet loss cause high ping?

They frequently appear together, but one does not directly cause the other. They are often symptoms of the same underlying condition, such as congestion or failing hardware. That condition raises latency and drops packets at the same time. On TCP connections, loss can also make latency feel worse indirectly. Retransmissions and head-of-line blocking add delay while the missing data is recovered. They are distinct measurements that tend to travel together.

Why do I only get packet loss while gaming?

Usually because games run over UDP and cannot wait for lost packets to be resent. Loss that TCP would quietly hide becomes immediately visible as rubber-banding and warping. It can also be specific to one game’s servers or the route to them. Loss in a single game while everything else is clean usually points at the game’s server or path rather than your connection. Comparing that game against other online activity, and testing wired versus wireless, usually reveals which it is.

Can my ISP cause packet loss?

Yes. Congestion, a misconfigured or failing link, or trouble at the connections between networks can all cause loss inside a provider’s network that you cannot fix from home. The signs that point upstream are consistent. Loss persists over Ethernet, affects every device, worsens at predictable busy hours, and appears even to nearby destinations. Collecting a record of when and how it happens is what makes a support call productive.

How do I know where my packet loss is happening?

Isolate it layer by layer. Compare Wi-Fi against Ethernet to separate wireless problems from everything else. Check whether one device or all of them are affected to separate a single machine from the network. Check whether one destination or many are affected to separate your connection from a specific service. Watch the loss over time rather than in a single snapshot so you can see its pattern. Each comparison rules out a set of causes, and together they point at where the network is actually dropping the packets.

Where This Leaves You

Packet loss is the part of connection quality that a speed test was never designed to reveal. It is not slow bandwidth, it is not latency, and it is not jitter, though it keeps company with all three. It is simply data that fails to arrive, and its impact depends on how much you lose, how the loss clusters in time, and which applications rely on the packets that went missing.

The useful skill is not memorizing causes but learning to locate them. Direction tells you whether the trouble is on the way out or the way in. The Wi-Fi versus Ethernet comparison splits wireless from everything else. One device versus many separates a machine from the network. One destination versus many separates your connection from a distant service. And watching the behavior over time beats trusting a single number. That is what turns a vague sense that something is wrong into a specific problem you can actually fix. When you want to see how your connection really behaves, run a StabilityTest and let the pattern show itself