CRF is a quality dial, not a size dial
The most common disappointment with any video compressor is expecting it to produce a number of megabytes. This one cannot, and it is worth being upfront about why.
Every preset here drives x264 in constant-quality mode. You tell the encoder how good the picture has to look and it spends whatever bitrate that requires, frame by frame. A locked-off screen recording of a text editor will sail through at a tiny bitrate; the same duration of handheld footage of leaves moving in wind will not, because there is genuinely more information in it.
The four Compression target choices map to CRF 26, 28, 30 and 32. On x264βs scale, lower is better quality and larger, and moving six points is the rough rule of thumb for halving the bitrate. Combining the higher CRF values with a resolution cap is what makes the platform presets land where they usually need to.
What the resolution caps do to a portrait clip
Balanced keeps your original resolution. It only applies scale=trunc(iw/2)*2:trunc(ih/2)*2, which nudges each dimension down to the nearest even number because H.264 requires that, and can therefore shave a single row or column off an odd-sized frame.
The other three build a different filter, of the shape scale='min(iw,1280)':'min(ih,1280)':force_original_aspect_ratio=decrease:force_divisible_by=2, with 854 in place of 1280 for the Discord preset. That reads as fit the frame inside a square box of that size, shrink only, and round to even dimensions. On a 16:9 landscape clip a 1280 box produces 1280 by 720, which is why the option is labelled 720p. On a 9:16 vertical clip the same box produces 720 by 1280. The cap is on the longest side, not on the width.
Only .mp4 gets past the dropzone
This page accepts .mp4 and nothing else, and the check happens in the browser before any processing begins, so a MOV or a WEBM never reaches the encoder at all.
That is narrower than several neighbouring tools on purpose. If your file is a MOV, an M4V or a WEBM, the target-size compressor takes all four containers and always writes MP4 out, so it doubles as a converter. The same is true of the trimmer and the audio remover, both of which accept those four extensions and both of which do their job with a stream copy rather than a re-encode, meaning no quality is lost at all.
Sending a video through the encoder
- Drop your
.mp4on the box above, or click Choose a file. - Set the Compression target. Balanced preserves resolution; the other three are sized for a destination and will reduce it.
- Click Compress Video and leave the tab open. The progress bar reflects the FFmpeg run, and Cancel abandons it and empties the box.
- Compare the two sizes printed above the download button. If the result is still too large, click Process another and step down a preset.
Three flags every run passes, whatever preset you pick
Alongside the CRF value, every run passes the same three fixed settings, and they matter more than they look.
-pix_fmt yuv420p forces 4:2:0 chroma subsampling. Some phone and screen-capture sources arrive in formats that many hardware decoders and browsers refuse outright, and this is the setting that makes the output universally playable rather than something that works on your laptop and shows a black rectangle on someoneβs TV.
-movflags +faststart moves the MP4 index to the front of the file after encoding. Without it a browser has to download the whole file before it can start playing; with it, playback begins immediately. It costs one extra pass over the finished file and is worth it for anything that will be streamed rather than downloaded.
-preset fast is x264βs own speed setting, and it is unrelated to the dropdown on this page. It trades a little compression efficiency for encode time, which is a sensible default when the encoder is running single-threaded inside a browser tab.
This page can hand you a bigger file
The GIF, MP3 and PDF compressors on this site compare their output against the input and return your original bytes when the encode did not help, and the image compressor does the same on any file it did not downscale. This one does none of that. Whatever x264 writes is what you get.
That matters most on already-compressed footage. A clip downloaded from a social platform has usually been through a hard encode already, and asking for CRF 26 at full resolution can genuinely produce a larger file than the one you started with. The interface will tell you, since it prints the percentage change, but you have to look at it. Three things help more than reaching for a harsher CRF. Drop the audio track first if the clip is silent anyway, which the audio remover linked above does without re-encoding the picture. Cut the clip shorter, since duration is the one variable that scales the output linearly. Or hand the problem to the target-size page, which reads the duration and works backwards from an explicit ceiling instead of guessing. The video tools index has the rest, and there is a longer explanation of what re-encoding costs in the guide on why video re-encoding loses quality.