Methodology

How HowFast measures your connection, how each number is calculated, and how the ratings are decided. Everything on this page is generated from, or checked against, the code that runs the test.

Updated October 11, 2026

What happens during a test

The test runs in your browser and talks only to HowFast's own test servers. It never sends traffic or results to a third-party speed test service. A Standard test goes through these steps:

Connect. The browser asks the server for your network details and a short-lived test session (valid for 10 minutes).
Warm up. A few small requests open the connection, and one 100 kB download gives a first speed estimate.
Idle latency. 20 tiny requests measure delay while nothing else is using the line.
Download and upload rounds. Requests grow in size, alternating between directions, from 100 kB up to250 MB for download and 50 MB for upload, until the data budget for your chosen mode is reached. Small latency checks run between rounds.
Latency under load. While download and upload rounds run, a separate server is pinged every 400 ms.
Detailed mode only: an extra phase with four parallel connections per direction.
Finish. The samples are filtered and summarised, confidence and ratings are worked out, and the result is saved to the history in your browser (you can turn this off).

All timings come from the browser's Resource Timing data for each request, not from JavaScript timers, so a busy page does not stretch the measured durations. The time the server spends preparing a response is reported back in a Server-Timing header and subtracted.

Download and upload speed

In plain language: how many megabits per second your connection moved. Each request is timed, and the headline is a high but typical value from the valid requests.

Mbps = (8 × bytes transferred) ÷ (adjusted duration in ms × 1,000) adjusted duration = end − start − server processing time

Download is timed from the moment the request is sent to the last byte received.
Upload is timed from the moment the request starts until the server's first response byte, which arrives once it has received the whole body.
A request counts only if its adjusted duration is at least 10 ms and it transferred data. Shorter ones are too quick to time reliably.
The first request in each direction is a warm-up and is left out, because a new connection starts slowly (TCP slow start).
A request more than 3× faster than the median of requests of the same size is an outlier and is left out. Excluded requests are counted in the Diagnostics panel.
The headline is the 90th percentile of the valid requests (nearest-rank method). The Diagnostics panel also shows the median and the number of samples.
With fewer than 3 valid requests the tile shows Not enough data instead of a number.
In Detailed mode, each round of the parallel phase sends four requests at once; its speed is total bytes ÷ wall-clock time. The multi-connection result is the median of those rounds. It is shown separately and never replaces the single-connection headline.

Latency and jitter

In plain language: latency (often called ping) is how long a tiny request takes to get to the server and back. Jitter is how much that delay jumps around from one request to the next.

latencyᵢ = response start − request start − server time jitter = ( |L₂ − L₁| + |L₃ − L₂| + … + |Lₙ − Lₙ₋₁| ) ÷ (n − 1)

The headline latency is the median of the idle requests. Diagnostics also shows the minimum and the 95th percentile (nearest rank).
Jitter uses consecutive requests in the order they were sent, the same definition as Cloudflare's open-source engine, so values are comparable.
Latency and jitter need at least 5 valid requests. Fewer shows Not enough data.
Browser latency includes a little time inside your browser and device, so it is usually a few milliseconds higher than a command-line ping.

Latency under load

In plain language: the same delay measurement, taken while your line is busy downloading or uploading.

Probes go to a separate latency server every 400 ms during the download and upload rounds.
A probe counts only if it overlapped a transfer of at least 250 ms in that direction. Probes that fall between short requests do not reflect a busy line and are dropped.
The latest 20 valid probes per direction are kept (40 in Detailed mode), and at least 5 are needed. On very fast connections the transfers can finish too quickly to load the line, and the result reads Insufficient data.

Bufferbloat grade

In plain language: how much extra delay appears when the line is busy. A big increase means your router or modem is queuing too much data, which makes calls and games lag whenever someone else is downloading or uploading.

increase = max(0, median loaded latency − median idle latency)

Grade	Latency increase under load	What it means
A+	5 ms or less	Excellent queue management
A	Over 5 to 30 ms	Very good
B	Over 30 to 60 ms	Noticeable in competitive gaming
C	Over 60 to 200 ms	Calls and games degrade when the line is busy
D	Over 200 to 400 ms	Severe lag under load
F	Over 400 ms	Unusable for real-time apps while transferring

Download and upload are graded separately. The overall grade is the worse of the two; if both get the same grade, the direction with the bigger increase is shown.
If only one direction could be measured, its grade is shown with Low confidence.
A grade appears only when both the idle set and the loaded set have at least 5 valid samples.
The grade is an indicator, not a laboratory classification. Some tools load the line continuously for a fixed time; this test loads it in bursts of increasing size, so a short burst may not fill a very large buffer.

Packet loss

In plain language: the share of small messages that never arrive. Even 1–2% can make calls choppy and games stutter.

loss = (messages sent − messages received) ÷ messages sent

Measuring loss from a browser needs a relay server (TURN) that bounces small messages back over UDP. That relay is not switched on yet, so the Packet loss tile reads Not available with the reason "Packet loss test is not enabled yet". We do not estimate or fill in a value. Ratings that use packet loss treat it as optional (see Online gaming below).

Confidence levels

Each number carries High, Medium or Low confidence, based on how many valid samples there were and how much they varied. The coefficient of variation (CV) is the standard deviation divided by the mean.

Level	Download and upload	Latency
High	At least 6 valid samples and CV at most 0.25	At least 15 samples and 95th percentile minus median at most 20 ms
Medium	At least 3 samples and CV at most 0.5	At least 8 samples
Low	Anything else that still produced a value	At least 5 samples

Any of the warnings listed under Warnings about a result lowers every metric of that result to Low.

What your connection can handle

The dashboard rates seven everyday uses as Great, Good, Fair or Poor. These thresholds are product decisions, published here and versioned: this is rubric version 1. If a threshold changes, the version number changes with it.

A use case gets the lowest rating that any of its required metrics reaches. The chip names the metric that held it back.
If a required metric is missing, the use case reads Not rated with the reason, for example "Upload did not finish".
If an optional metric is missing (packet loss for gaming), the rating is worked out without it and capped at Good, with the note "Packet loss not measured".
If the metric that decided the rating has Low confidence, the chip says so.

4K streaming

Metric	Great	Good	Fair	Poor
Download	50 Mbps or more	25 to under 50 Mbps	15 to under 25 Mbps	Under 15 Mbps

HD streaming

Metric	Great	Good	Fair	Poor
Download	15 Mbps or more	8 to under 15 Mbps	5 to under 8 Mbps	Under 5 Mbps

Online gaming

Metric	Great	Good	Fair	Poor
Idle latency	20 ms or less	Over 20 to 40 ms	Over 40 to 80 ms	Over 80 ms
Jitter	5 ms or less	Over 5 to 10 ms	Over 10 to 20 ms	Over 20 ms
Bufferbloat increase (worse direction)	30 ms or less	Over 30 to 60 ms	Over 60 to 200 ms	Over 200 ms
Packet loss (optional)	Under 0.5%	0.5% to 1%	Over 1% to 2.5%	Over 2.5%

Video calls

Metric	Great	Good	Fair	Poor
Upload	10 Mbps or more	4 to under 10 Mbps	2 to under 4 Mbps	Under 2 Mbps
Download	10 Mbps or more	4 to under 10 Mbps	2 to under 4 Mbps	Under 2 Mbps
Idle latency	50 ms or less	Over 50 to 100 ms	Over 100 to 150 ms	Over 150 ms
Jitter	10 ms or less	Over 10 to 20 ms	Over 20 to 30 ms	Over 30 ms
Latency increase while uploading	60 ms or less	Over 60 to 150 ms	Over 150 to 300 ms	Over 300 ms

Working from home

Metric	Great	Good	Fair	Poor
Video calls rating	Great	Good	Fair	Poor
Download	50 Mbps or more	25 to under 50 Mbps	10 to under 25 Mbps	Under 10 Mbps
Upload	10 Mbps or more	5 to under 10 Mbps	3 to under 5 Mbps	Under 3 Mbps

Many devices

Metric	Great	Good	Fair	Poor
Download	300 Mbps or more	100 to under 300 Mbps	50 to under 100 Mbps	Under 50 Mbps
Upload	30 Mbps or more	10 to under 30 Mbps	5 to under 10 Mbps	Under 5 Mbps
Bufferbloat grade	A+ or A	B	C	D or F

Large downloads and uploads

Metric	Great	Good	Fair	Poor
Download	500 Mbps or more	200 to under 500 Mbps	50 to under 200 Mbps	Under 50 Mbps
Upload	100 Mbps or more	20 to under 100 Mbps	5 to under 20 Mbps	Under 5 Mbps

The one-line summary

The sentence at the top of a finished result is picked by these rules, checked in order. The first one that matches is shown. If nothing could be rated, no sentence is shown.

#	When	Sentence
1	Every use case is rated Great.	“Excellent for everything you are likely to do online.”
2	HD streaming is Good or better, and gaming or video calls is Fair or worse because of bufferbloat.	“Great for streaming. Calls and games may lag when someone else is uploading or downloading.”
3	HD streaming is rated Poor.	“Slower than most streaming services need for HD video.”
4	Video calls is rated Poor and upload is the limiting metric.	“Upload is too slow for reliable video calls.”
5	Gaming is Fair or worse and idle latency is the limiting metric.	“Fine for streaming, but the delay is high for fast online games.”
6	Gaming or video calls is Fair or worse and jitter is the limiting metric.	“Your connection is uneven, so calls and games may stutter. A wired connection often helps.”
7	HD streaming is Good or better and video calls is Fair or worse.	“Good for streaming. Video calls may sometimes freeze or blur.”
8	HD streaming is Good or better and many devices is Fair or worse.	“Good for one or two people at a time. A busy household may notice slowdowns.”
9	Large downloads and uploads is Great and everything else is Good or better.	“Very fast. Large downloads and uploads finish quickly.”
10	Every use case is Good or better.	“Good for everyday use, including HD streaming and video calls.”
11	HD streaming is Good or better and 4K streaming is Fair or worse.	“Good for HD video. 4K streaming may buffer.”
12	None of the above applies.	“Fine for browsing and basic streaming. Demanding tasks may struggle.”

Warnings about a result

Some conditions make a result less trustworthy. When one is detected, the dashboard shows a note and lowers confidence on every metric to Low.

Note shown	When it appears
The tab was in the background during the test. Results may be low.	The page was hidden (another tab or app in front) at any point during the test. Browsers slow down background tabs.
This speed is higher than any home connection. The result may be wrong.	Download or upload above 10,000 Mbps.
Latency is lower than physically likely. The result may be wrong.	Median idle latency under 1 ms.
Browser or device overhead may be adding delay.	The network round trip seen by the server and the median latency measured in the browser differ by more than 30 ms.
Many requests failed or were retried. Results may be low.	More than 20% of requests in one direction failed or were retried.
Mobile data: results vary with signal.	The browser reports a cellular connection (only some browsers expose this).
You may be on a VPN or proxy.	Your network (AS) name matches a bundled list of VPN and hosting providers. Results then describe the tunnel, not your line.
Your device was busy during the test. Results may be low.	The page's main thread was blocked for more than 200 ms at a time while the test ran.

Test modes and data use

A speed test has to move real data to measure your speed. The dashboard tells you the maximum before you start and counts the bytes as they go.

Mode	Data	Largest request	Loaded-latency points	Parallel phase
Standard	Uses up to 200 MB	250 MB down, 50 MB up	20 per direction	No
Reduced data	Uses up to 25 MB	10 MB down, 10 MB up	20 per direction	No
Detailed	Uses up to 600 MB	250 MB down, 50 MB up	40 per direction	Yes, 4 connections

Reduced data is selected for you when your browser reports Data Saver, a cellular connection, or a slow connection type. Slower connections use less than the maximum because the rounds stop growing once requests take long enough to time well.

Your network details

IP address: read by the test server so it can show it to you. Our code does not write it to logs, analytics or a database. See the Privacy policy.
Provider: the network (autonomous system) your connection comes from, with its registered name, taken from the hosting network's request metadata.
Location: approximate, city level, derived from your IP address. The browser's location permission is never requested. Where the server has no such data, the card says so.
Server: the test location that handled your test.

Limitations

Results describe the path between your device and our nearest test location at the moment of the test. They do not predict the performance of a specific app, game or website, and they are not a guarantee.
Wi-Fi, other devices on your network, browser extensions, VPNs and a busy device all affect the result. A wired test on an otherwise idle network is the best measure of your plan.
A single browser connection can fall short of very fast plans (roughly above 1 Gbps). Detailed mode adds a multi-connection figure for that reason.
Upload timing relies on the server's first response byte, so it can read slightly high on some proxies and networks.
Bufferbloat is tested with bursts, not a sustained full load, so it may understate very large buffers.
Packet loss is not measured until the relay server is switched on.
Provider and location come from IP-address data and can be wrong, especially on mobile networks and VPNs.