100% client-side — files never leave your device

How to Compress a Video in Your Browser

A three-minute phone clip is 400 MB and the form you need to attach it to allows 25. The usual response is to drag a quality slider until it fits, which works but throws away more than necessary. Four separate things determine the size of a video file, and they are not equally worth cutting.

The four dials

Resolution is the biggest and the least painful. Modern phones record 4K by default. If the clip will be watched in a browser window or on a phone, 1080p is plenty and 720p is often fine — and dropping 4K to 1080p removes three quarters of the pixels. Start here.

Bitrate is how many bits per second the encoder may spend, and it is the dial that most directly trades quality for size. Too low and you get blocking in motion and mush in detail. Roughly: 8 Mbps is comfortable for 1080p, 4–5 Mbps is acceptable, 2 Mbps looks like a video call. Fast-moving footage needs more than a static talking head at the same resolution, which is why one number cannot cover every clip.

Frame rate is worth cutting only sometimes. 60 fps to 30 fps saves meaningfully and is unnoticeable for a screen recording or an interview. On sport or fast panning it is very noticeable. Do not go below 24 for anything with motion.

Codec changes the efficiency of everything above. H.264 is the compatibility floor — everything plays it. VP9 and H.265 achieve similar quality at appreciably smaller sizes, with narrower support and slower encoding. AV1 is better again and slower again. For a file someone else must open, H.264 remains the safe answer; for the web, VP9 in WebM is a good trade, which is what MP4 to WebM is for.

What in-browser encoding can and cannot do

The video compressor here runs FFmpeg compiled to WebAssembly. It is genuinely the same encoder, and it never sends your footage anywhere — which for family video, medical recordings or unreleased material is the entire point. Be realistic about the limits, though:

  • It is slower than native FFmpeg. WebAssembly gives up some performance, and hardware video encoders are not available to it. Expect a multiple of the time a desktop install would take.
  • Memory is the real ceiling. A tab has far less headroom than your machine. A short clip is comfortable; a two-hour 4K recording will not be. Trim first — encoding only the thirty seconds you need is faster than any compression setting.
  • The progress bar tracks real work. Encoding is CPU work happening on your own processor, so a long clip takes as long as it takes. Plug the laptop in.

For a very large file, a desktop FFmpeg install is the right tool and there is no reason to pretend otherwise. For everything up to a few hundred megabytes, doing it in the tab means no upload, no queue and no copy of your footage on someone else's disk.

A sensible order

  1. Trim to the part you actually need. Nothing else saves as much.
  2. Drop resolution to the largest size it will really be viewed at.
  3. Halve the frame rate if the content is static.
  4. Then lower the bitrate, and only until quality starts to visibly suffer — check a high-motion moment, not a still frame.
  5. Switch codec last, and only if the recipient can definitely play it.

When you do not need video at all

Two common cases where the answer is a different format entirely. If it is a short silent loop for a page or a chat, a GIF may be what people expect — though be warned that GIF is a poor compressor and a long clip becomes larger, not smaller. And if only the words matter, extract the audio track and send a few megabytes instead of a few hundred.

More from the blog