Video File Size Calculator

Understanding the Video File Size Calculator

A video file size calculator estimates megabytes from resolution, duration, and frame rate. Resolution is a weak predictor on its own, because bitrate determines file size directly and the same resolution can be encoded across an enormous range of bitrates.

How it actually works

Enter resolution tier, duration, and frame rate. The calculator applies megabytes per minute by tier, scales by frame rate relative to 30, and multiplies by duration. Ten minutes of 1080p at 30 frames per second gives about 80 MB.

The deeper context most people miss

The gap between streaming and recording bitrates is the important part. Camera footage is encoded at high bitrate to preserve quality through editing, while delivery encodes are compressed far harder because they only need to look right once. A file size estimate that does not specify which is being described will be wrong by a large factor.

Why codec matters more than resolution

A codec determines how efficiently a given quality is stored, and successive generations have improved substantially. H.264, standardised in 2003, remains the compatibility baseline and is supported essentially everywhere. H.265, also called HEVC, achieves comparable quality at roughly half the bitrate and carries patent licensing complications that slowed adoption. AV1 is royalty-free, achieves further gains over HEVC, and has been adopted by major streaming platforms with hardware decode support now widespread in recent devices. VP9 sits between and is used heavily by YouTube. The practical consequence is that a file encoded in AV1 can be substantially smaller than an H.264 file of equivalent quality, so comparing file sizes without knowing the codec tells you little. Encoding effort matters too: the same codec at a slower preset produces a smaller file at the same quality because the encoder searches harder for efficiencies, which is why encoding speed and file size trade against each other. Two-pass encoding analyses the content before allocating bitrate and outperforms single-pass at a given target size. Content complexity is the other major variable, and it dominates within a codec: a static talking head compresses dramatically better than fast motion, fine detail, film grain, or confetti, which is why a fixed megabytes-per-minute figure is only ever an average across content types.

A worked example: what determines quality at a given size

Eighty megabytes for ten minutes of 1080p works out at roughly 1.1 megabits per second, which is low for 1080p and would look soft on complex content while being adequate for a static screen recording. This illustrates the central point: the same resolution at different bitrates produces very different results, and pushing resolution up while holding bitrate constant makes things worse rather than better, since the same data is spread across more pixels. A well-encoded 720p file frequently looks better than a poorly encoded 1080p file of the same size, which is why streaming services drop resolution when bandwidth is constrained rather than holding resolution and degrading quality. Frame rate scales bitrate roughly proportionally, so 60 frames per second needs roughly double the bitrate of 30 for equivalent quality, which is why high frame rate content is expensive and why the choice should follow the content: sport and gaming benefit from 60, while dialogue and cinematic material generally do not. Variable bitrate encoding allocates more data to complex scenes and less to simple ones, producing better quality per megabyte than constant bitrate and making file size content-dependent rather than predictable, which is why quality-targeted encoding using a constant rate factor is preferred for archival and constant bitrate for streaming where predictable bandwidth matters.

Deciding what settings to use for what purpose

Purpose determines the answer more than any general rule. For recording source footage that will be edited, high bitrate matters because each generation of re-encoding loses quality, and editing compressed footage causes artefacts to compound, which is why cameras record at bitrates far above delivery and why intermediate codecs including ProRes and DNxHD exist specifically to be edited without generational loss at very large file sizes. For final delivery to a platform, the platform re-encodes whatever is uploaded, so uploading at a reasonably high bitrate and letting the platform compress produces better results than pre-compressing hard, and most platforms publish recommended upload specifications worth following. For self-hosted delivery, bitrate must balance quality against bandwidth cost and viewer connection speeds, and adaptive bitrate streaming that offers multiple renditions is the standard approach since it serves each viewer what their connection supports. For archival, lossless or visually lossless encoding preserves the material, and storage is cheaper than reshooting. For sharing over messaging and email, aggressive compression is appropriate and size limits usually govern. Screen recordings compress exceptionally well due to large static areas and benefit from settings tuned for that. And for anything that will be edited later, keeping the original rather than only the delivery version matters, since delivery encodes cannot be restored.

Why streaming looks different from downloading

Adaptive bitrate streaming, which underlies most video delivery, encodes content at several quality levels and switches between them based on measured bandwidth and buffer state. This means the resolution and bitrate a viewer receives varies through playback and frequently starts low while the player establishes conditions, which is why video often looks soft for the first seconds. The player's decisions are opaque to the viewer, so complaints about quality frequently reflect network conditions rather than the source. Content delivery networks distribute renditions geographically to reduce latency and improve throughput. Per-title and per-scene encoding, adopted by several platforms, analyses each piece of content and allocates bitrate according to its complexity rather than applying a fixed ladder, which produces meaningful bandwidth savings on simple content. Live streaming constrains all of this, since encoding must happen in real time with limited lookahead, which reduces efficiency compared with offline encoding and is why live streams generally look worse than on-demand at the same bitrate. Latency and quality trade against each other in live delivery. For anyone publishing video, the practical implication is that the encode you upload is not what viewers receive, so optimising your upload beyond the platform's recommendations delivers little, while ensuring the source is clean and high quality delivers a great deal.

Variations: containers, colour, and delivery formats

Container formats including MP4, MKV, MOV, and WebM package encoded streams with audio, subtitles, and metadata, and they are distinct from codecs, which is a persistent confusion since MP4 is a container that can hold H.264, H.265, or AV1 among others. Audio adds to file size modestly relative to video, typically a few percent, and is frequently overlooked in estimates. Bit depth and chroma subsampling affect both quality and size, with 8-bit 4:2:0 being standard for delivery and 10-bit or higher with less subsampling used in production for grading headroom. HDR increases requirements and needs metadata carried correctly through the chain. Resolution standards include 1080p at 1920 by 1080, 4K UHD at 3840 by 2160, and DCI 4K at 4096 by 2160 which is slightly wider. Frame rates vary regionally with 24 for film, 25 in PAL regions, and 30 or 29.97 in NTSC regions, and mixing them causes judder that is difficult to fix afterwards. For estimating precisely, the reliable method is encoding a representative sample and measuring, since content complexity dominates within any codec and no general figure captures it.

Estimating and choosing video settings

Estimate from bitrate rather than resolution, since bitrate determines file size directly and the same resolution spans an enormous range. Distinguish recording from delivery bitrates, which differ by an order of magnitude, and specify which you mean. Choose codec deliberately, since H.265 achieves comparable quality at roughly half the bitrate of H.264 and AV1 improves further, though compatibility varies. Match frame rate to content, since 60 frames per second roughly doubles bitrate and benefits sport and gaming while adding little to dialogue. Prefer lower resolution at adequate bitrate over higher resolution starved of it, since spreading the same data across more pixels looks worse. Record source footage at high bitrate for anything that will be edited, since generational re-encoding compounds artefacts. Follow the platform's published upload specifications rather than pre-compressing hard, since the platform re-encodes regardless. Keep originals rather than only delivery encodes, which cannot be restored. And encode a representative sample and measure when precision matters, since content complexity dominates any general figure.

What people get wrong

• Estimating file size from resolution alone, when bitrate determines size directly and the same resolution is encoded across an enormous range of bitrates.
• Raising resolution while holding bitrate constant, which spreads the same data across more pixels and produces a worse-looking result than the lower resolution would.
• Comparing file sizes without knowing the codec, when H.265 achieves comparable quality at roughly half the bitrate of H.264 and AV1 improves further still.
• Pre-compressing hard before uploading to a platform, which re-encodes whatever it receives, so a higher quality upload produces a better final result than a pre-compressed one.

Where the math comes from

File Size in MB = Duration in minutes × megabytes per minute for the resolution tier × (Frame Rate / 30). The per-minute figures are averages, and actual size depends on bitrate, codec, encoding effort, and content complexity, with static content compressing dramatically better than fast motion, fine detail, or film grain. Bitrate in Mbps relates to size as MB per minute ≈ Mbps × 7.5.

Questions and answers

Related calculators

Self-Hosted vs API LLM · Meeting Cost · Solar Panel Count · Gift Card Value · Room Air Purifier Size