The formula, written out
Bitrate is bits per second. Runtime is seconds. Multiply them and you have bits; divide by eight and you have bytes. A 90 minute recording at 5,192 kbps combined is 5,192,000 bits per second times 5,400 seconds, which is 28,036,800,000 bits, which is 3,504,600,000 bytes, which is 3.5 GB. Add a percent or two for the container and you have the number that appears in a file listing.
The one place people trip is the k. In bitrate, kilo is 1,000 — a 128 kbps file carries 128,000 bits every second, not 131,072. In file size, kilo has historically meant 1,024, which is why a byte count converted with the wrong thousand is out by 2.4% per step and by more than 7% by the time it reaches gigabytes.
GB and GiB
A drive sold as 64 GB holds 64,000,000,000 bytes, because the manufacturer counts in decimal. Windows divides by 1,024 three times and prints 59.6, using GB as the label for what is properly a gibibyte. Both are describing the same bytes. Nobody has taken anything, though it is a persistent belief that they have, and the gap grows with capacity: at a terabyte it is 93 GiB.
The practical rule is to plan capacity in the unit the medium is sold in and expect the operating system to disagree with you by about seven percent, then take another slice off for the file system itself. What you can actually write to a freshly formatted card is a little under the binary figure, not the decimal one.
Why this is an estimate
Constant bitrate encoding really does emit the same number of bits every second, and for it this arithmetic is exact. Nearly everything modern is variable instead. The encoder is given a quality target or an average, and it spends bits where the material needs them: a static interview shot costs a fraction of a crowd scene, silence costs almost nothing, film grain costs a fortune.
Across a full runtime the average converges and the estimate lands within a few percent. Across a short clip it does not, because a single difficult passage can dominate. Constrained modes complicate it further — a capped variable bitrate will not exceed a ceiling but is free to come in far under it, so the estimate becomes an upper bound rather than a prediction.
What is not counted here
The overhead percentage stands in for container structure: headers, the index or moov atom, timestamps, chapter marks and any subtitle or metadata track riding along. One to three percent covers the usual cases. It does not cover a second audio track, embedded artwork of any size, or a video thumbnail, all of which are simply additional payload — add them as extra bitrate or accept that the answer is low. Nor does it account for a file system allocating in whole blocks, which rounds every file up to the next multiple of the cluster size and matters only when you are storing thousands of tiny ones.
Related pages
For converting an existing byte count between units without any media arithmetic, use the data size converter. Subtitle tracks that ride in the same container are handled by the subtitle timing shifter and the subtitle reading speed checker. If the question is page weight rather than storage, the page speed budget planner works in the same currency.
Questions people ask
Why does my finished file not match this exactly?
Almost certainly variable bitrate. The number you set in an encoder is a target average, and the encoder spends more on hard material and less on easy material, so the total only converges over a long runtime. A two pass encode aimed at a size lands very close; a single pass at an average can be several percent either way, and a short clip can be much further out than that.
Is 1 kbps 1,000 bits or 1,024?
A thousand. Bitrates have always been decimal — 128 kbps is 128,000 bits per second. The 1,024 convention belongs to memory and file sizes, and mixing the two is the most common source of a wrong answer here. This tool uses 1,000 for bitrate and shows the result in both decimal and binary byte units so you can see the gap rather than guess at it.
What bitrate should I actually use?
That depends on the codec, the resolution, the frame rate and how much the picture moves, and no table settles it. The reliable method is to encode two minutes of the most difficult material at a few settings and look at the result at full size. The table on this page is there to tell you whether a number is in the right order of magnitude, not to choose one.
Does the container really only add two percent?
For a normal audio or video file, yes — headers and an index are small next to the media data. It rises when the file carries extras: multiple audio tracks, embedded cover art, dense chapter marks, or a large subtitle track. Those are payload rather than overhead, so the cleaner way to model them is as extra bitrate.
Can I go the other way, from a file size to a bitrate?
Yes. Enter the runtime and put the size you have to hit into the target field, and the bitrate that lands there is worked out with the overhead already taken off. Split it between video and audio by fixing the audio rate first, since dropping audio below about 96 kbps is far more audible than the equivalent saving is visible.