Video Upload File Size Estimator – Duration, Bitrate and Bytes
A recorded video is about to be uploaded, and two questions come up before it goes anywhere: how big is this file going to be, and — if something imposes a size cap — what bitrate fits inside it? This video file size calculator answers both from the same equation, in your browser, with no network call of any kind. It sizes a finished recording; if you are broadcasting live and want to know what sustained bitrate your connection can carry, that is the Live Stream Bitrate Calculator’s job, not this one.
One equation, read in both directions
Everything here reduces to a single identity:
size_bytes = (video_bps + audio_bps) × seconds ÷ 8 × (1 + overhead/100)
Read left to right it gives you a file size from a bitrate. Rearranged, it gives you the total bitrate that fits a size cap, and subtracting the audio track leaves the video bitrate you have to work with. Mode A and Mode B are the same arithmetic run in opposite directions, which is why the duration, audio bitrate and overhead fields stay put when you switch between them.
Where the ÷ 8 lives
Bitrate is counted in bits per second; file size is counted in bytes. Eight bits make one byte, so the chain divides by 8 exactly once — and getting that division backwards, or skipping it, produces an answer wrong by a factor of eight. It is the most common mistake in this calculation, so the step gets its own labelled row in the working-out panel.
Work an example through. A clip running 1 h 12 min 30 s is 4,350 seconds. At 8,000 kbps of video plus 128 kbps of audio, the total is 8,128 kbps, so the file carries 8,128 × 4,350 = 35,356,800 kilobits. Divide by 8 and that is 4,419,600 kilobytes. Add a 2% container allowance and you land on 4,507,992 kilobytes — 4.51 GB, or 4.20 GiB. Both readings describe the same 4,507,992,000 bytes.
4.51 GB and 4.20 GiB are the same file
Bitrates are always decimal: 1 kbps is exactly 1,000 bit/s, never 1,024. File sizes are where the ambiguity lives. Under decimal prefixes — what upload limits and storage vendors mean — 1 GB is 1,000,000,000 bytes. Under binary prefixes, the unit is a gibibyte of 1,073,741,824 bytes, which is what many desktop file managers show while still printing “GB” on the label. That is why a file you calculated at 4.51 GB appears as 4.20 GB in a folder listing. Nothing changed but the divisor, so every size output here is labelled with the convention it used and the other reading is shown beside it.
Container overhead is an allowance, not a constant
MP4, MOV and MKV files carry per-frame headers, an index or moov atom, and interleaving padding, so a muxed file comes out slightly larger than the sum of its elementary streams. How much larger depends on the container, the fragment and keyframe layout, and how many tracks there are — there is no single correct figure to hard-code. So it is a field you set, starting at 2% as a neutral placeholder. Set it to 0 to size the streams alone. The composition bar shows the effect directly: audio is usually a sliver beside the video payload, and the overhead segment moves the total by a visible but small amount.
Why the plot is a straight line
With duration and audio held still, file size against video bitrate is exactly linear — halving the bitrate halves the file, with no threshold or cliff anywhere along it. The size-versus-bitrate plot draws that line and marks where your current settings sit on it. In Mode B it also draws a rule at your target size; the point where the two meet is the answer the mode computes.
One caveat sits next to the result rather than in a wall of disclaimers: the calculation assumes a constant bitrate. A VBR or CRF export varies around its average, spending bits where the picture needs them, so the finished file lands near this estimate rather than exactly on it. Two-pass and capped-VBR encodes track a target closely; CRF does not aim at a bitrate at all.