Divide Mbps by eight for theoretical MB/s. Protocol overhead, server limits and competing traffic lower actual transfer rates.
How to Read Your Speed Test Results
Interpret download, upload, response timing and observed loss by measurement method, then choose a controlled follow-up test.
Read the method and destination before comparing numbers. Download and upload describe transfer capacity; timing describes responsiveness to the tested endpoint. A high Mbps result does not rule out delay under load, Wi-Fi interference or an application-specific problem.
How to run the check
- Identify the measurementRecord the tool, date, device, Wi-Fi or Ethernet and endpoint. An HTTP response sample is not interchangeable with ICMP ping or a game-server round trip.
- Read both transfer directionsVideo uploads and backups use upstream capacity. A modeled 100/10 Mbps plan has one tenth as much advertised upload as download; the model is not a measured result.
- Compare idle and busy timingRun the same method while the connection is idle and during a controlled transfer. Record completed samples and failures rather than selecting the fastest run.Open the relevant tool →
- Repeat one controlled changeCompare the same device on Ethernet and Wi-Fi. Keep the destination and time window similar. Save JSON or a shareable result only after a successful measurement.
What the signals mean
Read the method and units. A median hides outliers, and browser scheduling can influence HTTP timing.
A failed HTTP request is not a direct packet-loss measurement. Read whether the tool tests transport packets, application messages or requests.
Frequently asked questions
Why is a file download slower than my speed test?
The file server, route, protocol, storage and other transfers can be the bottleneck. Compare units and sustained rates, not only a brief peak.
Should I send one test to my ISP?
Send repeated comparable runs with timestamps, connection mode and symptoms. One result documents an observation but rarely identifies the responsible segment.