Bitrate vs Size Calculator

turn bitrate settings into final size expectations

Loading interactive simulation...

bitrate is a flow, size is an integral 🖖

Bitrate is a rate and size is its integral, which makes one number worth memorising: an extra megabit per second costs exactly 450 MB an hour, whatever is in the picture. Length compounds the same way. The Long lecture preset runs at a modest 3.2 Mbit/s and still produces a bigger file than the 4K preset at eighteen, because ninety minutes beats fifteen. Audio and container overhead are the small terms — across these eight presets they account for between 5 and 10 percent of the finished file.

why your file is one-eighth of the bitrate 🖖

Bitrate is measured in bits per second, but file size is in bytes — and one byte is 8 bits. So the megabits per second your encoder shows must be divided by 8 to get megabytes per second of storage. A quick rule of thumb: 8 Mbps is roughly 1 MB every second, so a 10-minute clip lands near 600 MB before audio and overhead. Getting this factor of 8 right is the difference between a plan that fits and one that overflows eightfold.

two different 'megas' in one sum 🖖

Bitrate always uses the SI mega: 1 Mbps is exactly 10⁶ bits per second. But 'MB' for file size is ambiguous — storage vendors and this calculator treat it as 10⁶ bytes, while Windows still counts in base-2 units where one 'MB' is really 2²⁰ = 1,048,576 bytes (properly a mebibyte, MiB). So the same 700 MB file can read as 668 MB in your file browser, and the gap compounds with each prefix step until a '1 TB' drive shows only about 931 GB.

ONE STAGE OF A CHAIN — WHAT ARRIVES, WHAT LEAVES, WHAT BREAKS DOWNSTREAM

Where This Sits In The Encoding Pipeline

A video encoder is not one algorithm but eight stages in a fixed order, and the order is not arbitrary: each stage exists because the one before it made its job possible. This tool models one of them. The chain below links to the other seven.

Bitrate vs Size Calculator — converts the bitrate the chain produced into a file size, and into a delivery constraint

What arrives
An average bitrate from the encoded stream.
What leaves
A file size, and an answer to whether it fits.
What the next stage assumes
Nothing downstream. This is where the constraint originally came from, though — the target that gets handed to rate control at stage 07.
What goes wrong here
Size is bitrate multiplied by duration, so it is arithmetic rather than a codec decision. The useful direction is backwards: a size limit divided by duration is the bitrate budget every earlier stage has to live inside.

Problem solved in full

  1. File size of a ten-minute video at 6 Mbit/s of picture 5 steps

    A ten-minute video at 6 Mbit/s of picture and 192 kbit/s of sound. Work out the file size, and then answer the question that decides encoder settings: how much of it is the audio?

    1. Bitrates add. The container carries both streams, so the number that matters for size is their sum.

    2. Size is bitrate times duration, and the only trap is the units: bitrates are in bits, files are measured in bytes. Divide by eight, and the factor everyone forgets is exactly the factor that makes an estimate come out eight times too large.

    3. Then the container itself costs something — headers, index, interleaving — modelled here as 3%.

    4. The audio share is the interesting ratio. It is 3.1% of the bitrate, and that same 3.1% is 14.4 MB of the finished file.

    5. Against a 520 MB cap the file has 41.67 MB to spare, so the video bitrate could rise a little rather than the audio being cut.

    Answer

    The tool prints a total of 6.192 Mbit/s, a payload of 464.4 MB and a final size of 478.33 MB. The number that changes decisions is 3.1%. Halving the audio bitrate — the first thing people reach for — saves about 7 MB of a 478 MB file, while costing every listener audible quality. Taking the same 7 MB off the video is a 1.5% bitrate cut nobody would see. The arithmetic is trivial and the conclusion is routinely got backwards, because 192 kbit/s sounds like a lot next to 6 Mbit/s only until you notice which one is the small number.

References (1)
  • The binary prefixes block 3 separates from the SI ones: IEC 80000-13:2008, Quantities and units — Part 13: Information science and technology, which defines the kibibyte, mebibyte and gibibyte precisely so that "MB" need not be ambiguous.

Example problems

  • short social - Thirty seconds at 8 Mbit/s is only 31.70 MB. At this length even a generous bitrate costs nothing worth budgeting for.
  • 1080p stream - Ten minutes at 6 Mbit/s, the case the worked problem solves in full: 478.33 MB against a 520 MB cap, with 41.67 MB to spare.
  • 4K stream - The one preset that misses its budget, and only just: 1925.35 MB against a 1900 MB target. In VBR the tool averages the slider at 90%, so 18 Mbit/s is really 16.20.
  • long lecture - Ninety minutes at a slider setting of 3.2 Mbit/s comes to 2048.98 MB, a bigger file than the 4K preset makes at eighteen. Length beats bitrate.
  • podcast video - An hour at 1.8 Mbit/s is 802.33 MB, and the audio is 7.3% of it. This is the one preset where trimming the sound would save anything worth having.
  • high quality - Twenty minutes at 18 Mbit/s is 2875.32 MB, the biggest file on the list, and the audio is 1.4% of it.
  • mobile data - Fifteen minutes at 1.2 Mbit/s fits in 132.56 MB, well inside the 180 MB cap even before the 30% headroom is spent.
  • live safety - An hour of live at 4.5 Mbit/s: 2082.60 MB of payload becomes 2207.56 MB once 6% container overhead is added, the heaviest overhead here.