Internet Speed Calculator

Understanding the Internet Speed Calculator

A download time calculator converts file size and connection speed into a transfer time. The unit mismatch between the two is the point: file sizes are in bytes and connection speeds in bits, and the factor of eight between them is the most common confusion in home networking.

How it actually works

Enter file size in megabytes and speed in megabits per second. The calculator multiplies size by 8 to convert bytes to bits, divides by speed, and reports the time along with the equivalent transfer rate in megabytes per second. A 700 MB file on a 60 Mbps connection takes 1 minute 33 seconds at 7.5 MB/s.

The deeper context most people miss

Internet speeds are advertised in bits per second and file sizes are measured in bytes, so a 100 Mbps connection delivers about 12.5 MB per second at best. Dividing the advertised figure by eight is the first step in any realistic estimate, and the gap between that and what people expect drives a great deal of complaints about connections performing as designed.

Why real throughput never matches the advertised rate

Several layers of overhead sit between the advertised link speed and the data actually delivered. Protocol overhead is unavoidable: every packet carries headers for TCP and IP, and on Ethernet and Wi-Fi there are further framing and control bits, so a meaningful fraction of transmitted bits are not payload. Typical protocol efficiency runs somewhere around 90 to 95% for wired connections. TCP itself introduces further limits through its congestion control and acknowledgement behaviour, and on high-latency links the bandwidth-delay product can constrain throughput well below line rate unless window sizes are tuned, which is why a fast connection to a distant server can transfer more slowly than a slower connection to a nearby one. The server at the other end is frequently the bottleneck rather than your connection, particularly for popular downloads without content delivery network distribution. Wi-Fi adds substantially more overhead than wired Ethernet, and the advertised rates on router boxes are theoretical maxima under ideal conditions that no real installation achieves, with real throughput commonly half the headline figure or less depending on distance, interference, and how many devices share the channel. Older devices connecting to a modern access point can slow the whole channel. The practical upshot is that a wired connection to a well-provisioned server is the only situation where throughput approaches the advertised figure, and everything else falls short for reasons that are structural rather than faults.

A worked example: where the bottleneck actually sits

A 700 MB file on a nominal 60 Mbps connection should take 93 seconds. Suppose it takes five minutes. Diagnosing this means working through the chain. Is the connection actually delivering 60 Mbps, tested wired rather than over Wi-Fi, using a speed test to a nearby server? If wired throughput is fine and Wi-Fi is not, the problem is the wireless link, and distance from the access point, interference on the 2.4 GHz band, channel congestion in dense housing, and older client hardware are the usual causes. If the connection tests fine and this particular download is slow, the server or the route is the constraint, which is common and outside your control. If everything is slow at particular times, the local segment may be congested at peak hours, which is a contention issue in shared-medium technologies including cable. If speeds are fine but interactive applications feel bad, the problem is likely latency or bufferbloat rather than bandwidth, and those are distinct issues that a speed test measuring throughput alone will not reveal. This diagnostic order matters because people commonly buy a faster package to fix a problem that a faster package cannot address, since upgrading bandwidth does nothing for latency, Wi-Fi coverage, or a slow remote server.

Deciding how much speed you actually need

Bandwidth requirements are lower than marketing implies for most households. Video streaming is the most common heavy use, and it requires roughly 5 Mbps for HD, 15 to 25 for 4K depending on codec and provider, and considerably less for standard definition, with modern codecs continuing to reduce these. Several simultaneous 4K streams therefore fit comfortably within 100 Mbps. Video calling uses a few Mbps per stream. Gaming uses very little bandwidth and is highly sensitive to latency and packet loss, which is why a fast connection can deliver a poor gaming experience and a modest one can be excellent. Large downloads and uploads benefit from more bandwidth linearly, so anyone regularly moving large files notices an upgrade where a streaming household does not. Working from home with cloud backup and large file transfers shifts the calculation, and upload speed becomes relevant, which asymmetric technologies including most cable connections provide far less of than download. The practical guidance is that beyond roughly 100 to 200 Mbps, additional bandwidth produces diminishing perceptible benefit for typical household use, while latency, Wi-Fi coverage, and reliability continue to matter at any speed. Upgrading the router or adding mesh coverage frequently improves the experience more than upgrading the package, and it is usually cheaper.

Latency, jitter, and why bandwidth is the wrong headline

Bandwidth measures how much data can flow per second and latency measures how long a single packet takes to make the round trip, and they are largely independent. Interactive applications including gaming, video calling, and remote desktop depend on latency and are barely affected by bandwidth above a modest threshold. Latency is bounded by physical distance and the speed of light in fibre, so a connection to a server across an ocean cannot be faster than roughly the transit time regardless of bandwidth, which is why content delivery networks place content geographically near users. Jitter, the variation in latency, matters as much as the average for real-time applications, since variable delay disrupts audio and video more than consistent delay. Bufferbloat is a specific and widespread problem where oversized buffers in network equipment hold packets during congestion rather than dropping them, causing latency to spike dramatically whenever the connection is saturated, which is why a household video call degrades when someone starts a large download. Modern queue management algorithms including CoDel and FQ-CoDel address it and are available in many routers, and enabling smart queue management frequently improves perceived performance more than any bandwidth upgrade. Packet loss degrades TCP throughput sharply since the protocol interprets loss as congestion. Testing tools that measure latency under load, rather than idle latency, reveal bufferbloat that standard speed tests miss entirely.

Variations: units, connection types, and measurement

Unit confusion extends beyond bits and bytes. Storage manufacturers use decimal prefixes where a gigabyte is 1,000,000,000 bytes, while operating systems frequently report in binary units where a gibibyte is 1,073,741,824, which is why a drive labelled 1 TB shows as roughly 931 GB. The same ambiguity affects file size figures. Connection technologies differ in their characteristics: fibre offers high symmetric speeds and low latency, cable offers high download and much lower upload with shared local capacity causing peak-time contention, DSL is distance-limited, fixed wireless and satellite vary with conditions, and low-earth-orbit satellite has transformed satellite latency from unusable for interactive applications to acceptable. Mobile connections vary enormously with signal and cell load. For measurement, speed tests to nearby servers measure the access link while tests to distant ones measure the route, and running several tests to different servers distinguishes local problems from routing ones. Testing wired rather than over Wi-Fi is essential for diagnosing whether the connection or the wireless is at fault, and this single step resolves a large share of perceived speed problems.

Understanding and diagnosing connection speed

Divide advertised megabits per second by eight to get megabytes per second, since speeds are quoted in bits and file sizes measured in bytes. Expect real throughput below the theoretical figure, since protocol overhead alone consumes 5 to 10% on wired connections and Wi-Fi loses considerably more. Test wired before blaming the connection, since Wi-Fi is the bottleneck in a large share of perceived speed problems. Test to multiple servers to distinguish a local access problem from a route or remote server issue. Check latency under load rather than idle, since bufferbloat causes latency spikes during downloads that standard speed tests miss and that degrade calls and gaming badly. Recognise that gaming and video calling depend on latency rather than bandwidth, so upgrading a package will not fix them. Consider a router upgrade or mesh coverage before a faster package, since it is usually cheaper and more often the actual constraint. And note that beyond roughly 100 to 200 Mbps, additional bandwidth produces diminishing benefit for typical household use.

What people get wrong

• Confusing megabits with megabytes, when connection speeds are quoted in bits and file sizes measured in bytes, a factor of eight apart.
• Blaming the connection for slow transfers without testing wired, when Wi-Fi overhead, distance, interference, and older client devices cause a large share of perceived speed problems.
• Buying more bandwidth to fix gaming or call quality, which depend on latency and packet loss rather than throughput and are unaffected by a faster package.
• Judging a connection by idle speed tests alone, which miss bufferbloat, where latency spikes badly under load and degrades interactive applications.

Where the math comes from

Time in seconds = File Size in MB × 8 / Speed in Mbps, multiplying by 8 to convert bytes to bits since file sizes are measured in bytes and connection speeds quoted in bits per second. Transfer rate in MB/s = Speed in Mbps / 8. Real throughput falls below this because of protocol overhead, typically 5 to 10% on wired connections and considerably more over Wi-Fi.

Questions and answers

Related calculators

Daycare Cost · Miles Per Gallon · Self-Hosted vs API LLM · Clothing Size Converter · File Size to Bandwidth