About Video Compressor
Video Compressor shrinks MP4, MOV and WebM files using H.264 at a quality you choose — typically cutting size by 50–80% for screen recordings and phone videos. The whole pipeline runs in your browser through ffmpeg.wasm, a WebAssembly port of FFmpeg, so the file is never uploaded. Pick a target quality (CRF), optionally cap the resolution, and the tool re-encodes locally. Processing speed depends entirely on your device's CPU — a five-minute clip takes roughly the same time on a laptop as it would in desktop FFmpeg.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Drop a video
MP4, MOV or WebM. The tool reads the duration, codec and dimensions and shows them before you start.
- 2
Pick quality and size
Choose a quality preset (CRF 18 looks visually lossless, 23 is YouTube-grade, 28 saves the most space) and an optional max height — 720p, 1080p or original.
- 3
Re-encode and download
ffmpeg.wasm runs the H.264 encode locally. A progress bar shows current frame; the output downloads as soon as encoding finishes.
Bitrate is the file size — everything else just sets it
A video's size is, to a first approximation, its bitrate multiplied by its duration. A 10-minute clip at 8 Mbps is roughly 600 MB no matter what you name it; halve the bitrate to 4 Mbps and you halve the file. Resolution, frame rate and the CRF quality knob don't shrink the file directly — they shrink it by letting the encoder hit your target quality at a lower bitrate. That's the mental model that makes compression predictable: you're really choosing a bitrate, and the other controls decide how much visible quality that bitrate buys.
This tool exposes CRF (Constant Rate Factor) rather than a raw bitrate target, which is the better default for most footage. CRF tells the encoder to spend whatever bitrate is needed to hold a constant perceptual quality — cheap on static talking-head shots, generous on fast motion — instead of wasting bits on simple scenes and starving complex ones. CRF 18 is visually lossless, 23 is the broadcast/YouTube sweet spot, and 28 is where most screen recordings still look fine at a fraction of the size. Each +6 on the CRF scale roughly halves the bitrate.
Resolution vs. bitrate: drop the right one
When a clip is still too big at a reasonable CRF, the instinct is to push CRF higher — but past about 30 you start seeing blocking and smeared motion. Often the smarter cut is resolution. A 4K screen recording downscaled to 1080p has a quarter of the pixels to encode, so it reaches the same crispness at roughly a quarter of the bitrate, and on any normal display nobody notices the difference. The rule of thumb: lower the resolution to the size it will actually be viewed at first, then tune CRF. A Slack clip or a docs embed almost never needs more than 720p.
The honest exception is detail-dense footage — text-heavy screencasts, fine UI, gameplay. There, downscaling smears the very thing you're trying to show, and you're better off keeping the resolution and accepting a higher bitrate. If the clip is mostly one section you care about, trim it first — cutting 8 minutes down to the relevant 90 seconds beats any quality setting for shrinking the output.
Why H.264 here, and what H.265/VP9/AV1 would buy you
This tool encodes H.264 (AVC) on purpose. Newer codecs are genuinely more efficient — H.265/HEVC and VP9 are about 30-50% smaller at the same quality, and AV1 is better still — but efficiency isn't the only axis. H.264 decodes everywhere (every browser, phone, TV, editor made in the last decade), encodes fastest, and is the safe default when you don't control where the file will be opened. The advanced codecs trade that universality for size, and they cost dramatically more CPU to encode — which matters a great deal in a browser.
| Codec | Size vs H.264 (same quality) | Decode support | Best for |
|---|---|---|---|
| H.264 / AVC | baseline | Universal | Anything you'll share or embed without knowing the player |
| H.265 / HEVC | ~30-50% smaller | Good but licence-gated (patchy in browsers) | Apple ecosystem, archival where players are known |
| VP9 | ~30-50% smaller | All modern browsers, no licence | YouTube-style web delivery |
| AV1 | ~50% smaller | Recent browsers/hardware only | Streaming at scale where encode time is amortised |
Smaller-codec percentages are typical, not guaranteed — gains depend heavily on content and encoder settings.
Why the in-browser encode is slow — and when to expect limits
Compression here runs on ffmpeg.wasm, a WebAssembly build of FFmpeg, which is the reason nothing uploads — and also the reason it's slower than the same job in desktop FFmpeg. Two things hold it back: it runs effectively single-threaded inside the WASM sandbox, and it can't reach your machine's hardware H.264 encoder (NVENC, Apple VideoToolbox, Intel QuickSync). Native FFmpeg using a GPU encoder can be 10-20x faster. So a 10-minute 1080p clip that a desktop tool finishes in seconds may take several minutes in the tab; on a phone, longer. If it's crawling, lower the resolution or pick a faster preset before blaming the file.
There's also a hard memory ceiling: ffmpeg.wasm tops out around 2 GB of working memory in most browsers, so inputs much above ~1.5 GB risk an out-of-memory failure — long 4K clips are the usual culprits. Trim them down first. None of this makes the tool the wrong choice; for clips that need to clear a platform size limit, the trade — wait a couple of minutes instead of uploading a private video to a stranger's server — is usually the right one.
Related guides
All guidesFrequently asked questions about Video Compressor
Why is the encode slow compared to desktop FFmpeg?
ffmpeg.wasm runs single-threaded inside a WebAssembly sandbox and can't use hardware H.264 encoders (NVENC, VideoToolbox, QuickSync). For a 10-minute 1080p clip expect several minutes on a modern laptop; on phones it's slower still. Lower the resolution or pick a faster preset if it's taking too long.
What's the maximum file size?
ffmpeg.wasm has a working memory limit of around 2 GB on most browsers. Files up to roughly 1.5 GB input typically work; beyond that you'll see out-of-memory errors. Long 4K clips are the most likely to hit this — trim them first with Video Trimmer.
Does it re-encode audio too?
By default audio is copied through unchanged when possible, preserving bitrate and quality. If the source audio is in a codec the output container doesn't support, it's transcoded to AAC at 128 kbps.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.