Video Bitrate and File Size Calculator

Who this is for, and what it actually answers

This calculator sits on the delivery side of a video job. It is for the moment when the picture is finished and a number has been imposed on you from outside: a platform limit, a client specification, an email attachment ceiling, a hard drive that has to hold the whole season.

• An editor exporting a master. You know the rate you want and need to know whether the drive has room. Use the file size mode.
• Anybody with a size limit. Somebody said the file must be under 500 MB. Use the bitrate mode, give it the limit and the running time, and it hands you the rate to set in the exporter.
• Somebody planning a long recording. A conference, a lecture series, a stream you intend to keep. Use the running time mode to find out how many hours fit in the space you have.
• Anybody uploading. Start from the published YouTube or Vimeo target in the preset menu instead of guessing, then check what that costs in gigabytes before you commit the export.

If your question is about a card in a camera rather than a file leaving an editor, the storage and recording time calculator is the right page. Same arithmetic, different framing.

The formula, in one line

File size equals bitrate multiplied by duration, divided by eight. Bits become bytes at the division. Everything else on this page is that line rearranged.

An example worth memorising. Ten megabits per second for one hour is 10,000,000 x 3600 / 8, which is 4.5 gigabytes. Once you know that a 10 Mbps stream costs 4.5 GB an hour, you can estimate almost anything in your head: 20 Mbps is 9 GB an hour, 100 Mbps is 45 GB an hour, 1000 Mbps is 450 GB an hour.

The same line, solved backwards

Going from a size limit to a bitrate is the sum most people actually need, and it is the one most calculators do not offer. Multiply the size in bytes by 8 to get bits, then divide by the running time in seconds.

A worked case. A 30 minute programme has to come in under 2 GB. That is 2,000,000,000 bytes times 8, which is 16,000,000,000 bits, divided by 1,800 seconds, which is 8,888,888 bits per second, or 8.89 Mbps. That figure is the total, so the audio comes out of it: a 320 kbps track leaves 8.57 Mbps for the picture. Now take about five percent off for container overhead and encoder variance and set the exporter to 8.1 Mbps. You will land under the limit with room to spare, which is the only place worth landing.

Why five percent and not zero

Because the encoder is aiming, not obeying. A two pass export with a target average usually lands within a couple of percent, and a container adds a fraction of a percent of its own for the index and metadata. Five percent is not a specification, it is the margin that has never yet made me redo an export at midnight. If you have the room, use ten.

Audio is not free

Most file size calculators ask for the video bitrate and stop there. Then people wonder why the export came out bigger than the promise. A 320 kbps stereo track is 0.32 Mbps, which over one hour is 144 megabytes. On a two minute social cut it is nothing. On a three hour conference recording it is 432 MB, and if you are cutting to a hard delivery limit it is the difference between accepted and rejected.

Uncompressed audio is heavier still. Forty eight kilohertz, twenty four bit, two channels is 48000 x 24 x 2, which is 2,304 kbps. That is 2.3 Mbps before a single frame of picture. Four channels doubles it. If you deliver ProRes with four channels of production sound, that is 4.6 Mbps of audio riding on top of the video rate, and the storage calculator on the front page will add it for you.

What the platforms actually publish

These are the published numbers, copied from the source and linked to it. Where the publisher gives a range, the range stays a range here. Nobody at YouTube decided that 4K is exactly 40 Mbps, so this site does not print that as a fact either.

Instagram does not publish a bitrate

This is worth saying plainly because so many pages pretend otherwise. For reels, Instagram publishes an aspect ratio between 1.91:1 and 9:16, a minimum of 30 frames per second, a minimum resolution of 720 pixels, and the codec requirements: H.264 or HEVC, progressive scan, closed group of pictures, 4:2:0 chroma. It does not publish a target bitrate. Any table that shows you an official Instagram bitrate is showing you somebody's guess dressed as a specification. Export at a sane rate for the resolution, use the highest quality upload setting in the app, and stop worrying about a number that does not exist.

Audio bitrates you can choose from

Constant bitrate against variable bitrate

A constant bitrate export gives you exactly the file size this calculator predicts, because the encoder is being told to spend the same amount every second whether the frame needs it or not. A variable bitrate export gives you a better looking file at the same average, because the encoder saves on the still frames and spends on the difficult ones. The trade is predictability.

Two pass variable bitrate with a target average will land very close to the prediction, usually within a couple of percent, because the encoder gets to plan. Single pass with a quality target such as constant rate factor will not, because you have told the encoder to chase quality and let the size fall where it falls. Both are correct choices. Only one of them lets you promise a file size in advance.

If you have a hard limit to hit, and you often do when a platform or a client sets one, use the bitrate mode above. Give it the limit and the running time, take about five percent off what it hands you for container overhead and encoder variance, and export two pass at that number.

Why your export never matches the exporter estimate

Premiere, Resolve and Compressor all show an estimated file size while you set up an export, and it is often wrong. The estimate is the arithmetic on this page applied to the target bitrate. The actual file is what the encoder produced, and the encoder had opinions: variable bitrate spending, keyframe placement, an audio track that got resampled, and container metadata. On short files the gap is invisible. On a feature length master it can be a couple of gigabytes.

The habit that has never let me down is simple. Calculate the size, add a margin, and check the real file before you send it. The arithmetic tells you what to expect. It does not tell you what happened.

The codec changes the quality, not the arithmetic

People arrive here asking for an H.264 calculator or an H.265 calculator as though the sums differ. They do not. Ten megabits per second is 4.5 gigabytes an hour whether those bits are H.264, H.265, AV1, VP9 or ProRes. The file size follows the rate, full stop.

What the codec changes is what you get for the rate. A newer codec spends its bits more cleverly, so H.265 at 6 Mbps can look like H.264 at 10, and that is a real saving. But you cannot ask this page, or any page, to tell you how much better, because the answer depends on your footage, your encoder, your preset and how long you are willing to let it run. Anyone quoting you a fixed percentage is quoting an average of somebody else's material.

The practical route is not a ratio, it is a test. Export sixty seconds of your hardest shot at two rates, look at them at full size on a real screen, and pick. That takes five minutes and settles an argument that otherwise runs all afternoon.

When this number will be wrong

The arithmetic never fails. These five situations are where the prediction and the file part company.

You exported on a quality target instead of a rate target. Constant rate factor and similar quality modes have no target size by design. You told the encoder to chase a look and let the size fall where it falls, so the size is an outcome, not an input. Nothing can predict it in advance. If you need a size, you need a rate.

You used a hardware encoder. The encoders built into graphics cards and phone chips are fast and they hit their targets less precisely than a software encoder given time. Expect more drift, and check the file rather than trusting the setting.

You ignored the audio. Four channels of uncompressed 48 kHz 24 bit production sound is 4.6 Mbps before a frame of picture exists. On a short cut that is noise. On a three hour recording it is 6.2 GB of audio alone.

You are predicting what a platform will store. This calculator predicts the file you upload. It cannot predict the file YouTube, Vimeo or Instagram builds from it, because every one of them re-encodes what you send at rates they do not publish. Your upload target is a quality decision, not a size decision.

The source is already compressed. Exporting a 6 Mbps social clip at 40 Mbps produces a 40 Mbps file that looks exactly like a 6 Mbps file. The size prediction is right and the money is wasted. Rate can preserve quality that exists. It cannot manufacture quality that does not.

How to find the bitrate of a video you already have

You do not need software for this and you do not need to trust a label. Take the file size in megabytes, divide it by the duration in seconds, and multiply by eight. That gives the total bitrate in Mbps, audio included.

A 900 MB file that runs 12 minutes is 900 divided by 720, which is 1.25, times eight, which is 10 Mbps. A 240 MB clip that runs 10 seconds is 192 Mbps, which is the signature of an intermediate codec rather than a delivery file. Once you can read a file this way you can tell in ten seconds whether somebody sent you a master or a preview, and you never have to ask.

Common questions

Related calculators

• Video Storage and Recording Time CalculatorTake a bitrate to a card or drive and get hours.
• ProRes File Size CalculatorApple published rates for all 58 supported formats.
• BRAW File Size CalculatorBlackmagic RAW, ratio by ratio.
• Sources and methodEvery number on this site and where it came from.