CruxDevCruxDev Tools Prompts
network Utility • Zero-Server Privacy • 100% Client-Side

ETA / Download Time Calculator

Estimate file download and upload times from file size and connection speed — supports Mbps, MB/s, and real-world overhead factors.

Overview

Estimates how long a file takes to transfer: enter a size in KB, MB, GB or TB and a connection speed in Kbps, Mbps, Gbps or per-second byte units, and get the duration in seconds, minutes, hours or days. The arithmetic is transparent binary math, which makes its assumptions worth reading.

How It Works

Enter the file size and pick its unit, then the connection speed and its unit. The ETA appears immediately below and updates with every edit - no button. Units cover KB through TB with 1024-based multipliers, and speeds from Kbps to GB/s. Results format themselves to the sensible scale, from tenths of seconds up to days.

Step-by-Step Usage Guide

  1. Enter the file size and select its unit - KB, MB, GB or TB, all 1024-based.
  2. Enter the connection speed and select its unit, from Kbps up to GB/s.
  3. Read the ETA, which formats itself to seconds, minutes, hours or days as the magnitude requires.
  4. Adjust the speed input to a realistic effective rate (accounting for overhead) and compare the two estimates.

Technical Specifications & Standards

The calculation is bytes divided by bytes-per-second, with one convention baked in that you should know about. Sizes use binary multipliers - a KB is 1,024 bytes, an MB is 1,048,576 - which matches what your operating system's file properties dialog shows. But network speeds marketed by ISPs are decimal: one Mbps is 1,000,000 bits per second, not 1,048,576. This tool converts Kbps to 128 bytes per second, Mbps to 131,072, and Gbps to 134,217,728 - treating each speed unit as its 1024-based equivalent (a kibibit, mebibit or gibibit per second). The result is that a real download over a genuine 100 Mbps connection takes about 4.9 percent longer than this tool predicts at the same number, since 100 decimal megabits carry fewer bytes than the tool assumes. Layer on protocol overhead - TCP headers, TLS handshakes, acknowledgements - and real-world throughput typically lands at 90-95 percent of link speed, widening the gap further. For engineering estimates, the output is a clean lower bound; for promising delivery times to users, divide by a realistic measured throughput instead of the link rate.

Targeted Use Cases

  • Estimating deployment and download times for large artifacts - container images, game builds, dataset pulls.
  • Explaining to stakeholders why a 50 GB backup over a 100 Mbps line is hours, not minutes.
  • Comparing transfer options: how much a link upgrade actually saves against a realistic effective rate.
  • Sanity-checking a progress bar's projected remaining time against the physics of the link.

Notes & Gotchas

  • Use the effective throughput you actually measure, not the advertised link speed - real transfers run 90-95 percent of link rate after protocol overhead.
  • Remember the tool's Mbps is 1024-based while ISPs mean decimal; expect real times about five percent longer at megabit speeds.
  • For sizes, the 1024-based units match what file managers display, so size inputs from your OS are correct as-is.
  • Treat the result as a floor: shared links, Wi-Fi contention and disk speed all push real times higher.

Frequently Asked Questions

Why is my actual download slower than the estimate?

Three compounding reasons: the tool treats Mbps as 1,048,576 bits per second while providers mean 1,000,000 (about 5 percent), protocol overhead consumes a few more percent, and real links rarely sustain their full rate. Use a measured effective speed for tighter estimates.

Are the size units binary or decimal?

Binary: 1 KB is 1,024 bytes, 1 MB is 1,048,576, and so on up the scale. This matches what operating systems report for file sizes, so a number copied from your file manager works as typed.

How do I convert my ISP speed to this tool's units?

Type the advertised number but expect the tool's speed units as 1024-based. For the closest real-world estimate, measure actual throughput and enter that as MB/s rather than trusting the advertised rate.

Does it account for latency or connection setup?

No. The calculation is pure throughput division - size over rate. Startup costs (TCP handshake, TLS negotiation, slow-start ramp) add seconds that matter for small files and are invisible for large ones.