Jitter Explained: What It Is, How It Is Measured

Quick answer: jitter is the variation in latency from one packet or request to the next. If every round trip takes exactly 40 ms, jitter is zero. If round trips swing between 40 ms and 60 ms, jitter is roughly 20 ms. Latency tells you how long a trip takes; jitter tells you how consistent that time is. Real-time applications such as voice calls, video meetings and online games care about jitter as much as about the average, because they need data to arrive in a steady rhythm.

What is jitter?

Every packet that crosses the internet spends time in cables, switches and router queues. That time is the packet's delay. Latency is the delay (usually the round-trip time, or RTT). Jitter is the variation of that delay over a series of measurements. The word comes from electronics, where it describes a signal that arrives slightly early or late compared with a perfect clock.

A useful picture is a bus route. Two routes may both average 30 minutes. On route A, buses take between 29 and 31 minutes every day. On route B, they take anywhere from 15 to 50 minutes. The averages match, but you can plan around route A and you cannot plan around route B. In networking terms, route B has high jitter.

Jitter is not a speed. It is measured in milliseconds, like latency, but it describes consistency. It also has nothing to do with bandwidth: a 1 Gbit/s connection can have terrible jitter and a modest 20 Mbit/s connection can have almost none.

How is jitter calculated?

There is no single official formula for "jitter" in everyday use. Different tools use different definitions, which is why two tools can show different numbers for the same connection. The three most common are described below, all using a list of latency samples taken one after another.

1. Mean absolute difference between consecutive samples

Take each sample, subtract the one before it, ignore the sign, and average the results. This is close to what the ping and mtr style tools report and is the idea behind the smoothed jitter estimator in RTP (RFC 3550), which updates a running value as J = J + (|D| - J) / 16, where D is the change in transit time between two successive packets. It is sensitive to the order of samples: it measures how much each sample jumps away from the previous one.

2. Standard deviation

The standard deviation measures how far samples typically sit from their mean. It ignores order entirely. A population standard deviation divides by n; a sample standard deviation divides by n - 1. For small data sets the difference is noticeable, so check which one a tool uses.

3. Range (max minus min)

The simplest measure: the highest sample minus the lowest sample. It is easy to understand but depends entirely on two values, so a single outlier dominates it.

Worked example with five samples

Five consecutive round trips measure 40, 42, 41, 58 and 40 ms.

• Mean: (40 + 42 + 41 + 58 + 40) / 5 = 221 / 5 = 44.2 ms.
• Consecutive differences: |42 - 40| = 2, |41 - 42| = 1, |58 - 41| = 17, |40 - 58| = 18. Sum = 38. Mean = 38 / 4 = 9.5 ms.
• Population standard deviation: about 6.94 ms (sample standard deviation about 7.76 ms).
• Range: 58 - 40 = 18 ms.

The same data gives "jitter" of 9.5, 6.9, 7.8 or 18 ms depending on the definition. None is wrong; they answer slightly different questions. The important habit is to compare like with like: use the same tool and definition when you compare before and after a change.

Why order matters: two sets with the same spread

Sequence (ms)	Mean	Std dev (population)	Range	Mean consecutive difference
40, 60, 40, 60, 40, 60	50	10	20	20
40, 40, 40, 60, 60, 60	50	10	20	4
40, 41, 42, 43, 44, 45	42.5	1.71	5	1
50, 50, 50, 50, 50, 50	50	0	0	0

The first two rows contain exactly the same values, so their mean, standard deviation and range are identical. But the first flips between fast and slow on every packet, while the second shifts once, in the middle, and then stays steady. A voice call would suffer far more in the first case. Consecutive-difference jitter captures this; standard deviation and range do not.

What causes jitter?

Jitter exists whenever packets spend a variable amount of time somewhere. The usual culprits, roughly from most to least common on home and office connections:

• Queueing at a congested link. When more data arrives than a link can send, packets wait in a buffer. How long they wait depends on how full the buffer is at that instant, which changes constantly. This is the mechanism behind bufferbloat, the largest single cause of jitter on home connections that are busy uploading or downloading.
• Wi-Fi. Wireless is shared and half-duplex. Interference, distance, walls and neighbouring networks cause frames to be retried, and each retry adds delay. See Wi-Fi, Ethernet, fibre, mobile and satellite latency.
• Mobile and satellite links. Radio conditions, handovers between cells and scheduling by the network operator produce variable delay by design.
• Busy devices. An overloaded phone, laptop or low-end router CPU can delay packets even when the network is idle. Browser background tabs are throttled, which also affects browser-based measurements.
• Route changes and load balancing. If traffic alternates between two paths of different length, delay alternates too. See routing, BGP and peering.
• Congestion further away. Peak-hour congestion at an ISP interconnect or on the destination side affects everyone using that path.

Distance alone does not cause jitter. A long but uncongested fibre path (for example across an ocean) is usually very steady, because the propagation time is fixed by physics (roughly 5 microseconds per km one way in fibre). Variation comes from queues and radio, not from the glass.

How does jitter affect calls, games and video?

Voice and video calls

Voice is typically sent as a packet every 20 ms. The receiver must play audio at a constant rate. If a packet arrives late, there is a gap. To hide jitter, receivers use a jitter buffer: they hold arriving packets for a short time and release them at an even pace. See latency for video calls and VoIP.

Online games

Games send state updates many times per second. With jitter, updates arrive unevenly: players seem to stutter, teleport or "rubber-band", and hit registration feels inconsistent even if the average ping looks fine. See latency for gaming.

Streaming and downloads

Video streaming and file downloads use large buffers and TCP, so jitter is mostly invisible. Very high jitter can still reduce TCP throughput because delay variation triggers unnecessary retransmissions or slows the congestion window, but you rarely notice it directly. Cloud gaming is the exception, because it behaves like a real-time stream; see latency for streaming and cloud gaming.

What is a jitter buffer and what does it cost?

A jitter buffer trades delay for smoothness. It deliberately adds waiting time so that late packets can still be used.

Example: a call sends a packet every 20 ms. Suppose the network delay varies between 30 ms and 70 ms. The buffer needs to absorb 40 ms of variation, so it holds each packet until about 70 ms after sending. Result: a steady 20 ms rhythm, but the one-way delay is now a constant 70 ms instead of 30 to 70 ms. A packet that takes 90 ms arrives after its playback slot and is discarded; the call counts it as lost.

Many applications use adaptive jitter buffers that grow when jitter rises and shrink when it falls. This is why a call can start crisp and gradually develop a slight delay or "walkie-talkie" feel on a bad network: the buffer has grown to protect against jitter at the cost of extra latency. The delay budget most often quoted for good conversation is about 150 ms one way (from ITU-T G.114 guidance), so every millisecond the buffer adds is a millisecond taken from that budget.

What is an acceptable jitter range?

The figures below are widely quoted rules of thumb, not guarantees. Applications differ in how well they cope.

Use case	Very good	Usually acceptable	Likely to cause problems
Competitive online gaming	Under about 5 ms	Up to about 15 ms	Above about 20-30 ms
Voice and video calls	Under about 10 ms	Up to about 30 ms	Above about 30-50 ms
Cloud gaming	Under about 5 ms	Up to about 15 ms	Above about 20-30 ms
Video streaming (buffered)	Not noticeable	Up to 100 ms or more	Only extreme, sustained jitter
Web browsing, downloads, email	Not noticeable	Up to 100 ms or more	Rarely a problem on its own

Jitter must also be read against latency. A jitter of 20 ms on a 15 ms connection means individual round trips range roughly from 5 to 35 ms, which is still fast. The same jitter on a 200 ms connection is a smaller relative variation but is harder for an application to hide.

How does GlobeLatency show jitter?

GlobeLatency measures latency with real HTTPS requests from your browser (see how GlobeLatency measures). It does not print a single number labelled "jitter", but the spread is visible in several places:

• Best and worst pass. In a test, each destination is measured for 1 to 20 passes (default 3). The tile shows the average of successful passes along with the lowest (best) and highest (worst). The gap between best and worst is the range definition of jitter described above.
• 95th and 99th percentile. Computed per destination over its passes with the nearest-rank method. They show how bad the slow end is. With few passes they simply equal the worst pass; see percentiles explained.
• The Unstable flag. A destination is marked Unstable when its worst pass is more than 3 times its average.
• Unstable count. The summary cards show how many destinations carried that flag.
• Live view. In the live map and the monitor, destinations are re-measured every 5 to 120 seconds (default 30). The sparkline, the 95th percentile over up to the last 60 readings, and the colour changes show jitter evolving over time.

How the Unstable flag behaves (worked example)

The flag compares the worst pass with three times the average. Because the average includes the worst pass itself, a single spike has to be large to trigger it. Suppose a destination normally answers in 30 ms and one pass spikes to a value S. With n successful passes, the average is (30 x (n - 1) + S) / n, and the flag fires when S is greater than 3 x that average. Solving gives S greater than 90 x (n - 1) / (n - 3):

Successful passes (n)	Spike needed to flag (base 30 ms)	Check
3	Impossible	With three passes the worst can never exceed 3 times the average of the three, because the average is at least one third of the worst
4	Above 270 ms (9 x base)	Average = (90 + 271) / 4 = 90.25; 3 x 90.25 = 270.75 < 271
5	Above 180 ms (6 x base)	Average = (120 + 181) / 5 = 60.2; 3 x 60.2 = 180.6 < 181
10	Above about 116 ms	Average = (270 + 117) / 10 = 38.7; 3 x 38.7 = 116.1 < 117
20	Above about 101 ms	Average = (570 + 102) / 20 = 33.6; 3 x 33.6 = 100.8 < 102

Two practical conclusions follow. First, the Unstable flag is a signal for severe swings only; moderate jitter such as 30 ms rising to 80 ms will not trigger it. Second, with the default of 3 passes the flag has almost no sensitivity, so use more passes if jitter is what you want to investigate. (The table assumes the average is taken over the successful passes only, as the shown average is.)

Why do several passes matter for jitter?

Jitter is a property of a series. One measurement cannot show variation, and two give only a single difference. A destination measured three times might look perfect by luck while a spike appears in the fourth pass.

The first pass to a destination also tends to be slower because it includes DNS lookup, TCP connection setup and the TLS handshake, while later passes may reuse the open connection (cache-busting prevents HTTP caching but not connection reuse). So the first-versus-later difference is a measurement artefact, not network jitter. With 10 to 20 passes, one slow first pass is a small part of the picture, and the percentile figures become meaningful.

For jitter caused by something that comes and goes, such as a neighbour streaming in the evening or a household member uploading, a one-off test is the wrong tool. Leave the monitor running for 10 to 30 minutes, note when the cards turn yellow or red, and match that against what else was happening on the network.

How do I measure jitter myself?

1. Pick a stable target near you, such as a well-connected CDN edge or a destination in your own country. Far destinations add their own variation.
2. Take at least 20 samples, spaced evenly. ping -c 50 host on Linux/macOS or ping -n 50 host on Windows reports min, average, max and often a deviation figure. mtr shows per-hop standard deviation.
3. Test in the conditions that matter: on Wi-Fi from the room where you play or work, and again over a cable.
4. Repeat under load (a large upload running) to see whether queueing is the cause.
5. Compare the best, average and worst. A worst value many times the best means the path is unstable.

How can I reduce jitter?

• Use Ethernet instead of Wi-Fi for anything latency-sensitive.
• If you must use Wi-Fi, sit closer to the access point, prefer 5 GHz or 6 GHz, and avoid channels crowded by neighbours.
• Prevent line saturation. Enable smart queue management (SQM, fq_codel or CAKE) on your router, or limit upload and download rates slightly below your line speed. See bufferbloat.
• Pause cloud backups, large uploads and updates during calls and games.
• Restart or replace an old router that has a weak CPU.
• If jitter shows up toward every destination at specific times of day, collect evidence and talk to your provider (talking to your ISP).

More general steps are in how to reduce latency and troubleshoot high latency.

Common mistakes and myths

• "Low ping means a good connection." Not if the ping swings. Look at best versus worst, not just the average.
• "Jitter and packet loss are the same thing." They are different measurements, though they often have the same root cause. See packet loss explained.
• "A single test shows my jitter." With three passes it mostly cannot. Use more passes or the live monitor.
• "Comparing jitter numbers from different tools is fair." Definitions differ (consecutive difference, standard deviation, range). Compare within one tool.
• "A faster plan fixes jitter." More bandwidth helps only if the cause was saturation. Wi-Fi, queueing configuration and bad routes are not fixed by a faster plan.
• Ignoring the first pass effect. The first request includes connection setup; do not read it as instability.
• Testing in a background tab. Browsers throttle timers in background tabs, which adds artificial variation.

What to do next

• Run a free latency test with 10 to 20 passes and compare best and worst.
• Watch your connection over time on the live map or the monitor.
• Learn how to read spread statistics in percentiles (p50, p95, p99) and mean, median, min and max.
• If the spikes appear only while something is uploading, read bufferbloat explained.
• Understand what the numbers do and do not capture in accuracy and limitations.