Compress video or image to a target file size

How the size target is met

1. 1. Budget

   Your target size becomes a bit budget, keeping about 3% in reserve for the MP4 container so the finished file does not creep over the limit.

2. 2. Audio first

   AAC audio that is already small is copied untouched. Otherwise audio is re-encoded at 96 kbps, or 64 kbps mono when space is tight, so the rest of the budget goes to the picture.

3. 3. Resolution and frame rate

   The remaining bits are divided by the number of pixels per second. If that is too few for a clean picture, the tool steps down from 1080p to 720p or 480p, then from 60 to 30 fps. It never upscales.

4. 4. Measure and correct

   After encoding, the real file size is checked. If it is over your limit, the video bitrate is corrected and the video is encoded again, up to two more times.

Processing runs in a Web Worker in your browser. The file is read from disk in slices and the result is built in memory, then offered as a local download. The page makes no network request that contains your file, which you can confirm in your browser’s Network tab.

The target in megabytes is converted to a bit budget (size × 8 × 1,000,000 × 0.97, keeping 3 percent for the container). Audio is chosen first, the remaining bits are divided by the duration to get a video bitrate, and the encoder is run. The real file is measured, and if it is over the limit the bitrate is corrected by target ÷ actual × 0.97 and the video is encoded again, at most twice more.

The tool computes bits per pixel (video bitrate ÷ width ÷ height ÷ frame rate). Below about 0.05 it steps the resolution down from 1080p to 720p to 480p, then 60 to 30 fps. It never upscales, and it never spends more bits than the source file has.

Reading and writing go through Mediabunny. Decoding uses the browser’s WebCodecs VideoDecoder, so support depends on your browser: H.264 and most others work in Chrome, HEVC depends on your system. The output is always MP4 with H.264 video and AAC audio, written with the index (moov) at the front so playback starts quickly.

The input is read lazily, so a large input does not fill memory. The output is assembled in memory, which is the practical limit. A 911 MB, 10 minute 1080p60 input compressed to a 100 MB target in about a minute in testing, using under about 900 MB of browser memory.

If the source audio is AAC and takes no more than 15 percent of the budget, it is copied without re-encoding. Otherwise it is encoded as AAC at 96 kbps stereo, or 64 kbps mono when 96 kbps would exceed 15 percent. Browsers without a native AAC encoder load a small WebAssembly encoder.

The tool searches for the highest JPEG or WebP quality that stays under the target using a binary search on quality, and only if the lowest quality is still too big does it reduce the dimensions step by step. Images already under the limit are returned unchanged, except HEIC, which is always converted.

The images are compressed one after another by the same worker, so the HEIC decoder loads only once. Each result is checked against the target, and the zip is built in your browser with the fflate library using no extra compression, because the images are already compressed. Up to 200 images are taken per batch.