Download and upload: sustained HTTP transfers
The Internet Speed Test uses our pinned adaptive-capacity-v1 browser engine, result version 4. It downloads and uploads payloads through https://speed.cloudflare.com/__down and /__up. These are HTTP measurements along the route your browser takes to that service, not a direct reading of your broadband contract or every destination.
The test first collects idle HTTP latency samples, then measures download and upload separately. Each direction has a warm-up before its measured window. Request sizes adapt to recent completed transfers; the engine uses two or four streams rather than relying on one tiny file or displaying the fastest instantaneous sample.
| Setting | Configured value |
|---|---|
| Warm-up per direction | 2 seconds; its bytes are excluded from the final speed |
| Measured window per direction | At least 8 seconds; may extend to 14 seconds when recent samples remain variable |
| Transfer streams | 2–4; chosen after warm-up within the configured limit |
| Adaptive payload size | 32,000–8,000,000 bytes per request; initial download 256,000 bytes and initial upload 64,000 bytes |
| Transfer request timeout | 20 seconds; up to 6 seconds of bounded completion/drain time per stage |
| Payload reservation ceiling | 750,000,000 download bytes and 500,000,000 upload bytes, shared by warm-up and measurement in each direction |
| Idle latency | 5 successful one-byte download probes, with at most 8 attempts and a 3-second timeout per attempt |
| Loaded latency sampling | Approximately once per second during measurement, with no overlapping latency probe from the same stage |
The payload ceilings are 750 MB down and 500 MB up in decimal units, not a fixed amount every run uses. A fast run can use a substantial data allowance. HTTP/TLS overhead, latency probes and acknowledgement traffic add to the payload figures. These settings describe measurement stages, not a guaranteed total completion time.
How the speed result is calculated
Download Mbps is verified payload bits received inside the measured window divided by that window’s elapsed time. The engine reconciles those bytes with completed response bodies; it does not count a cached or compressed file as a new full-speed transfer.
Upload Mbps uses payloads from successfully acknowledged POST requests and the elapsed interval covered by those completed requests. Browser send progress alone is not treated as proof that the provider received a payload. Acknowledgement timing and overhead can affect the estimate.
The displayed units are decimal megabits per second: 1 Mbps equals 1,000,000 bits per second, while a byte contains 8 bits. The Download Time Calculator separately handles file-size and rate conversions, including binary units.
Validation, stability and incomplete results
Download acceptance requires a successful full response, the expected payload length, no detected compression/cache hit, and compatible Resource Timing evidence for the transferred bytes. Upload acceptance requires a successful provider response, a consumed/verified acknowledgement and usable timing evidence. Transfers interrupted before verification do not become successful samples.
The engine looks for at least six near-one-second bins, then checks the last three: both their relative spread and first-to-last change must be within 10% for the stable-window stop rule. This is an internal stopping rule—not a statistical accuracy guarantee or confidence interval. A maximum-window result is marked variable. Reaching a data ceiling without enough sustained stable evidence can make the result inconclusive.
A complete result requires sustained verified download and upload data from at least two streams, at least two accepted transfers per direction, and the required idle-latency samples. Unsupported streaming/timing APIs, filtering, cached or mismatched payloads, rate limiting, timeouts and interrupted runs can prevent a complete result. An unavailable value is not zero speed or zero latency.
What latency and “jitter” mean here
Idle latency is the median of the successful one-byte HTTP probe durations. Each duration includes browser scheduling and applicable connection, network and server work. It is not ICMP ping to your router or the latency of every game server.
The homepage’s jitter value is the mean absolute difference between adjacent successful idle samples. Download-loaded and upload-loaded latency are the medians of successful probes taken while those transfers are active. Their difference from idle latency describes additional delay observed in this test; it does not by itself locate the bottleneck.
The speed widget offers COPY and Download test details. Its diagnostics include the measurement method/configuration and accepted transfer evidence so a completed result or failure can be examined. Review a file before sharing it. Simulated engineering tests and browser behavior checks help verify code paths; they are not a physical-line calibration dataset.
Game pages and regional HTTP comparisons
The 32 game pages compare HTTPS requests to 29 AWS DynamoDB regional API endpoints. The game’s name provides troubleshooting context; these endpoints are not the game’s actual match servers. The pages do not measure ICMP round-trip time, UDP packet loss, frame time, matchmaking quality or the route of your next match.
| Tool | Request pattern | Timing and limits |
|---|---|---|
| 31 game pages | Up to 3 attempts per region; 87 attempts across 29 regions | At most 6 active requests; 2.5-second timeout; latest successful HTTP timing and median of successful regional samples |
| Fortnite | Up to 4 attempts per region; 116 attempts across 29 regions | At most 3 active requests; 4-second timeout; successful sample median with attempt counts |
| Server Ping Test | Manual three-round regional comparison | The same bounded 3-attempt, 6-active, 2.5-second regional method; not a ping to an arbitrary entered host |
| Gamer Speed Test regional section | One screening attempt per region, then up to 8 attempts for each of the 3 best available candidates; at most 53 attempts | At most 6 active screening requests, then at most 3 candidate requests; a candidate needs at least 4 successful deep samples before a winner can be selected |
Regional requests use unique query values, no-store caching and omitted credentials. Because they use no-cors, the browser exposes an opaque response and hides its HTTP status. A fulfilled fetch times availability of response headers, not a full response-body download or proof of a successful server status. Rejections and timeouts are unavailable samples, never fast success values.
Game pages automatically start one bounded sample after their controls are ready, when the tab is visible and online. Use Stop Test to cancel; after completion, Start Test runs a new sample. An active run stops when the page is hidden, goes offline or is left. Stopping a run does not cause it to resume automatically. The separate Server Ping and Gamer Speed tools keep manual controls.
The Gamer Speed Test’s optional connection snapshot combines entered bandwidth values with a successful regional HTTP sample. Its grade is an informal comparison heuristic, not a certification of gaming quality. Confirm real match ping, packet loss and frame-time symptoms using the game’s own telemetry or official diagnostic tools.
Connection stability: one selected HTTP endpoint
The Connection Stability Monitor keeps its established URL. Select one of the same 29 AWS regional endpoints and manually choose a 1-, 3- or 5-minute run. The selected destination is shown; the monitor does not first contact every region to choose a location for you.
The monitor sends HEAD requests: timing ends when the browser receives the response headers, without downloading the response body. Only one request is active at a time, with starts at least one second apart and a 2.5-second timeout that aborts the request. The opaque response hides HTTP status, so a fulfilled fetch is not proof of a successful status code. The run reports the mean and maximum successful fetch timing, plus the mean absolute change between adjacent successful samples. A failed/timed-out sample breaks the adjacency pair. The graph shows the most recent 90 samples, with gaps for failures.
HTTP failure percentage is failed plus timed-out completed probes divided by all completed successful, failed and timed-out probes. A visitor stop, the end of the chosen duration or a hidden/offline/page-leave cancellation is not counted as a network failure. No completed samples means an unavailable percentage. A displayed 0% means no counted HTTP failures in that sample, not proof of zero network packet loss.
The monitor does not calculate UDP/ICMP packet loss or issue a gaming quality grade. It stops on a manual Stop, when the chosen duration expires, when hidden/offline or when the page is left; it does not automatically resume.
Focused checks and calculators
The Bufferbloat Test reuses the current browser capacity engine and compares idle with loaded HTTP latency. It does not directly inspect a router queue or assign a universal bufferbloat grade. The Video Call Speed Test compares measured capacity with labeled planning estimates; it does not make a Zoom, Meet or Teams call or validate a service-level guarantee.
The WiFi Room Comparison records repeat browser runs in the current session for the room labels you enter. Use the same device and conditions. It does not read radio signal strength, scan nearby networks or obtain a GPS location.
The Household Bandwidth Calculator, Streaming Bitrate Calculator, Download Time Calculator and Gaming Data Usage Calculator calculate scenarios from the values and assumptions shown. They do not observe your actual household traffic. Planning estimates, application requirements and measured speeds are different kinds of information.
Camera planning and guided troubleshooting
The Security Camera Bandwidth Calculator separates simultaneous stream demand from daily video payload. Its decimal GB/day formula is the sum of camera count × bitrate in Mbps × daily upload hours × 0.45. Spare capacity changes only the capacity estimate; it does not inflate camera data use. The retention value is a video-payload equivalent, not a guaranteed storage requirement. The tool shows its assumptions, manufacturer sources and a mathematical worked example.
The Slow Internet Troubleshooter uses your answers to prioritize comparisons. It does not contact your router, scan your Wi-Fi or establish a cause. Both tools work locally and wait for your input. With Analytics allowed, their start and completion event types can be counted with the tool name; they do not add your answers, entered values or results to those events.
Make a useful comparison
- Use the same device, browser, connection type and physical location for the baseline. Record whether a VPN is active and whether other transfers are running.
- For a broadband-capacity check, use a capable wired connection when practical. For a WiFi problem, compare the same device at the router and at the problem location.
- Change one condition at a time. Repeat the run rather than treating one high or low number as a permanent property of the connection.
- Compare real app/game telemetry separately. Different endpoints, routes, load patterns and aggregation can produce different valid results.
Run a fair comparison and keep a useful record
Use these blank worksheets to compare testing services or two devices. They contain no connection results. Record measurements you actually observe and keep failed or incomplete runs in the log; leave unavailable numbers blank.
CSV files open in common spreadsheet apps. Use anonymous labels such as Device A and Room A; review the file before sharing it.
Compare testing services on one connection
- Check each service's data notice. Our full test can use up to 1.25 GB plus overhead per run; repeated comparisons can use substantial data.
- Keep the same device, browser, location and connection. Record whether a VPN or background transfers are active. Run one service at a time.
- Choose the services before testing. For three services, alternate the order across rounds: A/B/C, B/C/A, then C/A/B. Record the time, service settings and endpoint label when available. A settings or endpoint change belongs in the notes.
- Compare the median of successful comparable runs within each service, and state the number of successful and incomplete runs. A median summarizes this sample; it is not an accuracy certificate.
- Label latency methods separately. Idle HTTP, loaded HTTP, ICMP and actual game telemetry are different measurements. A difference between services alone does not identify throttling or a faulty service.
Compare a laptop with a phone
- Start in the same room, using the same service, Wi-Fi network and band when you can confirm it. Record unconfirmed settings rather than guessing. Each device's browser and hardware remain part of the comparison.
- Alternate Device A and Device B for three rounds. Pause other transfers and record VPN or relay use. Keep both devices in the same position where practical.
- Next change one condition, such as the laptop's location or a background transfer. Keep the second set separate. A wired laptop run is a separate connection condition, rather than a direct phone hardware comparison.
- Use Wi-Fi Room Comparison for same-device room checks and the Slow Internet Troubleshooter to choose your next check.
These are repeatable collection procedures and blank resources, not published experimental findings. A small set of tests on one connection cannot rank every provider, router or device.
Provider context: FAST.com's measurement explanation, Cloudflare's test methodology and Google's router-versus-device testing guidance. These services use their own methods and destinations.
What these results cannot establish
A single browser run cannot guarantee the advertised plan speed, identify an ISP’s motive, prove throttling, certify video-call/gaming quality or promise the same result as another testing service. It also cannot infer network packet loss from HTTP timing alone. An endpoint can be unavailable because of browser policy, filtering or the endpoint’s own behavior, so a failure is not automatically an ISP fault.
Measurement requests go directly to the stated endpoint providers, which receive connection information needed to handle them. Optional analytics and other site features have separate controls described in the privacy policy. No game login or game-account access is needed for these browser checks.
Review, corrections and version history
This is an implementation review of the live engine and the associated tool methods, not a claim of independent laboratory certification or a completed real-device calibration study. We update this page when measurement behavior changes. Report a reproducible discrepancy with the tool URL, device/browser, time, connection conditions and downloadable test details through the contact form; avoid including private account information.
- 2026-10-22.1: Added camera upload/data arithmetic and guided next-check documentation. Reviewed optional event measurement. The adaptive-capacity-v1 result version 4 measurement engine is unchanged.
- 2026-10-18.1: Documents adaptive-capacity-v1 result version 4, bounded regional HTTP comparisons, the selected-endpoint stability method and the focused diagnostic/calculator workflows.
Find the right next check in the Tools directory, or read the troubleshooting guides.