Compress a video file
Shrink MP4, MOV, MKV and WebM files with H.264 CRF encoding, an estimated output size and real before/after numbers. No upload, no watermark.
- Runs in your browser
- Files are never uploaded
- Free, no account
First use downloads the 10 MB video engine from this site. After that it is cached and works offline. It is WebAssembly served from onthisdevice.com — no third-party CDN — and your file is still processed entirely on your own device.
How to compress a video
- Drop the video in. The tool reads its length and resolution straight away.
- Pick a quality target. Balanced (CRF 24) typically removes 60-80% of a phone recording's size with no visible difference.
- If the file still needs to be smaller, drop the resolution — that saves far more than pushing CRF higher.
- Check the estimated output size, then press Compress video.
- Compare the before and after figures, preview the result, and download it.
CRF: the setting that actually matters
H.264's constant rate factor sets a quality target and lets the bitrate move around to hit it. The scale runs from 0 (lossless, enormous) to 51 (unwatchable). Every increase of about 6 halves the bitrate; every decrease of 6 doubles it.
| CRF | Typical 1080p30 bitrate | Per minute | Quality |
|---|---|---|---|
| 18 | ~8 Mbps | 60 MB | Visually lossless; archival |
| 20 | ~6 Mbps | 45 MB | Barely distinguishable from the source |
| 24 | ~3 Mbps | 22 MB | Recommended — good on any screen |
| 28 | ~1.7 Mbps | 13 MB | Fine for messaging; soft in fast motion |
| 32 | ~0.9 Mbps | 7 MB | Visible blocking; last resort for hard limits |
Those bitrates assume ordinary handheld motion. A locked-off talking head can land at half of them; drone footage over trees can double them. That is exactly why the estimate on the tool is labelled an estimate.
Hitting a specific size limit
Common ceilings: 25 MB for a Gmail attachment, 8 MB on many chat platforms, 512 MB for a Discord upload without Nitro. Work backwards from the limit:
- Total bitrate (kbps) = target size (MB) × 8192 ÷ duration (seconds).
- Subtract the audio bitrate (128 kbps unless you changed it) to get the video budget.
- Match that budget to the table above; if it demands a CRF above 30, halve the resolution instead and try again at CRF 24.
Example: a 3-minute clip for a 25 MB inbox limit gives 25 × 8192 ÷ 180 ≈ 1138 kbps total, so about 1000 kbps of video. At 1080p that would look poor; at 720p it is entirely reasonable.
What the speed preset changes
The x264 preset controls how hard the encoder searches for redundancy. Slower presets produce
a smaller file at the same CRF — the quality target does not change, the efficiency does.
Going from veryfast to medium saves roughly 15% of the size and
costs roughly three times the encoding time. In a browser, where encoding is single-threaded,
veryfast is usually the right compromise.
Things that will not help
- Compressing an already-compressed file again. Each pass discards detail permanently; two passes at CRF 28 look worse than one pass at CRF 24 and are barely smaller.
- Changing the container. Renaming an MP4 to MKV moves the same streams into a different box; the size is unchanged.
- Raising the audio bitrate. Audio is usually under 5% of a video file.
Questions
How much smaller will my file get?
It depends entirely on the source. A phone recording at a high bitrate often drops 60-80% at CRF 24 with no visible difference; a file that is already well compressed may barely shrink. The tool shows an estimate before you start and the real numbers afterwards.
Should I lower the resolution or raise the CRF?
Resolution wins. Going from 1080p to 720p removes 56% of the pixels, which usually saves more than several CRF steps and looks better than a heavily quantised 1080p file on a phone screen.
Why is the estimated size not exact?
CRF encoding is variable-bitrate by design: a static talking head needs a fraction of the bits a handheld action shot needs. The estimate assumes typical motion at 30 fps, so treat it as a ballpark rather than a promise.
Does compressing twice make things worse?
Yes. Every lossy re-encode discards detail permanently. Always compress from the original file rather than from an already-compressed copy.