Video Bitrate Calculator

About the Video Bitrate Calculator

Video bitrate is the amount of data per second a video file consumes, measured in kilobits per second (kbps) or megabits per second (Mbps). The fundamental relationship is simple: file size (in bits) = bitrate (in bits/s) × duration (in seconds). Convert bits to bytes by dividing by 8, then to MB by dividing by 1 000 000 (decimal, the convention used by YouTube, Twitch, Vimeo, AWS, and every cloud storage provider) — or by 1 048 576 if you insist on binary MB (older OSes still report this way). This calculator does that arithmetic in both directions and adds a recommendation engine that looks up a sensible bitrate for your resolution and codec combination, drawn from the published encoder presets of YouTube, Netflix, Apple, and the AOM Encoding Guidelines for AV1. The recommendation respects the rough efficiency tiers: H.264 (AVC, 2003) is the baseline; H.265 (HEVC, 2013) needs about 50% the bitrate of H.264 for matching quality; AV1 (2018) needs about 30% less than HEVC; VP9 sits between H.264 and HEVC. Use the recommendation as a starting point, then refine after test renders — content complexity (talking head vs sports), motion, grain, and the encoder's CRF/QP target all shift the optimal bitrate by ±30%.

How exactly is bitrate converted to file size and what units does this calculator use?

The tool multiplies bitrate (in bits per second) by the total duration in seconds. The result is in bits; divide by 8 to get bytes. From there it converts to kilobytes, megabytes, and gigabytes using decimal SI prefixes — 1 KB = 1 000 bytes, 1 MB = 1 000 000 bytes, 1 GB = 1 000 000 000 bytes — matching the convention used by YouTube's upload limits, Twitch's bitrate guidelines, AWS S3, and basically every internet platform since 1998. Windows File Explorer still reports binary KiB/MiB/GiB (1024-based) and labels them KB/MB/GB, which is technically wrong per IEC 80000-13 and trips people up when their 10 GB file shows as 9.31 GB. If you need binary units, multiply our decimal output by 0.9313 to convert MB to MiB.

What bitrate should I use for 1080p, 4K, and 8K with H.264, H.265, and AV1?

Industry-standard ranges for high-quality streaming (no visible artefacts on typical content): 1080p30 — H.264 8–12 Mbps, H.265 5–8 Mbps, AV1 3–6 Mbps; 1080p60 — H.264 12–18 Mbps, H.265 7–12 Mbps, AV1 5–8 Mbps; 1440p30 — H.264 16 Mbps, H.265 10 Mbps, AV1 7 Mbps; 4K (2160p30) — H.264 35–45 Mbps, H.265 20–25 Mbps, AV1 14–18 Mbps; 4K (2160p60) — H.264 53–68 Mbps, H.265 30–40 Mbps, AV1 20–27 Mbps; 8K (4320p60) — H.264 not practical, H.265 80–120 Mbps, AV1 50–80 Mbps. YouTube's recommended upload bitrates sit at the upper end of these; for archival masters use 1.5–2× the streaming numbers. For Twitch (which still mandates H.264), the platform-imposed cap is 6 000 kbps for partners at 1080p60, which is why streamers favour 936p or 720p for a cleaner look at that bitrate.

What's the difference between H.264, H.265 (HEVC), VP9, and AV1 and which should I pick?

H.264 (AVC, MPEG-4 Part 10, finalised 2003) — universal compatibility, hardware decode on every device made since 2008, the safe choice for delivery; encode speed is fast, but compression efficiency is now 20 years old. H.265 (HEVC, 2013) — ~50% bitrate reduction at matching quality versus H.264, hardware decode on iPhone 6+, Apple Silicon, most Android since 2015, and modern Smart TVs, but encumbered by complex patent pools (MPEG LA, Velos Media, HEVC Advance) which is why YouTube and Twitch never adopted it. VP9 (Google, 2013) — royalty-free, similar efficiency to HEVC, ubiquitous on YouTube but limited consumer device decode. AV1 (Alliance for Open Media, 2018) — royalty-free, ~30% better than HEVC, supported by Netflix, YouTube, Twitch (beta), hardware decode on Intel 11th-gen+, AMD RDNA3+, Apple A17 Pro+, modern Android. Pick H.264 for maximum compatibility, AV1 for delivery at the lowest bitrate, HEVC for archival because the file is smaller than H.264 and the patents do not matter for personal storage.

Why does my actual file end up bigger or smaller than the calculator predicts?

Three reasons. First, audio — the calculator only models video bitrate; audio adds 96–320 kbps for stereo AAC or up to 1 Mbps for lossless Dolby Atmos. For a 1-hour 1080p H.264 video at 10 Mbps video plus 192 kbps AAC, the audio is 0.86% of the total — usually negligible but matters at low video bitrates. Second, container overhead — MP4, MKV, and WebM add 0.5–2% for the moov atom, indexing, and per-frame headers. Third, variable bitrate (VBR) — most encoders run in CRF or two-pass VBR mode and target an *average* bitrate; complex scenes spike higher and simple scenes drop lower, so a 10 Mbps target produces a file that matches duration × 10 Mbps to within ±5%. If your file is 20%+ off, check whether you set bitrate in kbps but the encoder expected Mbps (1000× error) or you confused bits with bytes (8× error).

How do streaming platforms compress my upload further and why should I upload at a higher bitrate?

Every major platform re-encodes your upload to multiple bitrates for adaptive streaming. YouTube transcodes to AV1, VP9, and H.264 across 7+ bitrate tiers from 144p to 8K. Twitch passes the source bitrate to VOD storage but transcodes lower qualities for non-partner viewers. Instagram and TikTok aggressively re-encode to ~3 Mbps at 1080p, regardless of your upload. The implication: upload at the highest bitrate the platform's *upload* spec accepts, not the bitrate of the lowest viewing tier. YouTube's recommended H.264 1080p upload is 8–12 Mbps; bumping to 16 Mbps gives YouTube's transcoder more signal and reduces compression artefacts in the final 1080p H.264 output. The trade-off is upload time and the platform's own cap — YouTube allows up to 256 GB or 12 hours per file; Twitch caps a single VOD at around 200 Mbps source.

What is CRF and how does it relate to a target bitrate?

CRF (Constant Rate Factor) is the quality-targeting mode in x264, x265, libvpx-vp9, and SVT-AV1. Instead of fixing bitrate, you fix a quality target on a roughly logarithmic scale: x264/x265 use 0–51 where 23 is the default and lower means better quality (16–18 is visually lossless for most content), AV1 uses 0–63 with 30 as a typical default. CRF produces variable file size depending on content — a CRF-23 H.264 encode of a talking head is far smaller than the same CRF-23 encode of fast-cut action. Use CRF when quality matters more than size (master archives, YouTube uploads). Use target bitrate (1-pass VBR or 2-pass VBR) when you must hit an exact size or stream within a platform cap (Twitch's 6 Mbps, broadcast SDI lanes). Many editors export CRF for archive then transcode to bitrate-targeted versions for delivery.

Why use HH:MM:SS instead of just typing seconds?

Both formats produce identical results; HH:MM:SS is offered because human brains do not naturally compute total seconds. A feature film at 142 minutes is 8 520 seconds — most people cannot derive that quickly, but they can read 2:22:00 directly off a player. The tool parses both: '7200', '7200s', '2:00:00', '120m', and '2h' all resolve to 7 200 seconds. For frame-accurate calculations, multiply duration by frame rate and divide by frame rate after summing the frame-level bit allocations (this is how broadcast and DCP estimators work); for typical YouTube/Twitch planning, second-level precision is plenty since you never hit the platform's hard cap exactly.

What's the most accurate way to plan a Twitch stream or YouTube upload at a target file size?

Start with your total duration in seconds, fix the target file size in MB (decimal). Compute video bitrate = (file_size_in_MB × 8 × 1000) / duration_in_seconds = bitrate in kbps. Then subtract your audio bitrate (typically 160 kbps for AAC stereo, 320 kbps for Opus, 1411 kbps for FLAC, 384 kbps for Dolby Digital 5.1) to get your encoder's video bitrate target. This tool now does that subtraction for you: enter your audio bitrate in the optional field and the 'required average bitrate' result splits into Video / Audio / Total, so the Video figure is exactly what you pass as the encoder's -b:v value. Use two-pass VBR if your encoder supports it — the first pass profiles the content's complexity, the second pass distributes bits intelligently. For YouTube, do not over-optimise: aim for 1.5× the YouTube-recommended bitrate so their re-encode has clean signal to work with. For Twitch, you have a hard cap (6 Mbps for partners at 1080p) so use CBR (constant bitrate) instead of VBR to guarantee you never exceed the cap mid-stream.

What bitrate fits a 2-hour movie in 4 GB?

A 2-hour movie is 7 200 seconds and 4 GB decimal is 4 000 MB = 32 000 000 000 bits. Total bitrate = 32 000 000 000 / 7 200 ≈ 4 444 kbps ≈ 4.44 Mbps. Subtract a 160 kbps AAC stereo track and you have about 4 284 kbps ≈ 4.28 Mbps for video — comfortably enough for a clean H.265 or AV1 1080p encode, or a slightly soft H.264 1080p. Enter duration 2:00:00, file size 4 GB, and audio bitrate 160 kbps in this tool and it returns exactly that Video / Audio / Total split. For a sharper 1080p H.264 result at 4 GB, either accept the lower bitrate with two-pass VBR or switch the codec to HEVC/AV1 which reach the same quality at roughly half the bitrate.