Video File Size / Bitrate Calculator

Bitrate and file-size calculations describe a live production decision

Bitrate estimation runs when confirming a delivery file will meet a client’s size requirement, checking whether a clip fits a platform’s upload cap, planning storage for a video server, or deciding encoder settings before a long render. The inputs — bitrate, duration, target file size — directly specify the technical parameters of a project in flight.

“What bitrate do I need for a 60-minute video to fit inside 8 GB?” answers with a number, but the question encodes the project’s duration, quality expectations, and delivery constraints. The combination of values is a technical fingerprint of a specific piece of work. Online calculators that accept these inputs via a form and return a result via a server round-trip transmit production specifications they were never meant to hold.

Arithmetic does not require a server

File-size calculation is (video kbps + audio kbps) × 1000 × duration (s) / 8. Reverse calculation is video kbps = (target bytes × 8 / 1000 / duration) - audio kbps. Neither formula involves a lookup, a model, or an API. Platform presets (YouTube, X, TikTok, Instagram recommended bitrates) are public constants that live in the tool’s source code.

Despite this, some online calculators implement the UI as a form submission to a server endpoint. There is no technical reason for the round-trip. It serves the operator’s interests (analytics, ad impressions) at the cost of transmitting the user’s project specification to infrastructure outside their control.

All calculations run as JavaScript arithmetic — zero network requests

This tool computes fileSizeBytes = (videoBps + audioBps) × durationSec / 8 and displays the result in binary MB (1024²). Reverse calculation uses videoKbps = (targetBytes × 8 / 1000 / durationSec) - audioKbps. Platform preset bitrates are hardcoded constants based on their respective public specifications — no external API is called.

Open DevTools Network tab while computing — no request fires beyond the initial tool load. Entered values and results exist only in browser page memory. Source is on GitHub.

Project specifications are business information — calculate them locally

Bitrate planning is part of production decision-making. Keeping it in the browser means client project parameters, delivery constraints, and encode decisions stay on the device where the work is being planned — not in a third-party server’s access logs that had no business receiving them.

CBR / VBR / CRF / ABR and what each rate-control mode is actually optimising

Rate control comes in roughly four flavours. CBR (Constant Bit Rate) holds the bitrate steady across all scenes — required for live streaming and broadcast where the delivery pipe is fixed. VBR (Variable Bit Rate) allocates more bits to busy scenes and fewer to static ones, configured by setting an average and a maximum bitrate. CRF (Constant Rate Factor) is the quality-target mode of libx264 / libx265 / libaom-av1: rather than targeting bitrate, it varies the per-frame quantization parameter (QP) to maintain perceived quality. ABR (Average Bit Rate) sits between CBR and VBR, constraining the average without enforcing a per-second cap.

Two-pass encoding (-pass 1 -pass 2) refines VBR / ABR accuracy: the first pass profiles every frame’s complexity and writes a log; the second pass distributes bits optimally. For the same target file size, two-pass typically yields 10–20% better quality than single-pass at roughly double the encoding time. For premium streaming delivery (Netflix, Amazon Prime Video), two-pass is effectively required, and x264 slow or higher presets are the norm. B-pyramid (hierarchical B-frame referencing) and psy-rd (psycho-visual rate distortion) lift quality further at the same CRF or bitrate, and tuning presets such as -tune film or -tune animation bundle relevant flags together.

Recommended bitrates across major platforms and live workflows

YouTube SDR recommends 35–45 Mbps at 2160p (4K), 16 Mbps at 1440p, 8 Mbps at 1080p, 5 Mbps at 720p, 2.5 Mbps at 480p, and 1 Mbps at 360p. HDR scales by roughly 1.25×. 50/60 fps content asks for 1.5× the table values. These figures buffer against the YouTube re-encode that follows upload; the actual delivery bitrate is adaptive per viewer’s bandwidth.

X / Twitter caps 1080p at 25 Mbps; TikTok runs 9:16 at 4.5–6 Mbps; Instagram Reels recommends 3.5 Mbps. Vimeo recommends a higher 10–20 Mbps for 1080p than YouTube. OBS Studio live streaming sits at 4500–6000 Kbps for Twitch and up to 9000 Kbps for YouTube Live. Theatrical DCP uses JPEG 2000 at 250 Mbps — a different regime entirely. CBR is the right default for live streaming; CRF + two-pass is the right default for on-demand. Once a target bitrate is decided here, video-compress applies it as an actual encode, and video-codec-info is the natural pre-step for reading the current codec / bitrate off a source file before planning the next pass.