A speed test measures jitter by sending a short series of small packets, timing each one, and reporting how much those timings vary. A low number means packets arrive at an even pace. A high number means some arrive late, and that is what makes calls choppy and games rubber-band even when your download speed looks great. Below, we explain how the measurement works, what counts as good, why one reading can mislead you, and how to test properly.
TL;DR
- Jitter is the variation in packet delay, shown in milliseconds. It is not the same as ping, which is the average delay.
- Under about 30 ms is the usual ceiling for voice, and video calls tolerate roughly 30 to 50 ms before quality drops, according to Zoom's guidance.
- Tools calculate jitter in different ways, so compare numbers from the same tool, not across tools.
- A reading on an idle connection can look perfect and fail once someone starts a stream or call. Test under load.
- One test is a snapshot. Repeat it at different hours before you blame your ISP.
Table of Contents
- What jitter actually measures
- How speed tests measure jitter
- What counts as good jitter
- Why jitter hurts: the de-jitter buffer
- How to run a jitter test you can trust
- Perspective: what we see in jitter results
- Choosing a tool for jitter tests
- Jitter for specific uses
- When to call your ISP
- FAQ
- Sources
What jitter actually measures
Every packet that crosses the internet takes a little time to arrive. If each one took exactly 40 ms, jitter would be zero. In real life one takes 38 ms, the next 61 ms, the next 40 ms. The average may still look fine, but the spread is the problem.
Standards bodies are a bit more precise. RFC 5481 uses the term "delay variation" for metrics that quantify how consistently a path delivers packets, and notes that some people call the same phenomenon jitter. Engineers often write PDV, short for packet delay variation. When a speed test says "jitter," it means this.
Why average ping hides it
People tend to read average latency as connection quality. Cloudflare's engineering blog makes the point that the variation around that average is what produces choppy streams and calls. Take two connections that both show a 47 ms average. One delivers every packet between 45 and 49 ms. The other swings between 28 and 85 ms. On a spreadsheet they look identical. On a video call, only one of them works.
How speed tests measure jitter
Most browser and app tests follow the same outline:
- Send a burst of small packets to a nearby test server, often over UDP.
- Record how long each packet takes, or how long the round trip takes.
- Reduce those timings to one number.
The third step is where tools differ. RFC 5481 describes delay variation as a comparison of individual packet delays against a reference, commonly the packet with the minimum delay in the sample. Other tools simply report the gap between the slowest and fastest ping. Others average the difference between consecutive packets. The FCC's mobile speed test app documents its own method, which uses up to 200 UDP packets over a fixed interval.
The practical consequence: a jitter of 8 ms on one site and 14 ms on another, tested minutes apart, does not mean your line changed. The tools may be doing different arithmetic. Pick one tool, keep the settings the same, and compare your own results over time.
Idle versus loaded jitter
Most tests measure jitter while nothing else is happening. That is the best case. The harder question is what happens when your upload is saturated by a backup, a stream or a family member's video call.
Cloudflare's analysis notes that high jitter is often a symptom of bufferbloat, which is excess queuing in routers when the connection is busy. It also argues that tests should report performance under load, not only when idle. A line can look flawless when empty and fall apart the moment a stream starts.
The effect shows up quickly in anything timing-sensitive, such as low-bandwidth online chess, where a move delayed by a router queue can cost you a bullet game even though your raw speed is fine. Real-time video and voice are less forgiving still.
What counts as good jitter
There is no single legal threshold. There are rules of thumb that vendors and standards groups repeat. Zoom's guidance lists these tolerances:
| Use | Jitter ceiling before quality suffers |
|---|---|
| VoIP calls | under 30 ms |
| Video calls | 30 to 50 ms |
| Streaming media | under 100 ms |
| General downloads | under 100 ms |
Those are ceilings, not targets. For gaming and live production, you want to sit well below them. As a working guide of our own, single digits are comfortable for nearly everything, 10 to 30 ms is workable but worth watching, and anything that regularly passes 30 ms deserves investigation.
Answering the common questions
Is 25 ms jitter good? It is inside the usual voice ceiling, so calls may be fine. For competitive gaming or a live broadcast, it is high enough to notice.
Is 2 ms jitter bad? No. That is excellent, and a wired connection to a healthy ISP often looks like this.
Why does streaming tolerate more? Players buffer seconds of video ahead of time. Voice and games can't wait, so they have far less room.
Why jitter hurts: the de-jitter buffer
Real-time apps defend themselves with a de-jitter buffer. ITU-T G.114 deals with transmission time and the planning of voice networks. The buffer holds incoming packets briefly and plays them out at a steady rate. If jitter is larger than the buffer can absorb, late packets are dropped, and the listener hears glitchy audio.
That explains two things people often notice. First, jitter shows up as packet loss even though no packet was lost in the network. Second, a bigger buffer smooths things but adds delay, so apps keep it small and hope your connection cooperates.
How to run a jitter test you can trust
A single click gives you a number. A proper routine gives you a diagnosis.
- Use a wired connection first. Plug a laptop into the router with Ethernet. This sets your baseline without Wi-Fi interference.
- Close background traffic. Pause cloud backups, updates and other streams, then test.
- Test again on Wi-Fi in the room where you actually work or play. A large gap between wired and Wi-Fi points at your wireless setup, not your ISP.
- Test under load. Start a large upload or a video call, then run the test again. If jitter climbs sharply, suspect bufferbloat. Our bufferbloat test methods walk through this.
- Repeat at different times. Evening peaks reveal congestion that a midday test misses.
- Log the results. Keep date, time, connection type and numbers so you can show a pattern.
Continuous monitoring beats occasional checks for intermittent problems, since a single point-in-time test can miss congestion spikes. That is why history matters more than any one reading.
Reading the result
| Pattern | Likely cause | First thing to try |
|---|---|---|
| High jitter on Wi-Fi, low on Ethernet | Interference or weak signal | Move closer, change channel, or use a wired link |
| Low idle jitter, high loaded jitter | Bufferbloat | Enable smart queue management on the router if it supports it |
| High jitter everywhere, worse in the evening | Congestion on the ISP side | Log results and contact the ISP with evidence |
| Random spikes at all hours | Faulty cable, modem or noisy line | Swap cables, reboot, ask the ISP to check the line |
If the problem is voice specifically, our guides on fixing VoIP jitter and the tests engineers run before calling an ISP go step by step.
Perspective: what we see in jitter results
We build GrandSpeed because a download number alone tells you very little about whether a video call or stream will hold up. The questions people bring us are rarely "how fast is my line?" They are "why does my call freeze when the speed test says 500 Mbps?" Nearly always, the answer sits in the quality metrics: jitter, packet loss, bufferbloat and DNS time, not the headline speed.
Our view is that jitter should never be read alone. A jitter figure beside latency, packet loss and a loaded test tells a story. A jitter figure on its own invites guesses. We also think the useful question is task-specific: a 20 ms reading can be fine for a webinar and a problem for a multi-camera live stream. That is why we built tests around streaming, conferencing, gaming, VoIP and remote work, and why we keep a history of results, so you can see whether Tuesday evenings are the problem.
— Peter D
Choosing a tool for jitter tests
When you pick a test, check for these:
- Jitter and latency reported together, not just speed.
- Loaded measurements, or at least a way to test while the line is busy.
- Packet loss and bufferbloat alongside jitter, since the three are linked.
- History, so you can compare readings across days.
- Works on the device you use, including phone on Wi-Fi and cellular.
Our speed test covers download, upload, latency, jitter, packet loss, bufferbloat and DNS resolution in a browser, on a phone, tablet or laptop, and stores your results so you can track them. If you stream or broadcast, the Livestream Upload Speed Monitor watches upload stability, which is where jitter often bites live video first. For viewing quality, the Video Streaming Quality Test shows what resolution your connection supports.
Jitter for specific uses
Video calls and remote work
Audio degrades first. If people tell you that you sound robotic, check jitter and packet loss before you check speed. A wired connection and a quiet network usually fix most of it. If you work from home, test at the hours when your meetings actually happen.
Online gaming
Gamers notice jitter as rubber-banding: your character snaps back after moving. Low average ping with high jitter feels worse than a slightly higher but steady ping. Test while a download or stream is running in the house, since that is when it usually surfaces.
Live streaming
Streaming software has to push video upstream continuously. Unstable upload timing can cause dropped frames and encoder warnings. Check upload speed and jitter together, and leave headroom. Our multi-camera livestreaming guide covers how bandwidth needs add up, and the video bitrate planner helps you match your bitrate to what your upload can actually hold steady. If upload is the weak spot, see why your upload speed may be slow.
When to call your ISP
Call when you have evidence, not a single bad reading. A useful report includes:
- Results from a wired connection, so they cannot blame your Wi-Fi.
- At least several days of tests, with times.
- Idle and loaded results.
- Any pattern, such as evenings only.
If the wired jitter is high at all hours with only your device connected, the fault is likely outside your home network. If it is high only under load, your own router's queue management is the first suspect, and many routers can be fixed with a setting.
FAQ
What is a good jitter on a speed test?
For most people, single digits are comfortable and under 30 ms is workable for voice and video calls. Gaming and live streaming are more sensitive, so lower is better. Compare numbers from the same tool, since tools calculate jitter differently.
How do you measure jitter?
A test sends a series of packets, records the delay of each, and reports the variation between them. Some tools use the gap between the fastest and slowest packet, others compare each packet to a reference. The IETF's RFC 5481 describes the underlying idea as packet delay variation.
Is jitter the same as ping?
No. Ping, or latency, is how long a packet takes on average. Jitter is how much that time varies. You can have low ping and high jitter, which is why a connection can seem fast and still make calls choppy.
Why is my jitter high only sometimes?
Intermittent jitter usually points to congestion, Wi-Fi interference or bufferbloat when the connection is busy. Test at different times, on Ethernet and Wi-Fi, and with and without load. Logging the results shows you which one it is.
Sources
- RFC 5481: Packet Delay Variation Applicability Statement
- Cloudflare Blog: Measuring network quality to better understand the end-user experience
- FCC 2022 Speed Test App technical description
- ITU-T Rec. G.114, One-way transmission time
- Zoom: What is jitter on a speed test and how do you fix it?