Real-world readiness
Internet quality test
Go beyond one Mbps number. Run one test, then compare capacity and responsiveness against transparent profiles for gaming, HD video calls, 4K streaming, and large uploads.
Test real-world internet quality
Measure capacity and responsiveness once, then check gaming, calls, 4K streaming, and large-upload readiness.
Optional context is saved with recent results and included only if you copy a share link.
Full-capacity measurement
Active because you selected full-capacity mode. The time- and byte-bounded run requests at most about 832 MiB of test payload, and usually less. Protocol overhead may add a little more.
Test endpoint
Default Server - Nearest Location
Same-origin hosted endpoint
Endpoint readiness unavailable
Default endpoint is ready.
For a cleaner readiness comparison, pause unrelated traffic; the test creates separate download and upload load.
Versioned method 1.0
Exact internet-quality profile thresholds
These are SwiftSpeedTest editorial planning profiles, not universal certifications. A Ready verdict requires every threshold to pass, retained loaded measurements, and full request confidence in both transfer directions. The worse retained download- or upload-loaded direction is used.
| Profile | Download | Upload | Loaded latency | Loaded jitter | HTTP probe misses |
|---|---|---|---|---|---|
| Online gaming | ≥ 10 Mbps | ≥ 3 Mbps | ≤ 50 ms | ≤ 15 ms | ≤ 2% |
| HD video calls | ≥ 4 Mbps | ≥ 4 Mbps | ≤ 100 ms | ≤ 30 ms | ≤ 2% |
| 4K streaming | ≥ 25 Mbps | ≥ 1 Mbps | ≤ 100 ms | ≤ 30 ms | ≤ 5% |
| Large uploads | ≥ 10 Mbps | ≥ 25 Mbps | ≤ 150 ms | ≤ 40 ms | ≤ 5% |
Verdict safeguards
Incomplete evidence does not become a confident score
- Ready: every profile threshold passes and transfer confidence is complete.
- At risk: the measurement is complete, but at least one threshold does not pass.
- Retest needed: loaded response is unavailable or a parallel transfer request failed, so the full verdict is withheld.
- Shared values: editable URL values remain visibly unverified and should not be treated as measurement evidence.
Measurement boundaries
Useful browser evidence, without false protocol claims
The test uses adaptive HTTP transfers and no-store HTTP probes. That makes it useful for browser-visible capacity and responsiveness, but it does not simulate a game server, media codec, meeting platform, VPN tunnel, or cloud provider.
Failed application probes remain labeled as HTTP misses. They are not ICMP, UDP, RTP, or network-layer packet loss. For the narrower latency-under-load grade and queue diagnosis, use the bufferbloat test.
Methodology sources
Official service recommendations inform the applicable capacity profiles; IETF references inform the loaded-response method. SwiftSpeedTest separately publishes its editorial thresholds, verdict rules, units, limitations, and reusable dataset. References checked 2026-07-24.
- Netflix: Netflix-recommended internet speeds
Service baseline: 5 Mbps for 1080p and 15 Mbps for 4K UHD on Netflix.
- Zoom: Zoom Web App system and bandwidth requirements
Service baseline: Zoom lists 3.8 Mbps upload and 3.0 Mbps download for 1080p HD video.
- IETF: RFC 7928: Characterization Guidelines for AQM
Explains why delay under load matters and why a capacity result alone does not characterize responsiveness.
- IETF: RFC 8289: Controlled Delay Active Queue Management
Documents an active queue-management approach intended to control persistent queue delay.
FAQ
Internet quality test questions
- What does the internet quality test measure?
- It measures browser download and upload throughput, idle latency and jitter, download-loaded and upload-loaded latency and jitter, p95 tail delay, transfer-request confidence, and failed or timed-out browser HTTP probes.
- How are the gaming, call, streaming, and upload verdicts calculated?
- Each profile publishes minimum download and upload rates, maximum loaded latency and jitter, and a maximum browser HTTP probe-miss percentage. Ready requires every threshold to pass, successful loaded measurements, and full request confidence in both transfer directions.
- Does this internet quality test measure packet loss?
- No. It reports failed or timed-out browser HTTP application probes. Those misses can reveal reliability problems, but they must not be relabeled as ICMP, UDP, RTP, or network-layer packet loss.
- Why can a profile say Retest needed?
- A readiness verdict is withheld when the browser cannot retain enough loaded-latency samples or when one or more parallel transfer requests fail. That avoids turning an incomplete run into a confident application claim.
- Why does the test use loaded latency?
- Calls and games can feel poor even with fast Mbps when queues delay small interactive requests during downloads or uploads. The test therefore uses the worse retained download-loaded or upload-loaded direction instead of relying on idle ping alone.
- Can this predict a specific game, meeting, or streaming service?
- No. The profiles are transparent planning diagnostics, not simulations or guarantees from a specific service. Real performance also depends on the application's server, codec, route, device, Wi-Fi conditions, and current traffic.
- How much data does the quality test use?
- It starts in full-capacity mode so it can create separate download and upload load. Before starting, the interface shows a time- and byte-bounded maximum estimate and lets you choose low-data mode, which may be less conclusive on a fast connection.