What Is Jitter? Why It Matters and How to Fix It

When the Average Looks Fine but the Connection Doesn’t

Your ping looks reasonable. The number a speed test hands back sits well within the range people call good, maybe 25 or 30 ms. Yet your game still stutters at the worst moments. Your voice on a call arrives in clipped fragments. The person on the other end keeps asking you to repeat yourself. Nothing about that average latency figure warned you it was coming.

The reason is that an average is a summary, and summaries hide what matters most for real-time traffic: consistency. A connection that delivers packets at a steady, predictable rhythm feels smooth. A connection that averages the same latency but delivers packets in an erratic, bunched-up pattern feels broken. The two can produce nearly identical ping numbers. That inconsistency has a name, and it is the measurement most people never think to check. It is jitter.

Maybe your connection seems fast on paper but keeps letting you down during calls, games, or anything that happens in real time. If so, jitter is one of the first things worth understanding. This guide explains what jitter actually is and how it differs from latency and packet loss. It also shows why it hurts some applications far more than others. And it shows how to find where your own jitter comes from, before you change hardware or blame your provider.

What Jitter Actually Is

Jitter is the variation in the delay between packets as they cross a network. Latency measures how long a packet takes to make its trip. Jitter measures how much that time changes from one packet to the next. If latency is the average length of your commute, jitter is how wildly that commute swings from day to day. Both are measured in milliseconds, and they describe different properties of the same journey.

A short example makes the difference concrete. Picture a stream of packets whose one-way delays land like this:

20 ms, 22 ms, 19 ms, 21 ms

The average is about 20 ms. Better still, every packet arrives close to it. The timing is tight and predictable. Now picture a stream that produces this instead:

20 ms, 85 ms, 24 ms, 130 ms

You could argue the typical packet is still fairly quick. A casual glance at an average might not look alarming. But the spacing is chaotic. Packets sent at even intervals now arrive in clumps and gaps. Any application expecting a steady flow now struggles. The data shows up early, late, and late again, with no pattern to rely on.

That is the core idea. Jitter is not about packets being slow. It is about packets being inconsistent, and inconsistency is its own kind of problem.

A Note on Definitions

It is worth knowing that “jitter” is a loose term, and the people who standardize network measurements are careful about it. The IETF’s formal metric is packet delay variation, defined in RFC 3393. That document deliberately avoids the word jitter, because different groups use it to mean different things. In everyday use, and throughout this article, jitter means the variation in packet delay over time. Just be aware that two tools can both report “jitter” while calculating it differently. One might compare each packet to the last, another to a running average. That is one reason jitter numbers from different tools do not always line up, which matters once you start measuring your own.

How Jitter Is Measured

Because jitter describes variation, it can only be calculated from a series of measurements, never a single one. A tool times a sequence of packets, records the delay of each, and then expresses how much those delays differ. Some tools report the average difference between consecutive packets. Others report the spread around a mean. Real-time applications compute it continuously as packets arrive, using running estimates rather than a tidy after-the-fact average.

The RTP protocol that carries most voice and video traffic is a good illustration. Its receivers keep an ongoing estimate of jitter using a smoothed calculation defined in RFC 3550. They update it packet by packet and weight recent samples, so one odd arrival does not throw off the figure. The details are not something an ordinary user needs to reproduce. The takeaway is that jitter is inherently a measurement over time. Any number you see is a summary of many samples rather than a snapshot.

This has a practical consequence for testing. A jitter reading built from a handful of packets is close to meaningless. A few samples cannot describe a pattern. Warm-up effects make it worse. The first packets to a new destination carry connection-setup overhead that inflates the early numbers. A trustworthy jitter figure needs a decent number of samples, gathered against a nearby target. It also needs enough time to catch the connection behaving both well and badly.

Jitter Is Not Latency, and It Is Not Packet Loss

These three metrics travel together and get blamed for each other constantly. Keeping them separate is what lets you describe a problem accurately instead of lumping everything under “lag.”

Latency, reported as ping, is delay: how long a round trip takes. You can have high latency with steady timing. That feels slow but predictable, like a commute that always takes the same time. Jitter is the variation in that delay. A connection can have low average latency and still have terrible jitter. That case confuses people most, because the ping number looks great while the experience does not. If your complaint is that everything feels uniformly delayed, latency is the likelier culprit. Our guide to high ping and how to fix it covers that side. If the connection feels erratic instead, fine one second and broken the next, look at jitter first.

Packet loss is different again. It is data that never arrives at all, rather than data that arrives at an uneven pace. Loss and jitter often share a cause, since a congested link tends to both delay packets unevenly and drop some of them. But they are distinct measurements with distinct effects, and our companion article on packet loss covers that metric in depth. The model is simple. Latency is how long, jitter is how consistent, packet loss is how complete. A connection in real trouble usually shows more than one. Treating them as a single blurred idea is what makes network issues hard to pin down.

Why an Average Ping Hides an Unstable Connection

The trouble with a single latency figure is that it flattens everything interesting into one number. Two connections can report an identical 30 ms average while behaving completely differently. One holds close to 30 ms on every packet. The other bounces between 8 ms and 90 ms and simply happens to average out to 30. To a speed test that reports latency as a headline figure, they look like twins. To a game or a call, one is excellent and the other is unusable.

This is also why a quick test can call a connection healthy right before it falls apart. A speed test runs for a short window and often reports latency as a single value. If it samples during a calm stretch, or averages the spikes away, it can miss the variation entirely. The number is not wrong. It answers “how quick is a typical packet.” The question that matters is “how consistent is the timing,” and those are not the same.

Measuring latency under load, rather than at idle, exposes much of what a plain average conceals. A connection can look steady when nothing else is using it. Then it develops heavy jitter the moment a large upload, a backup, or another device starts competing for the link. That gap between idle and loaded behavior is where a lot of real-world jitter lives. It is invisible to any test that only looks at a quiet connection for a few seconds.

Why Jitter Matters for Real-Time Traffic

Not all traffic cares about timing. When you load a web page or download a file, the data travels over TCP. TCP guarantees delivery and reassembles everything in order. If packets arrive unevenly, TCP simply waits and sorts it out, and you rarely notice. A file does not care whether it finished assembling a few milliseconds sooner or later.

Real-time traffic is the opposite. Games, voice calls, and video conferencing carry a live stream of small packets. Those packets mean something only if they arrive on schedule. These applications generally run over UDP, which does not wait for stragglers or resend what goes missing. A late packet in a live conversation is useless once the moment it described has passed. When timing is steady, everything the application expects shows up when expected. When jitter climbs, packets arrive early, late, and out of rhythm. The application has to paper over the gaps in real time. How gracefully it does that decides whether you notice a little roughness or a call that becomes unusable.

Gaming

A low average ping is often treated as the mark of a good gaming connection. But it does not guarantee smooth play. Games send frequent, small updates about position, movement, and actions. They depend on those updates arriving at a steady cadence. When jitter is high, updates bunch up and then stall. The game is left guessing about what happened in between. That shows up as stutter, as actions that register a beat late, or as movement that looks slightly wrong. The connection feels responsive one moment and sluggish the next.

It is worth being honest about attribution here, because jitter is not the only thing that produces those symptoms. Packet loss causes rubber-banding and warping too. A struggling or distant game server can feel identical to a local network problem. Modern games also run their own prediction and correction to smooth over imperfect networks. That can mask small amounts of jitter, and sometimes make its effects appear in odd ways. Jitter is a common and under-appreciated cause of uneven gameplay. Still, it is one suspect among several, which is why the diagnostic steps later focus on isolating it rather than assuming it.

Voice and Video Calls

Voice and video are where jitter does its most visible damage. A call carries audio as a steady stream of tiny packets, each a slice of sound. They are sent at fixed intervals, such as one every 20 milliseconds. If they arrived exactly as sent, playback would be seamless. Jitter disrupts that even spacing. Without intervention, you would hear the result as robotic audio, clipped words, and dropouts.

Jitter Buffers and the Delay Trade-off

To counter this, receiving applications use a jitter buffer. The idea is straightforward. Instead of playing each packet the instant it arrives, the application holds a small reserve. It waits a moment, then plays them out at a smooth, even rate. That reserve absorbs the unevenness, so late packets have a chance to catch up before their turn to play.

The catch is that buffering is not free. Every millisecond a packet spends waiting in the buffer is a millisecond of added delay. Conversation becomes awkward once the total one-way delay grows too large. Call-quality engineering generally tries to keep mouth-to-ear delay under roughly 150 ms. The jitter buffer’s size eats directly into that budget. That is the trade-off at the heart of real-time audio. A bigger buffer hides more jitter but adds more delay. A smaller buffer keeps the conversation snappy but drops packets that arrive too late to use.

Modern systems use adaptive buffers that grow and shrink as conditions change. Call platforms typically set tight jitter targets, because rising variation eventually exceeds what buffering can conceal without adding excessive delay. The exact figure varies by platform and method, and Microsoft’s network guidance for real-time media in Teams covers these impairments. When jitter stays moderate, the buffer conceals it and you never notice. When jitter is severe or wildly variable, it exceeds what any reasonable buffer can hide. The call degrades no matter how clever the software is.

Streaming

On-demand streaming, the kind where you watch a recorded video, is largely immune to jitter. The reason is worth understanding. A streaming player buffers seconds or even minutes of video ahead of what you are watching. Uneven packet timing has an enormous cushion to absorb it. The occasional late packet is irrelevant when the player already holds the next thirty seconds. Live and low-latency streaming shrink that cushion to stay closer to real time, so they grow more sensitive to jitter. They are still far less sensitive than a two-way call, where every added buffer second harms the conversation. If your streaming is smooth while your calls and games are not, that difference in buffering is the reason. It is a useful clue rather than a contradiction.

What Causes High Jitter

Jitter comes from anything that makes packet timing uneven, and several causes can operate at once. The pattern of when it appears is what eventually points to the source. Watch for idle versus loaded, one device versus all of them, certain hours versus constantly.

Congestion, Buffers, and Local Hardware

Network congestion is the most common cause. When a link carries more traffic than it can handle at that instant, packets queue. Those queues form and drain irregularly. Some packets sail through. Others wait behind a burst of traffic, and the delay between them becomes uneven. This is why jitter so often rises during busy evening hours. It also spikes the moment a large upload or download saturates your connection.

Buffer and queue behavior deserves specific mention. Oversized buffers in network equipment create a particular flavor of jitter under load. When a device holds too much queued data, latency and its variation swell whenever the link is busy. They recover when it clears. This effect, often called bufferbloat, is a frequent reason a connection tests clean at idle and turns erratic the instant something starts uploading.

Wi-Fi interference and weak signal are the dominant source of jitter inside homes, and wireless earns its own section below. In short, air is a shared and unpredictable medium, and sharing it unpredictably produces uneven timing.

Overloaded or aging hardware introduces jitter when a router cannot process packets at a steady rate. A router running hot, low on headroom, or handling more than it was built for will pass some packets promptly and delay others. That unevenness is jitter.

Beyond Your Network

ISP congestion produces jitter beyond your walls, inside your provider’s network, typically at peak times when a shared segment carries its heaviest load. You cannot fix this from home, but you can gather the evidence that identifies it.

Routing and path changes can shift jitter as well. Traffic crosses many networks to reach a destination. When the path changes or a handoff between networks is congested, the delay of successive packets can vary. They take slightly different routes or wait at busy exchange points.

VPNs add a server and extra hops to the path, plus encryption work on every packet. A nearby, well-run endpoint may add little. A distant or overloaded one can introduce noticeable jitter that was not there before. If your jitter rose when you enabled a VPN, test with it off.

Destination or server problems round out the list. If the service you are connecting to is overloaded, packets can leave it at uneven intervals no matter how healthy your connection is. Jitter that appears only with one specific game or service, and nowhere else, often points here rather than at your network.

Why Wi-Fi Is Especially Prone to Jitter

Wired connections send signals along a controlled path that the two ends do not have to share. Wi-Fi broadcasts through open air that it shares with every nearby device, and that difference is a recipe for uneven timing.

The core issue is that Wi-Fi is a medium where devices take turns. Only one device on a channel can transmit at a time. Your traffic waits its turn among your neighbor’s network, your other devices, and anything else on the same frequencies. When the air is busy, that wait varies from one packet to the next, and variable waiting is exactly what jitter is. Interference from microwaves, cordless phones, baby monitors, and dense clusters of networks makes the waiting less predictable still.

Signal strength compounds it. A weak or distant connection forces the wireless hardware to retransmit frames that were not received cleanly, and each retransmission adds a variable delay. A device at the edge of usable range may deliver most packets promptly, then stall on the ones that need several attempts. That produces exactly the erratic timing that ruins real-time traffic. Someone walking between you and the router, a neighbor starting a download, or a suddenly crowded channel can all spike jitter briefly. Then it settles again. This is why Wi-Fi jitter is so often intermittent. It is also why comparing Wi-Fi against a wired connection is the single most informative test you can run.

What Counts as Good or Bad Jitter

People want a single number that separates good from bad. Rough guidance is useful, but treating any threshold as an absolute law will mislead you. What counts as acceptable depends on several things: the application, how the jitter is measured, the network path, and whether the variation is steady or bursty.

As practical guidance rather than scientific fact, these ranges hold up reasonably well for real-time use:

• Under 5 ms is excellent, and typical of a healthy wired connection to a nearby destination. Nothing will feel affected by it.
• 5 to 15 ms is good and generally unnoticeable for calls and gaming.
• 15 to 30 ms is usually still workable, though sensitive applications may show minor roughness, especially if the variation is uneven.
• Above 30 ms tends to become noticeable in real-time use, with calls and games showing the strain.
• Well above 30 ms, and particularly jitter that spikes into the hundreds of milliseconds, is disruptive for anything interactive.

Why Context Changes the Numbers

The context matters more than the boundaries. A steady 20 ms of variation is easier for a jitter buffer to absorb than 20 ms that swings wildly around an average. The buffer can size itself for a consistent spread but struggles with sudden bursts. Ordinary web browsing tolerates far more jitter than a live call, since it has no timing requirement to violate. And a figure measured against a distant server reads higher than one measured against a nearby target. The same connection can appear better or worse depending on how you test it. Use the ranges as a starting point, not a verdict.

How to Test Jitter Properly

The most common testing mistake is treating jitter like a speed reading: run it once, read the number, move on. Because jitter is variation over time, a single brief test tells you very little. A connection can look flawless for the ten seconds you happen to measure and fall apart a minute later. One brief reading will never show you that.

A better approach is to watch the connection over a meaningful stretch, ideally while noting when problems occur. You want enough samples to describe a pattern, gathered against a nearby target so distance does not inflate the numbers. Spread them across enough time to catch both quiet and busy periods. Test at the times you actually experience trouble, such as evening hours or during a call. That is far more revealing than a midday test when the network is calm.

This is the kind of picture a stability test is built to produce, because it watches the connection continuously rather than sampling a single instant. To see whether your latency holds steady or swings around beneath a flattering average, run a StabilityTest and let it observe for a while. That beats trusting one number. Looking at jitter alongside latency, packet loss, and connection drops over the same period gives a far more honest read on quality. Those metrics interact and often rise together.

How to Find Where Your Jitter Is Coming From

As with any connection problem, the goal is not to try every fix at once. It is to narrow down where the jitter starts. Each comparison you run rules out a set of causes, and the location tells you which fixes are even worth attempting.

Confirm the Jitter Over Time

Before changing anything, establish that jitter is genuinely present and get a feel for its behavior. Is it constant or bursty? Does it appear at particular times of day? Does it track with something you are doing, like a large upload? A pattern that emerges over minutes or hours is worth far more than a single reading, and it shapes everything that follows.

Compare Wi-Fi Against Ethernet

This is the highest-value test available to you. Run your check over Wi-Fi, then connect the same device with an Ethernet cable and run it again under similar conditions. If the jitter drops sharply on the cable, the problem is your wireless environment, and the fixes belong there. If it persists over Ethernet, you have eliminated Wi-Fi entirely. You can stop adjusting your wireless setup, which is where a lot of effort gets wasted.

Check Whether It Affects One Device or All of Them

If several devices show high jitter, the cause is shared and sits at the router or beyond. If only one device is affected, suspect that machine, its wireless adapter, its drivers, or its position relative to the router. This costs nothing and removes an entire branch of possibilities.

Test at Idle Versus Under Load

Run a test on a quiet connection. Then run it again while something loads the link, such as a large upload or a file sync on another device. Jitter that is fine at idle and terrible under load points strongly toward congestion or bufferbloat, either in your own network or at your provider. This single comparison explains a large share of real-world jitter. It is easy to miss if you only ever test a calm connection.

Compare Different Destinations

Test against a couple of different, reliable targets. Jitter that appears everywhere points at your own network or your provider. Jitter that shows up only against one particular game or service, while other destinations stay smooth, points at that destination or the route to it. It is not your connection.

Working outward like this turns a vague complaint into a located one. You move from your device to your wireless, your router, your provider, and finally the destination. A reading of high jitter in isolation tells you little. High jitter that appears under one condition and vanishes under another tells you where to look.

How to Reduce High Jitter

Once you know roughly where the jitter lives, the fix follows from the location. Trying things in that order beats changing settings at random.

Wireless Fixes

When the problem is wireless, work on the wireless environment. Move closer to the router, or clear the obstacles between you and it. Put the router somewhere central and open rather than in a cabinet or on the floor. Move to a less congested channel, or to the 5 GHz or 6 GHz band, which are usually cleaner than 2.4 GHz. For the devices where consistency matters most, such as a console, a desktop, or a work computer, use a cable. A wired connection removes the entire category of wireless timing problems at once.

Congestion and Bufferbloat

When congestion or bufferbloat is the cause, reduce what is saturating the link. Pausing a large upload, a cloud backup, or a big download during a call or a game often clears the jitter immediately. You have removed the queue that was forming. On a router that supports Quality of Service or Smart Queue Management, enabling it helps. It keeps buffers from swelling under load and holds jitter down when the connection is busy. If your line is simply carrying more than it can handle at peak times, that is worth knowing before you assume the hardware is faulty.

Hardware, VPNs, and the Far End

When local hardware is the cause, work through it methodically. A router that runs hot, is years past its prime, or struggles under load can introduce jitter. Updating its firmware or replacing genuinely aging equipment is a real fix rather than a guess. Restarting helps when a device has drifted into a degraded state. If the jitter returns quickly, though, the restart only masked something deeper.

A VPN that introduced the jitter is easy to test for: turn it off, or switch to a closer, less loaded endpoint. And if the evidence points to your provider or to a specific destination, no change on your end will fix it. Recognizing that early saves you from replacing hardware that was never the problem.

When the Problem Is Inside Your Home

Most jitter that people can actually do something about starts inside the home, and a few signs point there clearly. Jitter that disappears the moment you switch from Wi-Fi to Ethernet is wireless, full stop. A problem that affects only one device is specific to that device rather than your connection. And jitter that appears only when your own network is busy, then clears when it goes quiet, is local congestion or bufferbloat. You can often manage that by controlling background traffic or improving how your router queues it. In each of these cases the cause is within reach, and the diagnostic steps above lead straight to it.

When the Problem Is Probably Your ISP

Other evidence points past your equipment to your provider’s network. The strongest single sign is jitter that persists over a wired connection after you have ruled out your own hardware. That eliminates everything inside your home you can control. It grows more convincing when several signs line up. The jitter affects every device. It worsens predictably during peak evening hours. It appears even against nearby, normally reliable destinations. And it often arrives alongside rising latency and occasional connection drops. Together those suggest an overloaded or unhealthy upstream link rather than anything in your living room.

None of this is worth taking to your provider on the strength of one bad test. A support conversation goes far better with evidence. The evidence that helps is a record over time. Note when the jitter happens, how consistent it is, whether it tracks the hour, whether it occurs on a wired connection, and what you measured it against. “My jitter climbs to 60 ms every weeknight at 8 pm on Ethernet, tested against a nearby server” gives a provider something concrete to investigate. “My internet feels laggy” does not.

When the Destination or Service Is Responsible

It is worth stating plainly, because it saves people from dismantling a network that was working fine. Say jitter shows up only when you connect to one particular service and nowhere else. The likeliest explanation is that the service, or the route to it, is where the timing is coming apart. Game servers get overloaded. A 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 dependable destinations. If they are all steady and only one target is erratic, the problem is not yours to fix. The answer is patience or a different server rather than new equipment.

Why Consistency Matters as Much as Speed

Underneath everything above sits a single idea: a fast connection and a reliable one are not the same thing. Bandwidth tells you how much data your connection can move. Jitter tells you whether it delivers that data on a rhythm your applications can depend on. For anything that happens in real time, the second property often matters more than the first, and it is precisely the property a headline speed number cannot show.

This is why two people on identical plans can have completely different experiences. One sees a steady stream of packets and a call that just works. The other has the same average speed but erratic timing, and every video meeting turns into a series of frozen frames and talked-over sentences. The plan on the invoice describes capacity. Whether that capacity arrives in a usable rhythm is a separate question, and it is the one that decides how the connection actually feels.

Frequently Asked Questions

What is jitter in an internet connection?

Jitter is the variation in the delay between packets arriving over your connection. Latency measures how long packets take on average; jitter measures how consistent that timing is. Low jitter means packets arrive at steady, predictable intervals, which is what real-time applications like calls and games need. High jitter means they arrive erratically, which causes stutter, choppy audio, and other timing problems even when your average ping and download speed look fine.

What is a good jitter?

As practical guidance, under 5 ms is excellent, 5 to 15 ms is good and usually unnoticeable, 15 to 30 ms is often still workable, and above 30 ms tends to become noticeable in calls and games. These are not hard scientific limits. What counts as acceptable depends on the application, how the jitter is measured, and whether it is steady or arrives in bursts, so treat the ranges as a starting point rather than a verdict.

Is 10 ms jitter good?

Yes, 10 ms of jitter is generally good and sits comfortably in the range most real-time applications handle without any visible effect. A jitter buffer on a call absorbs that amount easily, and games rarely show it. It is worth watching only if it comes with high packet loss or occasional large spikes. A low average can still hide brief bursts that disrupt things.

Is 20 ms jitter bad?

Not necessarily. Around 20 ms is often still workable for calls and gaming, especially if the variation is steady rather than spiky. It sits in the range where sensitive applications may begin to show minor roughness, though many will not. If a connection measuring 20 ms of jitter feels fine in practice, it probably is. If it feels rough, the number may be hiding sharp bursts, which matter more than the average.

Is 30 ms jitter bad?

Around 30 ms is roughly where jitter starts to become noticeable for real-time use. Around 30 ms is roughly where jitter can start to become noticeable in real-time use, depending on the application and how the variation occurs. It is not catastrophic, and a good adaptive jitter buffer can still conceal a fair amount of it. Even so, it is high enough to be worth diagnosing, particularly if it comes in bursts or arrives with packet loss.

Why is my jitter high but my ping is low?

Because ping and jitter measure different things. Ping is the average delay, and jitter is how much that delay varies. A low average simply means a typical packet is quick; it says nothing about consistency. If most packets are fast but some arrive much later, the average stays low while the variation, your jitter, is high. That combination is common, and it is exactly why a connection with a great-looking ping can still ruin a call or a game.

Is jitter worse than ping?

Neither is universally worse; they cause different problems. For real-time traffic like voice, video, and gaming, consistent timing often matters more than raw speed. High jitter with low latency can feel worse than moderate, steady latency. For activities without timing requirements, like downloads or browsing, jitter barely matters while latency still affects responsiveness. The right one to worry about depends on what you are doing.

Does Wi-Fi cause jitter?

Wi-Fi is one of the most common sources of jitter in homes. Wireless is a shared medium where devices take turns transmitting, and interference, weak signal, distance, and retransmissions all make the timing between packets uneven. The quickest way to confirm it is to compare the same test over Wi-Fi and over Ethernet. If your jitter drops sharply on the cable, your wireless environment was the cause.

Can Ethernet have jitter?

Yes, though usually far less than Wi-Fi, and when it appears on a wired connection it points to a more specific cause. Ethernet removes wireless timing variables. Jitter that persists on a cable typically comes from congestion or bufferbloat on your line, an overloaded or failing router, or something upstream at your provider. That is what makes wired testing so useful: it narrows the search considerably.

Does jitter cause lag in games?

It can. Games rely on a steady stream of small updates. When jitter bunches those updates together and then stalls them, the result is stutter, delayed actions, and inconsistent movement. That said, jitter is not the only cause of those symptoms; packet loss and struggling game servers produce similar effects. Comparing wired against wireless and testing different servers helps confirm whether jitter is actually the problem in your case.

How do I reduce jitter?

Start by locating it rather than guessing. If it is wireless, move closer to the router, reduce interference, switch bands, or use Ethernet for the devices that matter. If it comes from congestion, pause heavy uploads and downloads during calls or games, and enable Quality of Service or Smart Queue Management on a capable router. Aging hardware may need a firmware update or replacement. And if the source is your provider or a specific service, no local change will fix it, which is why diagnosis comes first.

Can my ISP cause high jitter?

Yes. Congestion inside your provider’s network, especially during peak hours, can produce jitter you cannot fix from home. So can problems where networks hand traffic off to each other. The signs that point upstream are jitter that persists over Ethernet, affects every device, worsens at predictable busy times, and appears even against nearby destinations. Gathering a record of when and how it happens is what makes a support call productive.

Does a VPN increase jitter?

It can. A VPN routes your traffic through an additional server and encrypts every packet, which adds both distance and processing. A nearby, well-run endpoint may add very little, but a distant or overloaded one can noticeably increase jitter. If your jitter rose after you connected to a VPN, test with it turned off. If you need the VPN, try an endpoint closer to you.

How do I test internet jitter?

Use a tool that measures over time rather than reporting a single instant. Gather enough samples against a nearby server to describe a pattern, and test at the times you actually experience problems. Comparing Wi-Fi against Ethernet, and idle against loaded conditions, tells you far more than one reading. A stability test that tracks jitter alongside latency, packet loss, and drops over a period gives the most complete picture of how consistent your connection really is.

Where This Leaves You

Jitter is the part of connection quality that a speed test, and even an average ping, were never built to show. It is not slow bandwidth, it is not high latency, and it is not packet loss. Jitter simply keeps close company with all of them. The unevenness in how your data arrives is its own distinct thing. For anything that happens in real time, that unevenness can matter more than raw speed.

What makes jitter manageable is that its pattern gives it away. Wireless versus wired separates the air from everything else. One device versus many separates a machine from the network. Idle versus loaded exposes congestion and bufferbloat. One destination versus several separates your connection from a distant service. And watching the behavior over time beats trusting a single flattering number. It turns a vague sense that something is wrong into a specific problem with a specific fix. When you want to see how steady your connection actually is, run a StabilityTest and give it time to reveal the rhythm underneath the average.