What is jitter on a speed test?

Jitter describes how much latency changes between retained probes. It complements the central latency result by showing whether timing stayed consistent during that test path.

What is the difference between ping and jitter?

Ping or latency summarizes round-trip delay to the selected endpoint. Jitter summarizes variation between probe timings. Both depend on the route, endpoint, test method, and whether the connection is idle or loaded.

What is a good jitter result?

There is no universal good, usable, or bad band. Compare the measured path with the versioned editorial planning ceiling for the activity, repeat the test, inspect loaded latency, and verify the real application.

Is SwiftSpeedTest probe loss the same as packet loss?

No. It is the share of SwiftSpeedTest application-level HTTP latency probes that did not complete. It is not ICMP packet loss or a complete network-loss measurement.

Latency measurement guide

Ping vs jitter: what the numbers actually mean

Latency tells you about round-trip delay on the selected path. Jitter tells you how consistent those probe timings were. Neither becomes a universal connection grade without the workload, endpoint, load state, and repeat evidence.

Updated July 24, 2026No app requiredBrowser-based speed test

Idle and loaded latency answer different questions

Jitter is route- and method-specific

Planning ceilings come from dataset 2026.07.24

Definitions

Delay, variation, tail behavior, and probe completion

Idle latency: Round-trip timing to the selected test endpoint while transfer traffic is not intentionally loading the connection.
Jitter: Variation between consecutive retained latency probes. It shows timing consistency for this sample.
Loaded latency: Latency sampled while download or upload traffic is actively using the connection.
Application-probe loss: The share of this test's HTTP latency probes that failed. It is not a complete packet-loss test.

SwiftSpeedTest method 2.1

The displayed values are robust summaries, not one probe

The test warms the endpoint, collects multiple HTTP probes, and requires enough valid measurements before reporting latency.
The central idle latency uses retained stable samples; extreme samples do not silently become the whole result.
Jitter is calculated from consecutive retained probe differences, while p95 tail latency preserves evidence about slower samples.
Separate probes run during download and upload to show how queueing changes responsiveness under load.

Read the complete sampling, trimming, endpoint, and limitation details in the measurement methodology.

Versioned workload planning

Planning ceilings are activity-specific, not universal grades

Dataset 2026.07.24, updated 2026-07-24, uses editorial planning ceilings for these latency-sensitive activities. A value at or below a ceiling does not guarantee success, and a value above it does not prove the access line is the cause.

Activity	Editorial ping ceiling	Editorial jitter ceiling	Evidence basis
HD video call	100 ms	30 ms	Rounded planning baseline informed by official 1080p video-call requirements.
Online gaming	50 ms	15 ms	Editorial gameplay baseline; title, platform, and route conditions vary.
1080p livestream upload	80 ms	20 ms	Conservative editorial baseline informed by official broadcast bitrate guidance.

Download the versioned JSON.

Diagnostic workflow

Compare paths and load states before assigning a cause

1. Repeat the idle test with the same endpoint and device. Keep the individual results and confidence.
2. Compare idle with download-loaded and upload-loaded latency. A large increase under load points toward queueing on the tested path.
3. Compare Ethernet and Wi-Fi on the same device. Improvement on Ethernet implicates the local wireless path, not automatically the provider.
4. Test the real game, call, or livestream and use its own region, call-health, or connection telemetry when available.
5. Repeat at another time. Route and congestion patterns that recur are stronger evidence than one labeled grade.

Versioned data

Checked July 24, 2026. These values are transparent editorial planning inputs, not universal strong, usable, or bad bands.

https://swiftspeedtest.com/data/internet-speed-requirements/2026.07.24.json

Frequently asked questions

Quick answers about this topic

What is jitter on a speed test?: Jitter describes how much latency changes between retained probes. It complements the central latency result by showing whether timing stayed consistent during that test path.
What is the difference between ping and jitter?: Ping or latency summarizes round-trip delay to the selected endpoint. Jitter summarizes variation between probe timings. Both depend on the route, endpoint, test method, and whether the connection is idle or loaded.
What is a good jitter result?: There is no universal good, usable, or bad band. Compare the measured path with the versioned editorial planning ceiling for the activity, repeat the test, inspect loaded latency, and verify the real application.
Is SwiftSpeedTest probe loss the same as packet loss?: No. It is the share of SwiftSpeedTest application-level HTTP latency probes that did not complete. It is not ICMP packet loss or a complete network-loss measurement.

Related guides

Keep going with the next best page

Internet speed-test results explained

Read throughput, idle latency, loaded latency, jitter, and confidence together.

Gaming latency concepts

Map these measurements to an online game without duplicating the test workflow.

Video-call evidence guide

Compare vendor bandwidth guidance with a versioned call-planning row.

Compare idle and loaded responsiveness

Run a test, preserve the endpoint and confidence details, then repeat under the real workload instead of grading one ping or jitter number.

Check ping and jitter Browse more guides