Video Bitrate Calculator

Background.

Video bitrate is the number of bits a video stream spends on every second of picture, and it is the single lever that decides both how good an export looks and how much room it takes up. Everything downstream of it — whether a 4K master fits on a 512 GB card, whether a webinar recording clears an email attachment limit, whether an archive of last season's footage fits the drive you already own — falls out of one small equation relating bitrate, runtime and file size. This calculator solves that equation in whichever direction you need it.

The arithmetic is genuinely simple, and it is worth seeing it stated plainly because the trap in it is a unit trap rather than a maths trap. Bitrate is quoted in megabits per second. File size is quoted in megabytes and gigabytes. A byte is eight bits, so a stream running at 8 Mbps is laying down one megabyte of data per second, not eight. Skip the division by eight and every estimate you make is exactly eight times too large. Multiply the total stream rate by the runtime in seconds, divide by eight, and you have the byte count; everything else on this page is that number expressed in different units.

The second thing the equation needs is the total stream rate, not just the video figure. A finished file is a container — MP4, MOV, MKV, MXF — holding a video elementary stream and one or more audio elementary streams multiplexed together. The container's data rate is the sum of what is inside it. On a heavily compressed web export the audio is a rounding error: 384 kbps of stereo AAC alongside 8 Mbps of H.264 adds under 5 percent. On a long podcast-style talking-head recording encoded at 1 Mbps, that same audio track is more than a quarter of the file. This calculator always asks for both and always adds them, so the audio never quietly disappears from your estimate.

There is also a reporting ambiguity worth surfacing rather than hiding. NIST documents two competing definitions of the prefixes: the SI decimal convention where a gigabyte is 1,000,000,000 bytes, and the IEC binary convention where a gibibyte is 2^30 = 1,073,741,824 bytes. Memory-card packaging, drive marketing and Apple's own published ProRes data-rate tables all use the decimal convention. Windows File Explorer uses the binary one while still printing the label 'GB'. The gap is about 7 percent at gigabyte scale, which is exactly wide enough to make a file that 'should' fit refuse to. This page prints both, side by side, so you can see which convention your storage figure came from.

Finally, a note on what the answer means. The equation is exact for constant bitrate encoding and an estimate for variable bitrate, which is what most modern encoders actually produce. Apple's ProRes documentation is unusually candid about this: ProRes is a variable bitrate codec, but the actual data rate is usually close to the published target, with a per-frame ceiling roughly 10 percent above target. Treat the result as a planning figure with a few percent of slack, not a guarantee — and if you need the file to fit inside a hard ceiling, solve for bitrate rather than for size and give yourself the margin deliberately.

What is video bitrate calculator?

Bitrate is the rate at which a coded media stream delivers data, conventionally expressed in kilobits or megabits per second. For video it is the primary quality control: within a given codec and resolution, more bits per second means fewer compression artefacts, better handling of motion and grain, and a proportionally larger file. Bitrate is not the same thing as resolution — a 4K file at 5 Mbps will look considerably worse than a 1080p file at the same rate, because the same bit budget is being spread over four times as many pixels.

File size is bitrate integrated over time. Because a byte is eight bits, the byte count of a media file is the total stream rate in bits per second multiplied by the runtime in seconds and divided by eight. The 'total stream rate' is the sum of every elementary stream in the container: video plus each audio track, plus a small allowance for the container's own headers, index tables and packet overhead. That last component is genuinely variable — it depends on the container format and the packetiser — so this calculator exposes it as an optional input rather than baking in an invented constant.

How to use this calculator.

1. 01Choose which of the three quantities you are missing: file size, bitrate, or runtime.
2. 02Enter the video bitrate in megabits per second — this is the number in your encoder's 'target bitrate' field, not a byte figure.
3. 03Enter the audio bitrate in kilobits per second, or 0 for a video-only master. YouTube recommends 128 kbps mono, 384 kbps stereo, 512 kbps for 5.1.
4. 04Enter the runtime in minutes, or the storage budget in decimal gigabytes, depending on what you are solving for.
5. 05Optionally set a container overhead percentage — 1 to 2 percent is a realistic allowance for MP4 muxing; leave it at 0 for the pure elementary-stream size.
6. 06Read the result, then compare the decimal GB and binary GiB figures against whichever convention your storage device reports in.

The formula.

Start by putting both streams into the same unit. Video bitrate arrives in megabits per second and audio bitrate in kilobits per second, so the audio figure is divided by 1,000 before the two are added: totalMbps = videoMbps + audioKbps / 1000. Multiplying by 1,000,000 converts that to bits per second.

Multiply bits per second by the runtime in seconds to get the total bit count, then divide by 8 to convert bits to bytes. Any container overhead allowance is applied as a multiplier of (1 + o/100) on the result. That single line — bytes = totalBitsPerSecond × seconds × (1 + o/100) / 8 — is the whole calculation, and the other two modes are the same equation rearranged.

Solving for bitrate: totalBitsPerSecond = bytes × 8 / (seconds × (1 + o/100)). The audio bitrate is then subtracted from the total to leave the video budget, which is the number you actually type into the encoder. If the audio track alone already exceeds the budget the calculator refuses rather than returning a negative video bitrate, because a negative bitrate is not a meaningful answer.

Solving for runtime: seconds = bytes × 8 / (totalBitsPerSecond × (1 + o/100)). This is the 'how much fits on the card' question, and it is why the calculator also reports gigabytes per hour — that figure is what camera and codec manufacturers publish, so you can sanity-check the answer against a spec sheet.

The size is then reported three ways. Dividing the byte count by 1,000,000 gives decimal megabytes and by 1,000,000,000 gives decimal gigabytes, the SI convention used by storage manufacturers and by Apple's published ProRes tables. Dividing by 1,073,741,824 (2^30) gives binary gibibytes, the convention Windows File Explorer uses while still printing 'GB'. The two differ by about 7.4 percent at gigabyte scale.

A worked example.

Frequently asked questions.

References& sources.

1. [1]Apple, "Apple ProRes" White Paper (April 2022), Appendix — Target Data Rates. Lists 1920 x 1080 at 60i/30p as 147 Mb/s and 66 GB/hr for ProRes 422, 220 Mb/s and 99 GB/hr for ProRes 422 HQ, and 330 Mb/s and 148 GB/hr for ProRes 4444; also states that ProRes is variable bitrate with a per-frame maximum about 10 percent above target.
2. [2]YouTube Help, "Recommended upload encoding settings" — recommended SDR video bitrates of 8 Mbps for 1080p and 12 Mbps at high frame rate, 16 Mbps for 1440p, 35-45 Mbps for 2160p, plus audio bitrates of 128 kbps mono, 384 kbps stereo and 512 kbps for 5.1.
3. [3]YouTube Help, "Choose live encoder settings, bitrates, and resolutions" — H.264 live streaming bitrates including 10 Mbps for 1080p30 and 12 Mbps for 1080p60.
4. [4]National Institute of Standards and Technology, "Prefixes for binary multiples" — defines the IEC binary prefixes (1 MiB = 2^20 bytes, 1 GiB = 2^30 bytes) alongside the SI decimal prefixes used by storage manufacturers.
5. [5]Microsoft, WAVEFORMATEX structure (mmreg.h) — defines nAvgBytesPerSec as "the required average data transfer rate in bytes per second" and nBlockAlign as (nChannels x wBitsPerSample) / 8, the byte-to-bit relation used for the audio component of the stream.