Video Size Estimator

Features

• Two modes from one relation: bitrate to size, capacity to recording time
• ⚠️ Bits divided by eight gives bytes; skipping that makes the result eight times too large while still looking plausible
• ⚠️ Both GB (drive, 1000³) and GiB (OS, 1024³) conventions, a difference of 7.4%
• ⚠️ The audio track is included: it can be 19% of a low-bitrate file
• Bitrate can be entered directly or estimated from resolution, frame rate and codec
• ⚠️ ProRes and uncompressed are flagged as intermediate formats one to two orders of magnitude larger
• One duration per line (45 means minutes, 1:30:00 means hours), with totals and a per-hour figure
• In capacity mode, one GB figure per line gives the recording time
• Everything runs in your browser; no network requests

How to use

1. Pick the mode: size from bitrate, or recording time from capacity
2. Choose resolution, frame rate and codec; enter a real bitrate if you have one
3. Enter durations (45 or 1:30:00) or capacities, depending on the mode
4. The result shows both the byte count and the figure in the chosen convention

FAQ

Why not just express bitrate in gigabytes?

Because bitrate is measured in bits per second while file size is in bytes, a factor of eight apart. What makes the mistake dangerous is that the wrong answer looks reasonable: an hour at 100 Mbps computes to 45 GB while the real figure is about 5.6 GB, and 45 GB is not absurd for an hour of 4K, so nothing feels off. This tool works in bits internally and divides by eight only when displaying.

Why is my number different from what the file manager shows?

Most likely the GB versus GiB gap. Drive manufacturers label 10⁹ bytes as 1 GB while operating systems display 2³⁰ bytes as 1 GiB, so the same file differs by 7.4% between the two. The default here is the drive convention, since that is what the remaining capacity on your card refers to; switch to the OS convention and the figures line up with the file manager. Beyond that, bitrate is variable: a still interview compresses far better than fast sport, so an estimate from an average bitrate naturally varies by about 30%.

Why is ProRes so large?

Because it was never designed for delivery. H.264, H.265 and AV1 use inter-frame prediction and lossy compression to shrink files by one or two orders of magnitude, at the cost of quality every time you decode and re-encode. ProRes and uncompressed formats do almost no inter-frame compression, so every frame decodes on its own and repeated edits do not degrade the image, which is exactly what an editor needs. Being one to two orders of magnitude larger is the feature, not the flaw, and the workflow is to edit in an intermediate codec and compress on export.

How accurate is the estimated bitrate?

Right order of magnitude, about 30% either way. The estimate uses a bits-per-pixel factor, while a real encoder varies its bitrate with scene complexity: a static interview and fast sport at the same resolution and frame rate can differ by more than a factor of two. So whenever you can get the real figure, which ffprobe prints and most editors show on export, type it in. The estimate is for the stage before editing, when you only want to know whether the card is big enough.