🎥 Video Bitrate & File Size Calculator

Ask ten editors what bitrate to use for a one-hour export and you'll get ten different answers, most of them cargo-culted from a forum post written in 2015. The subject seems technical enough that people accept received wisdom without questioning it — and the received wisdom is often wrong in ways that cost time, storage, and quality. Let's fix that.

The Formula Nobody Teaches You

Video file size is almost embarrassingly simple once you see it written out. Take your video bitrate in megabits per second, add your audio bitrate (converted to the same unit), multiply by the duration in seconds, then divide by eight. That last step converts from bits to bytes, because storage is measured in bytes, not bits. The confusion between Mb (megabits) and MB (megabytes) is responsible for more botched deliverables than any other single mistake in this industry.

So for a 10-minute video at 8 Mbps video bitrate and 192 kbps audio: (8 + 0.192) × 600 ÷ 8 = roughly 614 megabytes before container overhead. Add about 2% for an MP4 container and you land near 626 MB. That's your estimate — accurate enough for any practical planning purpose.

The Biggest Myth: "Higher Bitrate Always Means Better Quality"

Up to a point, yes. Beyond that point, you're buying file size, not quality. Every encoder — H.264, H.265, AV1, VP9 — has a floor where the source material runs out of information to encode. Push past that floor and you're just stuffing the container with redundant data. A 4K 60fps source that looks perfect at 40 Mbps looks identical at 80 Mbps. The extra 40 Mbps buys nothing except a file twice as large.

The practical ceiling depends heavily on resolution and codec. For H.264, 1080p30 typically maxes out around 8–12 Mbps for most content. H.265 achieves comparable quality at roughly half that. AV1 goes further still — which is why streaming platforms have been quietly migrating toward it. If you're still encoding 1080p H.264 at 20 Mbps for a web upload "just to be safe," you're wasting storage and probably getting transcoded back down to 6 Mbps by the platform anyway.

Variable Bitrate Changes Everything

The calculator here works with constant bitrate (CBR) math — bitrate × duration = size. That's the baseline, and it's correct for CBR encodes. But most modern encoders default to variable bitrate (VBR), which means the actual file size can vary from your estimate by 10–30%. VBR allocates more bits to complex scenes (fast motion, high detail) and fewer to simple scenes (static background, talking head). The result is better quality per megabyte, but your file size becomes harder to predict without running the encode.

Two-pass VBR encoding gives you the best of both worlds: you specify a target file size and the encoder figures out where to spend the bits. The first pass analyzes the entire video; the second pass uses that analysis to allocate bitrate intelligently. This is how the old DVD-ripping community hit exact file sizes with remarkable consistency — tools like Handbrake's two-pass mode are doing the same calculation this calculator does, just dynamically across the timeline.

Audio Bitrate Is Not an Afterthought

On a 30-second advertisement, audio bitrate is negligible. On a 3-hour film at 192 kbps stereo, the audio track adds about 259 MB — more than an entire 4-minute YouTube video at the same audio quality. For long-form content especially, your audio bitrate choice meaningfully affects your storage budget.

And here's the thing most guides skip: audio bitrate also has a quality ceiling, and it's lower than people think. A well-encoded 128 kbps AAC file is genuinely hard to distinguish from 320 kbps in a blind test for most listeners. The sweet spot for stereo dialogue and music is typically 128–192 kbps AAC. Going above that is almost always spending bits you'll never hear. The exception is lossless audio for archival masters, where you'd use FLAC or PCM and the calculation changes entirely.

Container Overhead Is Real but Small

MP4 and MKV containers add a few percent overhead for metadata, chapter markers, subtitle tracks, and index tables. For a 10-minute video, this is maybe 10–20 MB — worth knowing but rarely a budget-buster. MOV and AVI can run higher, especially MOV files exported from Final Cut Pro with embedded preview thumbnails and metadata bloat. If you've ever wondered why a QuickTime export seems bigger than the equivalent MP4 at the same settings, now you know.

The 1 GB Per Hour Heuristic — and Why It Breaks

You'll hear "1 GB per hour" thrown around as a rule of thumb. At 2.2 Mbps total bitrate, this is mathematically true. That's acceptable quality for 720p content, arguably passable for 1080p talking-head footage, and completely inadequate for 4K or any content with fast motion. The heuristic comes from an era of 720p streaming and doesn't map onto modern production work.

Better heuristics by resolution: 1080p30 web delivery needs roughly 4–8 GB per hour at H.264, or 2–4 GB at H.265. 4K30 sits around 20–40 GB per hour at H.264, 10–20 GB at H.265. These are real-world ranges, not theoretical minimums. Anything below the bottom of these ranges and you'll notice blocking artifacts and detail loss in high-motion sequences.

Practical Use Cases for This Calculator

The "bitrate to file size" mode is what you use before you encode — you know your settings, you want to know how much space to reserve on a drive, or whether a file will fit under a client's 2 GB upload limit. The "target size to bitrate" mode is what you use when the constraint comes first — the client sends a 500 MB limit, or a platform has a maximum upload size, and you need to reverse-engineer the bitrate that makes your content fit.

For that second mode, always include your audio bitrate in the calculation before solving for video bitrate. A common mistake is to divide the total size budget by duration and assume that's your video bitrate. It isn't — you have to subtract the audio portion first, then solve for video. Otherwise you'll encode a file that comes in 5–10% too large and have to redo the whole thing.

Streaming Platforms Transcode Your Upload Anyway

This is the one that consistently surprises people: YouTube, Vimeo, and most platforms immediately re-encode everything you upload. Your carefully crafted 50 Mbps master gets torn apart and rebuilt as multiple quality levels, typically ranging from 360p at around 1 Mbps to 4K at 35–45 Mbps (for YouTube). Uploading at a higher bitrate doesn't mean viewers see a higher bitrate — it means the platform has better source material to transcode from.

The practical implication: for streaming delivery, encode your upload master at a high-quality setting (at least the platform's recommended bitrate, which is typically 8–40 Mbps depending on resolution), but don't stress about going much higher. Once you're above the "visually lossless" threshold for your codec and resolution, extra bits in the upload file don't improve the viewer's experience one bit. They just take longer to upload and process.

When the Math Matters Most

Budget the math when you're filling hard drives, pricing cloud storage, planning encoding queues for multi-episode production, or hitting specific platform upload limits. Ignore the math and you're guessing, and guessing in video production usually means re-encoding — which burns time that could have been spent on something worthwhile. A 3-hour encode on a slow machine that comes in 200 MB over a client's limit is a brutal way to learn this lesson.

The formula is simple. Bitrate times duration divided by eight, plus audio, plus overhead. Everything else is detail on top of that arithmetic foundation.