Media Production Tools
Menu

How to Calculate Video Upload Time

Upload time is file size in bits divided by connection speed in bits per second. This guide works the conversion, explains the documented reasons the real transfer is slower, and shows how to model that without inventing a number.

Published 2026-08-11 · Updated date pending

The short answer

Upload time is the file in bits divided by the connection in bits per second. A 10 GB file on a 20 Mbps upload link takes 4,000 seconds — one hour, six minutes and forty seconds — if the link delivers its full advertised rate.

It usually does not, and the honest way to handle that is to enter the throughput you have actually observed rather than accept an invented discount. The Video Upload Time Calculator has an efficiency field for exactly this, and it defaults to 100% because any other default would be a number nobody measured.

The formula

bytesToSend  = fileSizeBytes x (1 + overheadFraction)
bitsToSend   = bytesToSend x 8
effectiveBps = connectionBps x efficiencyFraction
durationSecs = bitsToSend / effectiveBps

Note the direction of the overhead term. Protocol overhead adds to what has to cross the link, so it multiplies here. In the file size calculator, container overhead also adds to the payload; in the bitrate calculator, which works backwards from a finished size, it divides instead.

fileSizeBytes = 10 GB              = 10 000 000 000 bytes
bitsToSend    = 10 000 000 000 x 8 = 80 000 000 000 bits
effectiveBps  = 20 000 000 x 1.00  =     20 000 000 bps
durationSecs  = 80 000 000 000 / 20 000 000
              = 4 000 s
              = 1:06:40   (66.6667 minutes)

Set efficiency to 80% and the same transfer takes 5,000 seconds, or 1:23:20. Both lines reproduce in the Video Upload Time Calculator.

Applying it to a real export: ten minutes of 4K at 35 Mbps plus 384 Kbps audio is 2,653,800,000 bytes, and at 20 Mbps that is 1,061.52 seconds — 17 minutes and 41 seconds. The file size calculator produces the input and the upload calculator consumes it.

Why the real transfer is slower

Three documented reasons, none of which requires a benchmark to state.

Protocol headers travel with your data. RFC 791 defines the Internet Header Length field as the length of the internet header in 32-bit words and states that “the minimum value for a correct header is 5” — twenty octets. RFC 9293 defines the TCP Data Offset field the same way for the TCP header, and derives the default IPv4 maximum segment size of 536 as 576 minus 40 octets of fixed IP and TCP headers. Every segment you send therefore carries at least forty octets that are not your file.

That gives you a floor you can compute rather than guess. Forty octets of headers on a 1,460-octet payload is about 2.7% added, which is the kind of figure the overhead field is for.

Advertised speed is a ceiling, not a delivery. AWS documents its own instance network bandwidth in gigabits per second and states that smaller instance types “are documented as having ‘up to’ a specified bandwidth; for example, ‘up to 10 Gbps’”, with a baseline bandwidth they fall back to once burst credits are exhausted. That is a cloud provider describing its own product, and the same “up to” structure is how consumer connection speeds are usually written.

Measured throughput is a different quantity from link rate. M-Lab describes its NDT test as “a single stream performance measurement of a connection’s capacity for ‘bulk transport’”, reporting upload and download speeds and latency. A single-stream bulk-transfer measurement is much closer to what a video upload actually does than a line-rate figure is — which is why the number to type into the efficiency field is one you have observed, not one this site supplies.

Modelling overhead and efficiency without inventing numbers

The calculator has two advanced fields and both default to their identity values:

  • Protocol overhead, default 0%. Set it to the added share you want to model. The RFC-derived floor above is a defensible starting point for a TCP transfer over IPv4; a larger figure is yours to justify.
  • Efficiency, default 100%. Set it to the share of the advertised speed you actually achieve. If you have run a bulk-transfer measurement, use that.

Leaving both at their defaults gives you the theoretical minimum time. That is a useful number precisely because it is labelled as a ceiling on performance rather than dressed up as a prediction.

What this does not tell you

  • It does not predict your connection. Congestion, contention, distance to the server, and the receiving service’s own limits all move the result, and none is modelled.
  • It gives a duration, never a clock time. The engine reads no clock, so it reports “1 hour 6 minutes”, not “finishes at 4:32 pm”.
  • Upload speed is usually not download speed. Many connections are asymmetric. Use the upload figure.
  • It does not model resumes, retries or chunked uploads. A transfer that restarts takes longer than the arithmetic says.
  • No throughput figure here is a measurement by this project. The only numbers are the RFC header sizes and the arithmetic shown.

Frequently asked questions

How long does it take to upload a 10 GB video?

At 20 Mbps with no overhead and full efficiency, 4,000 seconds — 1:06:40. Halve the connection speed and it doubles. Enter your own file size and speed in the Video Upload Time Calculator.

Why is my upload slower than my speed test?

A speed test and a file upload are different workloads, and a link rate is an upper bound. M-Lab’s NDT is described as a single-stream bulk-transport measurement, which is closer to an upload than a line rate is, but still a different transfer to a different endpoint. Use the efficiency field to record the gap you observe.

What overhead percentage should I use?

Zero gives the payload-only figure. For a floor you can justify, RFC 791 and RFC 9293 put the fixed IPv4 and TCP headers at 40 octets per segment, which is about 2.7% on a 1,460-octet payload. Anything larger is a claim you should be able to support.

Does upload time depend on the codec?

Only through file size. Choose a codec and bitrate, get a file size from the file size calculator, then bring that size here.

My connection is advertised in Mbps but my transfer shows MB/s. Which is which?

They differ by a factor of eight. 20 Mbps is 2.5 MB/s. Mbps vs MB/s covers the conversion and the errors it causes.

Sources

  • RFC 791: Internet Protocol — IETF / RFC Editor. https://www.rfc-editor.org/rfc/rfc791. Accessed and verified 2026-08-11. Supports the definition of the Internet Header Length field and the twenty-octet minimum header.
  • RFC 9293: Transmission Control Protocol (TCP) — IETF / RFC Editor. https://www.rfc-editor.org/rfc/rfc9293.html. Accessed and verified 2026-08-11. Supports the TCP Data Offset definition and the 40-octet fixed IP and TCP header figure behind the default 536-octet MSS.
  • NDT (Network Diagnostic Tool) — Measurement Lab (M-Lab). https://www.measurementlab.net/tests/ndt/. Accessed and verified 2026-08-11. Supports the description of NDT as a single-stream bulk-transport capacity measurement reporting upload and download speeds and latency.
  • Amazon EC2 instance network bandwidth — Amazon Web Services. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html. Accessed and verified 2026-08-11. Supports bandwidth being stated in Gbps and the documented “up to” and baseline bandwidth structure.