Video Bitrate Calculator

How this is calculated

BITRATE IS SIZE DIVIDED BY TIME, and everything here follows from that. A megabyte is eight megabits, so a target in MB becomes a budget in bits, and dividing by the running time in seconds gives the bits per second you are allowed to spend. ⚠️ THE AUDIO COMES OUT OF THE SAME BUDGET AND IT IS THE STEP PEOPLE SKIP. If you set your VIDEO bitrate to the total you calculated, the finished file overshoots by exactly the size of the audio track. This tool subtracts it, so the number it gives you is the one to type into the encoder rather than one you still have to adjust. ON A SHORT CLIP THE AUDIO BARELY MATTERS; ON A LONG ONE IT DOES. Audio is usually a constant bitrate, so its share of the budget depends entirely on how generous the video budget is. At a high target size it is a rounding error. Squeeze the same video into a small file and the audio can take a serious bite - and at the extreme it can exceed the whole budget, which the tool shows as a negative video bitrate rather than pretending a solution exists. MEGABYTES HERE ARE DECIMAL - a million bytes, which is what video tools, cameras and upload limits all mean by MB. Your operating system may report the finished file in MEBIbytes (1,048,576 bytes) and call those MB too, so a file this tool calls 500 MB can show up as about 477 in a file browser. Nothing is wrong; they are different units with the same name, and our file size converter covers that properly. THIS IS AVERAGE BITRATE, NOT A GUARANTEE. Variable-bitrate encoding spends more on complex scenes and less on simple ones, hitting the average across the whole file. A two-pass or target-size mode in your encoder will land very close to the figure; a constant-quality mode such as CRF ignores it entirely and gives you whatever size the content needs, which is often the better choice when you have no hard limit. CONTAINER OVERHEAD IS NOT MODELLED. Muxing, headers and index data add roughly a percent or so, so if the limit is hard - an upload cap or a disc - aim a little under rather than exactly at it. RESOLUTION AND FRAME RATE ARE NOT INPUTS, DELIBERATELY. They change how good a given bitrate LOOKS, but not the arithmetic of how large a file it produces. What bitrate is enough for 1080p60 is a judgement about acceptable quality and content complexity, not a calculation - a static screen recording and a fast sport look completely different at the same number.

Common questions

Why subtract the audio?

Because it spends the same budget, and forgetting it is the most common reason a file comes out over target. Your encoder asks for a VIDEO bitrate, so if you hand it the total the file was allowed, the finished result overshoots by exactly the size of the audio track. The tool reports both figures side by side for that reason - the total the file can afford, and the video number to actually type in. On a generous target the difference is trivial, but on a tight one it is the difference between hitting an upload limit and missing it.

When does the audio actually matter?

When the budget is tight, because audio is usually a constant bitrate while the video budget is whatever is left. At 500 MB for ten minutes the audio takes under two percent of the budget and you could ignore it. Squeeze the same ten minutes into 25 MB and it takes 38 percent - close to two fifths of everything you have. Push further and the audio alone can exceed the whole budget, at which point the tool reports a negative video bitrate - which is the honest answer rather than a made-up small positive number, and it tells you to cut the audio bitrate or accept a bigger file.

Why is my finished file a different size in the file browser?

Almost certainly because of the two meanings of MB. This tool uses decimal megabytes - a million bytes - which is what cameras, video tools and upload limits mean. Windows reports MEBIbytes, 1,048,576 bytes, and labels them MB as well, so a file this tool calls 500 MB shows up there as roughly 477. Nothing has gone wrong and nothing needs re-encoding; they are two different units sharing a name, and our file size converter shows both readings of the same number of bytes side by side.

Will my encoder hit this exactly?

Close, if you use the right mode. Two-pass encoding or an explicit target-size mode will land within a percent or so, because they measure the content first and then spend the budget. Single-pass variable bitrate is looser. Constant-quality modes such as CRF ignore a target size entirely - they give you whatever size the content needs to reach the quality you asked for, which is usually the better choice when you have no hard limit and a worse one when you do. Container overhead adds roughly a percent on top, so if the limit is genuinely hard, aim slightly under it.

What bitrate do I need for 1080p?

That is a quality judgement rather than a calculation, which is why resolution and frame rate are not inputs here. Bitrate decides how big the file is; resolution, frame rate and content complexity decide how good it looks at that size. A static screen recording and a fast-moving sport at the same bitrate and resolution look completely different, because one has almost nothing changing between frames and the other has everything changing. The honest approach is to encode a difficult thirty-second section at a couple of candidate bitrates and look at them, then use this tool to check the whole video fits.

Can I use it the other way round?

Yes, and that is what the last two outputs are for. Enter a video bitrate you already know you like and it reports the file size that would produce for your running time, and how long a video would fit inside your target at that bitrate. That second one answers a question the forward direction cannot: not whether this video fits, but how much video fits - useful when you are deciding what to cut, or how long a recording can run before it breaks a limit.

Does it account for the container?

No, and it is worth a small margin. Muxing, headers, index data and chapter markers all add a little to the finished file - typically around a percent, more for formats with heavy metadata or many tracks. The arithmetic here covers the media streams themselves, so if you are aiming at a hard ceiling such as an upload cap or a disc, treat the result as the maximum rather than the target and take a few percent off. If the limit is soft, the overhead is small enough to ignore.

Take it further with AI

Copy this into ChatGPT or Claude with your own numbers filled in. It hands over the figures this calculator worked out, so the answer is built on real arithmetic instead of a guess.

I used the Video Bitrate Calculator at https://www.bfcbrilliance.com/tools/video-bitrate-calculator.

What I entered:
- File size you have to hit (MB or GB): ___
- Those units are: ___
- How long the video runs (min): ___
- Audio bitrate (kbps): ___
- Or a video bitrate you already like (kbps): ___

What it calculated:
- Video bitrate to set: ___
- Total bitrate the file can afford: ___
- That video bitrate in Mbps: ___
- Share of the budget the audio takes: ___
- Size if you encode at your chosen bitrate: ___

Use those figures as given — they are already worked out, so please don't recalculate or estimate your own. Help me turn them into a plan: what to buy or do, in what order, roughly what it should cost, and the mistakes people most often make with this job.

More internet speed tools