English Deutsch Español Français Italiano Nederlands Polski Українська
Encoders & Utilities

Download Time

Estimate download duration at any connection speed.

Download time estimator Pick file size and connection speed — we will compute the transfer time. SI units (1 KB = 1000 B).
Try: 1 GB @ 100 Mbps 50 GB @ 1 Gbps 4 GB @ 10 Mbps 700 MB @ 56 Kbps
2m 23s
1 MB @ 56 Kbps
Raw time
142.86 s
Adjusted time
142.86 s
Total bytes
1 000 000
Bits per second
56 000

About this tool

Download Time estimates how long a file of a given size will take to download at a given connection speed. Enter the file size in any unit (KB, MB, GB, TB — binary or decimal), pick a speed in Mbps/MBps/Gbps (with presets for common tiers: 56k dial-up, 4G LTE, fibre 100 / 1000 Mbps), and the tool returns the duration in human-friendly form (1 hour 23 minutes 12 seconds) plus a few comparison rows at other common speeds.

The math is straightforward — duration = size / speed — but the unit conversions trip everyone up. ISPs sell speed in bits per second (Mbps); file sizes are in bytes (MB); and "MB" itself is ambiguous between 1,000,000 bytes (decimal, used by ISPs and disks) and 1,048,576 bytes (binary, used by Windows and RAM). The tool labels every unit precisely so you can verify which world you are computing in.

When to use this tool

  • Estimating backup or migration windows. A 500 GB cloud-to-cloud transfer at 1 Gbps is ~70 minutes of actual transfer; planning that gives you the maintenance window.
  • Comparing internet plans. "100 Mbps" vs "Gigabit" sounds dramatic; on a 10 GB game download it is 14 minutes vs 1.5 minutes. Concrete numbers help decide whether the upgrade is worth it.
  • Sizing CI/CD bandwidth. Pulling a 2 GB Docker image on every build at office-shared 50 Mbps adds up fast.
  • Setting realistic user expectations. "This export will take ~5 minutes" beats a spinner with no progress bar.

Why real downloads are slower than the calculation

The number you compute is the absolute minimum. Real downloads encounter TCP slow-start (first second is partial speed), per-connection bandwidth caps (a single HTTPS download to one server rarely saturates a fibre line), TLS handshake overhead, disk I/O bottlenecks, and shared-pipe contention. As a rule of thumb, plan for 70–85% of theoretical for a single large file, less if you are downloading many small files.

Frequently asked questions

Why is Mbps not the same as MB/s?
Mbps is megabits per second; MB/s is megabytes per second. 1 byte = 8 bits, so 100 Mbps ≈ 12.5 MB/s. ISPs advertise in bits because the number looks 8× bigger; operating systems display in bytes because that is how files are measured. The factor of 8 is the single biggest source of "why is my download slower than my speed test?" confusion.

What is the difference between MB and MiB?
MB = megabyte = 1,000,000 bytes (decimal, SI). MiB = mebibyte = 1,048,576 bytes (binary, IEC). Disk and ISP marketing uses MB; Windows file-size dialogs and RAM specs use MiB (often labelled "MB" anyway, adding to the confusion). For a 1 TB hard drive sold by a manufacturer, you get ~931 GiB usable — same number of bytes, different conventional name.

Why is my real download slower than the calculator says?
Several reasons stack up: TCP slow-start (the protocol ramps up gradually, so the first few seconds are partial speed); TLS handshake and DNS overhead (smaller files barely benefit from high speeds); single-connection caps (one HTTPS stream to one server rarely saturates fibre); local Wi-Fi contention; and the server's own outbound bandwidth. Plan for 70–85% of theoretical and you will rarely be surprised.

Does the tool account for overhead?
It computes the protocol-free theoretical minimum. Real-world transfers add ~3–5% for TCP/IP headers (40 bytes per 1500-byte packet), plus a few percent for TLS framing. We deliberately do not bake this into the headline number because the overhead varies by protocol — HTTP/3 is leaner than HTTP/2 over TLS over TCP. For pessimistic planning, add 5% to the duration the tool reports.