The arithmetic is deterministic. The real world is not. Every result is conditional on the inputs you choose.
The transfer model
We convert the file size to bytes, multiply by eight to get bits, and divide by the effective rate in bits per second. Effective upload rate is modeled as nominal Mbps × efficiency ÷ 100 − reserved upload Mbps. A rate of zero or less cannot complete a nonempty transfer and is treated as an invalid capacity scenario.
effective Mbps = nominal Mbps × efficiency / 100 − reserved Mbps
transfer seconds = file bytes × 8 / (effective Mbps × 1,000,000)Efficiency is an editable assumption, not a measured value or a universal protocol-overhead percentage. Reserved traffic is a simplified steady allowance for other uploads. If you enter measured application throughput, start with 100% efficiency and no reservation for competing traffic already included in that measurement to avoid double counting.
Units
MB and GB are decimal: 106 and 109 bytes. MiB and GiB are binary: 220 and 230 bytes. Mbps means 1,000,000 bits per second. MB/s means 1,000,000 bytes per second. One byte is eight bits. See NIST's unit definitions.
Supporting calculations
- Video size: combined average video and audio bitrate × duration ÷ eight. Container overhead and variable-rate encoder behavior can change the actual size.
- Backup window: transferred data ÷ effective throughput, compared with available hours. The input should represent data actually sent, not automatically the entire source library.
- Data usage: average bitrate × hours per day × days for one stream. Calculate each simultaneous stream separately and add the results. Adaptive quality, retries, and other traffic can change billing totals.
- Bandwidth-delay product: bandwidth in bits per second × round-trip time in seconds. Dividing by eight expresses the result in bytes. This estimates the amount of data in flight at the given rate and RTT; it is not an automatic operating-system tuning recommendation.
- Mbps conversion: divide by eight for decimal MB/s.
Deadlines and precision
The planner uses the date and time interpreted by your browser in its local timezone and displays that timezone. Check it before making a cross-timezone commitment. Shared links preserve the deadline as an absolute UTC instant, then display it in the viewer’s local timezone. A user-selected extra buffer is added after the transfer; it is an allowance, not a prediction of platform processing. Calculated finish times start from the calculation time; the tool does not observe a real upload. Displayed durations are rounded for readability. Small differences near a deadline should not be interpreted as meaningful certainty.
What is outside the model
We do not simulate congestion control, server queues, packet loss, device sleep, file scanning, encryption or compression work, interruptions, retries, data caps, or post-upload processing. Constant throughput is a simplification. The timeline is a projection, not live progress. Leave a separate buffer and verify arrival with the destination.
Checking a result
A 1 GB file at 10 Mbps effective throughput takes 800 seconds, or 13 minutes 20 seconds. Doubling the rate halves the modeled duration; doubling the file size doubles it. If a result looks wrong, first check the file unit, bits versus bytes, and upload versus download speed. Each tool includes an example and limitations so that you can inspect the assumptions without trusting a black box.