File Transfer Time Calculator

The Dual-Arrow Flow

Protocol Library

Seven protocols with overhead, RTT, and port — sourced from RFC and vendor docs.

Transfer Time Reference Table

One-way download estimator? Try the Download Speed Calculator.

The Transfer-Time Formula

No saved estimates yet. Tap "Save to History" to remember up to six transfers.

How to Estimate a Transfer

1. Enter the file size and unit (MB, GB, TB) and the link speed with unit (Mbps, MB/s, Gbps).
2. Pick the protocol — FTP, FTPS, HTTPS, SCP, SFTP, rsync, or AWS S3 multipart. Each protocol displays its overhead and typical RTT.
3. Choose direction — Upload (client to server) or Download (server to client). The dual-arrow widget highlights the active stream.
4. Read the effective time, throughput, and overheadin the result panel below the SVG. Compare to the conversion table to validate.
5. Tap Save to History to retain up to six estimates for comparison across protocols and link speeds.

A Short History of File Transfer Protocols

In 2026, a data engineer in Bengaluru moving a 4 TB dataset between an on-prem NAS and an AWS S3 bucket needs to know exactly how long the transfer will take, accounting for the chosen protocol's framing overhead, the link's effective throughput, and the round-trip time penalty. Naive 'size ÷ bandwidth' arithmetic is wrong by 5-15% for most modern protocols. The File Transfer Time calculator implements the corrections explicitly. The dual-arrow flow widget illustrates the bidirectional nature of every modern transfer (control + data, request + response) and the protocol picker brings in the specific overhead numbers for FTP, FTPS, HTTPS, SCP, SFTP, rsync, and S3.

The protocols themselves have a forty-year lineage. FTP (File Transfer Protocol) was first specified by Abhay Bhushan in RFC 114 in 1971 and standardised in RFC 959 by Postel and Reynolds in 1985. It uses TCP port 21 for control and a separate ephemeral port for data, has zero encryption, and is now obsolete on the public internet but persists on internal LANs because of its 3% bandwidth overhead — the lowest of any common protocol. FTPS adds TLS framing per RFC 4217 (2005) and lifts overhead to about 7%.

SSH and its file-transfer descendants — SCP (Secure Copy, 1995 via Tatu Ylönen's original SSH) and SFTP (drafted by the IETF Secure Shell Working Group, draft 02 in 2004) — multiplex over the single TCP port 22. SCP is a one-shot stream with AES-GCM encryption at 6% overhead; SFTP is a chunked, resumable protocol with 9% overhead due to its larger framing. Modern OpenSSH (since version 9.0 in 2022) deprecates the original SCP protocol in favour of SFTP-backed scp.

HTTPS, the dominant modern transfer protocol, evolved from Tim Berners-Lee's 1991 HTTP/0.9 through HTTP/1.1 (RFC 2616, 1999), HTTP/2 (RFC 7540, 2015), and HTTP/3 over QUIC (RFC 9114, 2022). On the wire, HTTP/2 over TLS 1.3 adds about 8% overhead — header compression (HPACK) and stream multiplexing reclaim much of the latency cost. The dual-arrow widget reflects this: a request stream from client to server and a response stream from server to client, both flowing simultaneously over the same TCP connection.

rsync's delta-encoding algorithm, invented by Andrew Tridgell in his 1999 ANU PhD thesis, transmits only the differences between a source and a destination file. On a fresh transfer rsync behaves like any other protocol with about 4% overhead, but on an incremental transfer of a partially-updated file the effective transfer size approaches zero. The calculator's rsync preset assumes a fresh transfer; for incremental sync the actual time is bounded by the file's change-rate, not its size.

Cloud object stores added a new family of transfer mechanics. AWS S3's multipart upload (introduced 2010, mandatory above 100 MB) splits the file into 5-10 MB parts uploaded in parallel and reassembled server-side. Effective overhead is about 5%, but the parallelism means a single client can saturate a 1 Gbps link far better than a serial protocol. Google Cloud Storage's resumable upload (XML API) and Azure Blob Storage's block blobs follow similar designs. The S3 preset in this calculator reflects the typical 10 MB chunk + 90 ms RTT pattern.

Network engineers and data professionals from companies like Cloudflare, Akamai, NetApp, and AWS now routinely model transfers using the bandwidth-delay product (BDP) framework first formalised by Van Jacobson in his 1988 SIGCOMM paper on TCP congestion control. BDP = bandwidth × RTT, and a TCP window smaller than BDP under-utilises the link. The calculator's effective-throughput estimate accounts for this by applying the protocol overhead as a multiplier on the raw bandwidth — a first-order approximation that matches real-world measurements within 8-12% for files larger than 100 MB.