DEV Community

GG LL
GG LL

Posted on

How to Compress a Video to a Specific File Size in the Browser

#privacy #javascript #tutorial #webdev

Compressing a video to “about 10MB” or “under 25MB” is not the same problem as choosing a generic quality preset. A target file size is a bit-budgeting problem: the video stream, audio stream, MP4 container, and encoder variation all have to fit inside the same fixed number of bytes.

This article explains the calculation, the failure cases, and a practical browser-based workflow that can get close to a target without uploading the original video.

1. Start with the total bitrate budget

A useful approximation is:

total bitrate (kbps) = target size (MB) × 8,000 ÷ duration (seconds)
Enter fullscreen mode Exit fullscreen mode

This uses decimal megabytes, which is usually how upload limits are communicated. The result is the combined budget for video, audio, and overhead.

Example: two minutes under 25MB

For a 120-second clip:

25 × 8,000 ÷ 120 = 1,667 kbps total
Enter fullscreen mode Exit fullscreen mode

If the audio is 128 kbps:

1,667 - 128 = 1,539 kbps before overhead
Enter fullscreen mode Exit fullscreen mode

Reserve roughly 5% to 10% for container overhead and encoder variation:

1,539 × 0.92 ≈ 1,416 kbps video bitrate
Enter fullscreen mode Exit fullscreen mode

So a starting video bitrate around 1,400 kbps is reasonable. It is still an estimate, not a guarantee.

2. Why the first export can miss the target

Even when the math is correct, the encoded file can land above or below the requested size.

  • Variable-bitrate encoders spend more bits on complex scenes.
  • Fast motion, film grain, screen noise, and detailed gameplay are expensive to encode.
  • Audio, subtitles, metadata, and the MP4 container consume part of the budget.
  • Browser codecs and WebAssembly encoder behavior vary across devices.
  • A source codec may need to be decoded and re-encoded rather than copied.

This is why a production target-size workflow should measure the first result and retry when it is too large.

3. A practical target-size pipeline

A browser compressor can use the following process:

  1. Read the source duration, dimensions, audio state, and container.
  2. Calculate the total bitrate budget from target size and duration.
  3. Subtract the planned audio bitrate.
  4. Reserve overhead and safety headroom.
  5. Choose a maximum resolution that makes sense for the available bitrate.
  6. Encode locally with FFmpeg/WebAssembly when supported.
  7. Measure the exported file.
  8. If it is too large, reduce the video bitrate and retry.

A simple retry adjustment looks like this:

next bitrate = current bitrate × target bytes ÷ actual bytes × safety factor
Enter fullscreen mode Exit fullscreen mode

For example, if the first export is 28MB and the target is 25MB, the next pass should not merely subtract 3MB from an arbitrary quality value. Scale the bitrate using the measured ratio, then add a small safety factor below 1.0.

4. Resolution still matters

A 4K frame contains four times as many pixels as 1080p. At a strict 10MB target, keeping 4K resolution can force the bitrate per pixel so low that the result looks worse than a clean 720p or 1080p export.

A sensible workflow should treat resolution as part of the size budget:

  • Very small target or long duration: consider 720p.
  • Moderate target and short clip: 1080p may work well.
  • 4K: keep it only when the duration is short or the target is large enough.

5. Trim before compressing

Removing an unwanted intro or outro is often better than reducing visual quality.

If a 120-second video is shortened to 90 seconds while the target remains 25MB, every remaining second gets a larger share of the bitrate budget. That can preserve more detail without changing the upload limit.

This is also why a lightweight start/end trimmer belongs in the same workflow as compression. The best order is usually:

choose file → trim duration → calculate bitrate → compress → measure → retry if needed
Enter fullscreen mode Exit fullscreen mode

6. Why process the file locally?

Traditional online compressors upload the original file before processing it. A local-first browser workflow can avoid that transfer when the browser supports the required decoder and WebAssembly runtime.

Local processing is useful for private recordings, client previews, meeting videos, screen captures, and files that are simply too large or slow to upload twice.

The tradeoff is that performance depends on the user's device, memory, browser, and codec support. Local-first does not mean every format works perfectly everywhere.

7. A transparent implementation note

I built CreatorZip around this workflow. It offers Automatic, 10MB, 25MB, and custom-size goals, plus start/end trimming before browser-based compression. The launch version is free and does not require an account.

The target-size logic uses safety headroom and can make a smaller retry when the first pass misses the goal. The interface also makes the limitations explicit: final size and quality still depend on duration, motion, codecs, and device performance.

If you want to check the math before encoding, use the CreatorZip video bitrate calculator. There is also a longer target-size compression guide.

Target-size compression is not magic. It is measurement, budgeting, and iteration—and it works much better when trimming, resolution choice, bitrate planning, and retry logic are treated as one pipeline.

Top comments (0)