Methodology · Method 2.2
How SwiftSpeedTest measures your connection
SwiftSpeedTest is a browser-based capacity and responsiveness diagnostic. Method 2.2 adapts transfer size and concurrency, measures latency both at idle and under load, and reports the sample quality needed to interpret the result.
Last updated November 5, 2026
Scope
What the test measures
Every primary result describes traffic between this browser and one selected SwiftSpeedTest-compatible endpoint. It does not measure the capacity of the internet as a whole.
Download capacity
The usable bits received by the browser divided by transfer time, reported in megabits per second (Mbps).
Upload capacity
The browser-known payload bytes acknowledged by the endpoint divided by transfer time, reported in Mbps. The endpoint must report the exact payload size and successful receipt.
Idle responsiveness
Round-trip latency while the connection is otherwise quiet, plus variation between consecutive valid probes, including delay spikes.
Loaded responsiveness
Latency, jitter, and p95 tail latency sampled while download and upload traffic are actively using the connection.
Measurement protocol
The five stages of method 2.2
Choose and hold a test endpoint
The production endpoint set includes the nearest global Edge route plus pinned US East, Central, and West Edge routes. The nearest route is ready without background measurement traffic; choosing Auto compares the candidates and favors lower latency, steadier results, and better reachability. You can also select an endpoint manually. The chosen endpoint is held fixed for the measurement run so the result is not blended across servers.
Measure idle latency
After a warm-up request, the browser makes at least eight probes (12 by default) with varied spacing. At least five valid measurements are required. Each probe must complete its expected JSON response within the deadline. Reported latency subtracts valid declared endpoint processing time when that timing header is available.
Run adaptive download batches
The browser streams generated binary payloads with response compression disabled, verifies the received size, and measures from request start through full-body completion so buffered bytes are not counted without their transfer time. It reselects the next payload size from measured throughput while enforcing the active mode's time and byte budgets.
Run adaptive upload batches
The browser generates binary payloads locally and times each request until the server acknowledges completion, rather than stopping when the browser hands bytes to its upload buffer. Both download and upload include request overhead, so these are conservative application-throughput measurements, not a claim of raw line capacity. Uploads require a successful acknowledgement with the exact payload size. Payloads are capped at 4 MiB per request in full-capacity mode and can step down to 256 KiB if a host rejects a larger body.
Probe responsiveness under load
Separate application-level ping requests continue through each transfer direction, with about 400 ms between completed probes. A loaded probe must start during an active transfer batch. Its completed response or timeout still counts if the batch ends while it is pending, so slow responses are not silently removed. At least three successful samples and full transfer confidence in both directions are required before loaded responsiveness is marked available.
Current protocol parameters
- Automatic data mode
- Low-data mode is selected when the browser requests reduced data, the user selects Mobile data or Hotspot, the connection hint is constrained, or no useful network hint is available. A manual override remains available before a run.
- Low-data ceiling
- Up to 48 MiB download plus 4 MiB upload payload (about 52 MiB total), with one request at a time, at most four batches per direction, 12 MiB maximum download requests, and 1 MiB maximum upload requests
- Full-capacity ceiling
- Up to 768 MiB download plus 64 MiB upload payload (about 832 MiB total), with one to three download requests and one or two upload requests in parallel, based on the browser connection hint
- Download payload choices
- 1, 2, 6, 12, 25, 50, 75, or 100 MiB per request, limited by the active mode and remaining byte budget
- Upload payload choices
- 1, 2, or 4 MiB per request in full-capacity mode; up to 1 MiB in low-data mode; 256 KiB rejection fallback
- Transfer window
- 8-second target in standard full-capacity mode; 4.5 seconds in low-data mode or on a detected slow connection. Time, batch, and byte limits can end a run earlier. Full confidence additionally requires at least two valid batches and 5.5 seconds of transfer time in standard full-capacity mode, or 3 seconds in low-data mode or on a detected slow connection.
- Batch ceiling
- Up to 8 batches per direction, or 4 on a detected slow connection
- Loaded-latency probes
- Continue across active batches, 2.5-second timeout per probe, about 400 ms between probes
Computation
How raw samples become reported values
Throughput
Each batch is measured as total valid bytes divided by the elapsed time from the earliest request start through the latest full completion. Download timing includes connection setup and response buffering; upload timing includes the endpoint acknowledgement. Parallel request durations are not added as if they happened sequentially.
With at least three valid batches, the first batch is treated as warm-up and excluded. With at least five remaining samples, the implementation trims floor(15%) from each throughput tail. The reported Mbps is calculated from total retained bytes over total retained duration.
Latency, jitter, and p95
Latency uses a robust median. Samples far from the initial median are treated as outliers using a median-deviation threshold, provided enough samples remain. A 10% symmetric trim is applied when the retained set is large enough.
Jitter is the average absolute change between consecutive valid probes in their original order, including delay spikes excluded from the central median. Tail latency is the 95th percentile of all valid probes, including values that can be excluded from the central median.
Application-probe loss
The displayed loss percentage is failed idle and loaded HTTP latency probes divided by all attempted probes. It helps expose an unresponsive browser-to-endpoint path, but it must not be interpreted as raw packet loss across the network.
Result quality
Confidence, discarded samples, and grades
Download and upload confidence are tracked separately. A direction is marked full only when every attempted transfer request succeeds and passes validation, at least two retained batches complete, and retained transfer time reaches 3 seconds in low-data mode or on a detected slow connection, or 5.5 seconds in standard full-capacity mode; otherwise it is marked degraded. The interface and exports preserve successful and attempted request counts. Discarded warm-up and trimmed throughput samples do not count toward the duration or batch minimums. Full confidence describes these validation checks; it does not guarantee the capacity of an ISP connection or that the selected endpoint saturated the link.
Discarded latency samples are not hidden. The result records retained and discarded counts for both loaded directions. SwiftSpeedTest's responsiveness grade considers the loaded increase above idle, p95 tail increase, worst loaded jitter, discarded-sample ratio, and application-probe loss.
Loaded responsiveness is marked unavailable when either transfer direction produces fewer than three successful latency samples or has degraded transfer confidence. The app does not substitute idle latency or invent a loaded value in that case.
Data handling
Local history, exports, and share links
No account is required. Up to 100 completed results, including any optional provider or location labels you enter, are stored in this browser's local storage. The compact Results panel shows the newest 8; the full history tracker can analyze all retained results. Clearing history removes the local list. CSV and JSON exports are assembled in the browser and downloaded as local files.
A share link encodes the result, diagnostic fields, method version, and optional context in its URL fragment. A fragment is not sent to SwiftSpeedTest's origin or CDN in the normal HTTP request, but the receiving page, browser history, extensions, recipients, and sharing intermediaries can read the complete link. It is not a hosted or cryptographically verified result. Anyone can edit those values, so the interface labels opened share links as unverified. Legacy query-string share links remain readable for compatibility.
Printable internet connection support reports are also assembled in the browser. They include measurement confidence, loaded response, deterministic next steps, and a controlled retest protocol while omitting provider, custom-location, and test-server identifiers. The files are not uploaded as hosted reports or represented as signed evidence.
Test traffic still reaches the selected endpoint, and ordinary request logs or configured analytics may process limited operational data. See the privacy policy for that broader scope.
Interpretation
Known limitations
- The browser, device CPU and memory, power-saving mode, extensions, and other active applications can limit the measured rate.
- Wi-Fi signal quality, router placement, radio interference, VPNs, background transfers, and other household traffic can change the result.
- The path to the selected endpoint matters. Another test provider can use a different route, server location, capacity, and measurement protocol, so identical results are not expected.
- The built-in US regional routes are geographically pinned within the same Vercel deployment. They improve path comparison, but they are not independently operated provider or deployment fault domains.
- Application-probe loss is the percentage of SwiftSpeedTest HTTP latency probes that failed. It is not ICMP packet loss and is not a complete network-loss test.
- A result is a snapshot of one browser-to-endpoint path. It is not a guarantee of ISP performance, a measurement of every destination, or a legal, regulatory, or certified bandwidth audit.
- The test intentionally transfers data. Review the visible estimate before starting and use low-data mode on a limited or expensive plan. The estimate is a payload ceiling, not a billing guarantee; protocol overhead can add a little more.
- The built-in production rate limit is a per-runtime-instance backstop. A multi-instance deployment still needs provider-level or distributed abuse controls for a global quota.
Use comparisons, not one number
Repeat the test under the same conditions, compare Ethernet with Wi-Fi, and test before and after a change. If the result will support a billing or service dispute, also collect measurements from another reputable protocol and follow your provider or regulator's required procedure.
Publishing policy
Editorial and source standards
SwiftSpeedTest is the accountable publisher. We do not invent named authors, expert reviewers, credentials, customer evidence, or testing claims. This is the standard for new and materially revised pages; older dated guides can lag and should be read as time-bound until refreshed.
Source selection
- Prefer current primary sources: regulators, standards bodies, official product documentation, and provider support pages.
- Use original datasets or published methodologies for market and population measurements, with date and scope visible.
- Use reputable secondary reporting for context, not as a substitute for an available primary source.
- Label internal calculations, planning baselines, estimates, and inferences so they are not mistaken for observed facts.
Review and freshness
- Check material factual claims against the linked source and make the source discoverable near the claim or in a clearly labeled source section.
- Record a meaningful modified date when evidence, methodology, recommendations, or conclusions change.
- Version measurement and structured datasets when a change could alter interpretation or reproducibility.
- Qualify or remove a claim when the available evidence does not support precise language.
Automation disclosure
Software scripts and AI-assisted tools may help inventory content, check links and structured data, organize source material, generate tests, or draft language. Automation is not treated as evidence or given an invented expert byline. Outside factual claims should remain traceable to an appropriate source, while SwiftSpeedTest remains responsible for what it publishes.
Accountability
Corrections and reproducible data
To report a factual error, broken source, unclear calculation, or measurement concern, include the page URL, the statement or behavior in question, and a primary source or reproducible test case when possible. Material corrections should be reflected in the page and its modified date rather than silently defended.
A public correction address will appear here only after a monitored mailbox is configured. Do not send sensitive information to guessed addresses for this domain.
The activity requirements calculator publishes its assumptions as versioned JSON and CSV. These are editorial planning baselines, not population measurements or provider guarantees; the calculator adds 25% headroom when combining simultaneous activities.
Practical follow-up
Use the result for the task you care about
Interpret capacity and responsiveness together. Continue with the focused guides for gaming, streaming, work from home, or slow internet diagnosis.