What Is Jitter?

Latency tells you the average; jitter tells you the spread

Latency is usually reported as a single number: the time it takes a small message to travel to a server and back. That number is useful, but it is a summary. It tells you roughly how responsive a connection is, in the same way an average commute time tells you roughly how long a journey takes.

What an average hides is variation. A commute that takes exactly 25 minutes every day feels completely different from one that averages 25 minutes but sometimes takes 10 and sometimes takes 50. The average is identical; the experience is not. Jitter is the network equivalent of that spread — it describes how much individual round trips differ from each other, rather than how fast they are on average.

Jitter

The variation in round-trip response time across a series of measurements taken close together in time. It is usually expressed in milliseconds and reflects how consistent, rather than how fast, a connection is.

Two connections can report the same average latency of, say, 30 ms and behave completely differently in practice. One holds steady between 28 and 32 ms on every sample. The other swings between 10 ms and 90 ms, occasionally spiking further, while still averaging out to roughly 30 ms across the run. Only the second connection will produce noticeable problems in a live call or a fast-paced game, and only a jitter figure — not the average latency — reveals the difference.

Why an average number can look fine while the experience does not

Averages are built to smooth things out, which is exactly what makes them unreliable for spotting inconsistency. A handful of very fast responses can offset a handful of very slow ones, leaving a summary figure that looks perfectly acceptable. This is a common source of confusion when someone reports a laggy call despite a speed test showing a good ping.

The underlying cause of that spread is usually some part of the network path handling traffic unevenly — a Wi-Fi link contending with other devices for airtime, a queue that briefly fills and drains, or a mobile connection switching between cell towers or signal conditions. None of these show up clearly in an average; they show up as occasional outliers buried inside it.

This is why jitter needs its own measurement and its own place in a result, rather than being inferred from the latency figure. A connection can pass on latency and still be the source of a genuinely bad call, and reporting only the average would miss that entirely.

Why jitter matters so much for voice, video and gaming

Real-time applications assume that data will arrive at a steady pace. A voice call breaks audio into small frames sent at fixed intervals, expecting each one to arrive just in time to be played. Video calls and online games make the same assumption for their own data. None of them need speed so much as they need consistency.

When jitter is high, frames stop arriving on schedule. Some arrive early, some arrive late, and some arrive in bursts after a gap. The receiving application has to cope somehow, and the tools it has are limited: play what it has and accept gaps, wait longer and add delay, or discard frames that arrive too late to be useful.

In practice this produces recognisable symptoms. Voice calls can sound robotic or clipped, as short gaps are filled or skipped over. Video can freeze for a fraction of a second and then jump forward to catch up, rather than playing smoothly. Games can feel responsive most of the time but occasionally show a rubber-banding effect, where a character's position suddenly corrects because an input or update arrived out of its expected order.

These symptoms can also be produced by other causes, including loaded latency and, separately, packet loss. Jitter is one plausible explanation among several, not an automatic diagnosis.

How jitter is actually calculated

Jitter cannot be measured from one round trip, because variation requires more than one value to compare. It is calculated from a series of latency samples collected in quick succession, by looking at how much consecutive samples differ from each other, or how far individual samples sit from the typical value in the series.

A single unusually slow sample in an otherwise steady series will raise the jitter figure, even if most of the run was consistent. This is by design — an occasional large spike is exactly the kind of event that disrupts a call or a game, so it should be visible in the result rather than smoothed away.

Because jitter depends on the shape of the whole series rather than any one value, it is also useful to look at the underlying samples in terms of the median (the typical value) and the 95th percentile, often written p95 (a value that only the worst 5% of samples exceed). A low median with a high p95 tells you that the connection is usually fine but has an occasional bad moment — a pattern a single jitter number can hint at but not fully explain.

p95 latency

The value below which 95% of samples in a series fall. It highlights occasional bad moments that an average would dilute, without being dominated by a single extreme outlier the way a maximum value would be.

Jitter is not packet loss

It is easy to lump jitter, latency and packet loss together as one vague idea of 'connection quality', but they describe different things and can be present independently of each other. Latency is how long data takes to arrive. Jitter is how consistent that time is across many pieces of data. Packet loss is about data that never arrives at all.

A connection can have high jitter with no packets lost whatsoever — every piece of data eventually arrives, just at uneven intervals. Norynt measures download and upload throughput, idle latency, loaded latency, jitter and how steady the speed stays; it does not directly measure packet loss. A high jitter reading in a Norynt result should be read as exactly that — uneven timing — and not treated as evidence that data is being dropped.

This distinction matters for troubleshooting. Fixes that target congestion and queueing, such as reducing competing traffic or improving a Wi-Fi link, address the causes typically behind uneven timing. They are not aimed at, and will not necessarily resolve, a separate problem of data going missing.

How Norynt measures jitter

Norynt collects a series of small timing probes and runs the timing work off the browser's main thread, so that the page rendering or scripts running in your browser tab do not distort the measurement. Each probe records how long a short round trip took, and the series of these round trips is what jitter is calculated from.

Not every probe is trusted equally. If a probe was delayed because the browser tab itself was busy — for example, because it lost focus or the device was under heavy load elsewhere — that delay reflects your computer's scheduling, not your network, and the probe is discarded rather than allowed to inflate the result. If too few trustworthy probes remain, Norynt will not publish a misleading figure built from too little reliable data.

Because Wi-Fi and long, congested paths are common sources of uneven timing, it is worth checking a jitter result against two simple comparisons: testing over a wired Ethernet connection instead of Wi-Fi, and testing again with your device placed close to the router. If jitter drops sharply in either case, that link was likely contributing to the unevenness measured in the original test.