Video File Size Calculator

How video file size is calculated

File size is bitrate multiplied by time. A video stream spends a fixed number of bits on every second of footage (its bitrate), the audio track spends its own, and the file is just the sum over the whole duration:

size (bytes) = (video bitrate + audio bitrate) × duration ÷ 8

The ÷ 8 converts bits to bytes. For example, a clip at 10 Mbps of video plus a 320 kbps audio track running one minute works out to (10,000,000 + 320,000) × 60 ÷ 8 ≈ 77 MB.

Two practical notes the calculator builds in. First, these are decimal megabytes (1 MB = 1,000,000 bytes), which is how drive makers and most upload limits count; your operating system reports binary MiB (1 MiB = 1,048,576 bytes), so it will show the same file as roughly 5% smaller. Second, the raw math is the elementary stream — a real MP4 or MOV adds about 2–5% for the container, muxing and metadata. Treat the result as a close estimate, not an exact byte count.

Why bitrate — not resolution — controls size

It is a common surprise: resolution does not directly set file size, bitrate does. A 4K clip and a 1080p clip encoded at the same bitrate occupy the same space. What changes is how that bitrate looks — spread 8 Mbps across 4K's eight million pixels and detail falls apart, while the same 8 Mbps over 1080p looks clean. That is why higher resolutions and frame rates are given more bitrate, and it is the bitrate increase — not the pixel count itself — that grows the file. If you want a recommended bitrate for a given resolution, codec and quality, use the Video Bitrate Calculator; this page turns whatever bitrate you choose into a size, and back again.

Fitting a video to a target size

To hit a ceiling — a 25 MB email attachment, a Discord upload, a hard client spec — work backwards. The target size and the duration fix a total bit budget; subtract the audio track and what remains is the video bitrate you can afford:

video bitrate = (target MB × 8,000,000 ÷ duration in seconds) − audio bitrate

The "Fit to target size" mode does this for you and warns when a target is impossible — for instance when the audio track alone already exceeds the budget, or when the leftover video bitrate is too low to look acceptable. Remember this is the math: actually producing that smaller file means re-encoding it in an editor or a dedicated video compressor (coming soon to VoiceDeck). This page tells you the number to aim for; it does not compress the file itself.

Codec data rates: the reference table

The codec-preset mode above is built on the published data-rate tables below — the same numbers the camera and NLE vendors print, not estimates. Pick a family, variant, resolution and frame rate and the page uses exactly these figures; a combination with no published rate is simply not offered, because interpolating a vendor's table would invent data.

Apple ProRes (target Mbit/s — Apple ProRes white paper, April 2018). ProRes is a variable-bitrate codec: these are targets, and the actual rate floats a little with image content. The 4444 figures assume no alpha channel.

Avid DNxHR (Mbit/s — Avid's published DNx data-rate table, unified 2025 naming). Unlike ProRes, DNxHR rates are fixed and bit-exact: the published number is what lands on disk, whatever the content. Avid publishes megabytes per second; the figures here are multiplied by 8 to match the Mbit/s convention of the other tables.

Sony XAVC (maximum Mbit/s — Sony's XAVC workflow documentation). XAVC-I is intraframe — every frame stored whole, like ProRes — while XAVC-L is Long GOP, trading editability for a third of the rate.

H.264 delivery (Mbit/s — YouTube's recommended upload encoding settings, SDR). These are recommendations, not limits; where YouTube publishes a range the calculator shows the upper end and discloses the range in the result.

Two omissions are deliberate. ProRes RAW has no absolute published rates — Apple specifies it only as bands ("between 422 and 422 HQ" for RAW, "between 422 HQ and 4444" for RAW HQ) — so any single number here would be invented; use the band edges from the ProRes table as your bracket instead. The legacy DNxHD name-numbers (superseded by DNxHR) and the XAVC 60/200 Mbit/s classes are likewise left out until they can be verified against vendor text.

A worked example: one hour of UHD

Take one hour of ProRes 422 HQ at UHD 29.97. The table gives 884 Mbit/s, and the arithmetic is one line:

884 Mbit/s × 3,600 s ÷ 8 = 397,800 MB ≈ 397.8 GB

The same hour in XAVC-I 4K (300 Mbit/s at 29.97) is 300 × 3,600 ÷ 8 = 135,000 MB = 135 GB, and in H.264 at YouTube's recommended 45 Mbit/s for 2160p it is 45 × 3,600 ÷ 8 = 20,250 MB = 20.25 GB. That is the mezzanine-to-delivery spread: 884 ÷ 45 ≈ 19.6× — the same pictures, the same hour, differing by a factor of twenty purely because of each codec's data rate.

Mezzanine vs delivery codecs

The spread above is not waste; it is division of labour. Mezzanine codecs — ProRes, DNxHR, XAVC-I — store every frame whole (intraframe), so any frame can be decoded alone, scrubbed, cut and re-rendered many times without compounding artefacts. Editors and colorists pay for that in disk space and card capacity, which is exactly what this page and the Memory Card Record Time Calculator help you budget.

Delivery codecs — H.264 and H.265 — are Long GOP: most frames are stored as differences from their neighbours, which is dramatically smaller but slow to seek and destructive to re-edit. So the professional workflow is to shoot and edit in a mezzanine codec, then export H.264 or H.265 once, at the end, for the client or platform. As a rule of thumb H.265 delivers equivalent visual quality at roughly half the H.264 rate, which is why it dominates 4K delivery wherever it is supported.

1. Choose a codec preset (ProRes, DNxHR, XAVC, H.264) or type in any bitrate directly.

2. Enter resolution, frame rate and duration — or give a target size and solve for bitrate instead.

3. Check the worked Mbit/s-to-GB arithmetic, then see how long a card holds on the memory card record-time grid.