Re-encode a video smaller with H.264 CRF, a speed preset that really reaches the encoder, and a downscale that keeps the shape. Measures a sample to predict the size, then shows what the file actually came out as.
Initializing in your browser…
Cut a clip out of a video, choosing whether the cut lands on the exact frame (re-encodes to MP4) or leaves the streams untouched (instant and lossless, but only at a keyframe). The result says which ran and reads the real length back off the file.
Convert a video between MP4, WebM, OGG, MOV, AVI and MKV, each naming the codecs it really writes and each producing a file that actually plays. One quality dial normalised into four different encoder scales.
Join clips end to end, saying in advance whether they can be stitched together untouched and, when they cannot, exactly which differences stop it. Clips of different sizes are letterboxed into one frame rather than squashed.
A 1.36 MB 640x480 clip needs to be smaller, and you want to know by how much before running it.
Input
detail.mp4 1.36 MB · CRF 28 · speed Fast · keep audio
Output
Sample predicts 596 KB; the real output is 560 KB, 60 percent smaller
The prediction comes from encoding two seconds of the file at those exact settings and scaling the measured bitrate, not from a table, because CRF fixes the quality and lets the size fall where the pictures put it. The same clip at the Fastest speed preset comes out 1.03 MB, roughly twice as large for the same quality target, which is why the speed control is labelled with its size cost.
CRF is a quality target, not a size target, and that one sentence explains most of the surprises people hit with a video compressor. The encoder is told how good the picture has to look and then spends whatever bitrate that takes: a static screen recording spends very little, a handheld shot of leaves in wind spends a lot. So the output size is a property of the pictures, not of the input file, and no table of "CRF 28 gives you 19 percent of the original" can be right for both. This tool therefore does not guess. Press Measure a sample and it encodes two seconds of your actual video at your exact settings, measures the bitrate that came out, and scales it up; the page prints the one assumption that makes, which is that the rest of the video is about as detailed as the part sampled. The consequence worth knowing in advance is that re-encoding can make a file BIGGER. If a clip was already written at CRF 18 and you ask for CRF 23, you get a smaller file; ask for CRF 18 again and you get a slightly larger one, because the second encode has to spend bits describing the first encode's artefacts as though they were detail. When that happens this tool says so in plain words rather than reporting a saving that did not occur. H.264 is the only video codec here, deliberately. It is the format every phone, browser and television made in the last decade decodes in hardware, and the output is always MP4, because muxing H.264 into whatever extension the input happened to have is how you get a file named .webm that half the world cannot open.
Measure a sample first, raise the CRF or drop the frame size until the prediction is under the limit, then run it once instead of guessing and re-exporting.
Cap the frame size at 720p and use CRF 28. The output is MP4 with H.264, which every platform accepts.
Screen captures compress extremely well because most of the frame does not move. A sample measurement will usually predict a much bigger saving here than on camera footage.
Shrink large camera recordings. Check the result panel: if the file grew, the original was already more compressed than the setting you chose.
MP4 with +faststart is written on every output, so the file begins playing before it has finished downloading.
Two settings decide almost everything. The CRF slider runs 16 to 34 on H.264's own 0 to 51 scale, where lower is better and about six points doubles or halves the bitrate; 18 is usually indistinguishable from the source and 28 is fine for social and messaging. The Encoding speed control picks the libx264 preset, and unlike a lot of "speed" controls it changes the file rather than only the wait. Measured with ffmpeg on a detailed 640x480 test clip at CRF 28: ultrafast produced 1,012,875 bytes, superfast 766,383, veryfast 502,243, medium 500,909 and slow 490,783. So the fastest setting is not a small compromise, it is twice the file for the same quality target, and the difference between Fast and Smallest is about two percent. Fast is the default because it captures nearly all of the compression for a fraction of the time.
Frame size is the other big lever, and it is applied as a cap rather than as a stretch. Choosing 720p on a 4:3 source gives a 4:3 output, not a letterboxed or squashed 1280x720 one, and choosing a size LARGER than the source does nothing at all: enlarging a video adds no detail and makes the file bigger, so the page says it left the frame alone and why. Every output width and height is even, because H.264 with 4:2:0 chroma cannot store an odd one, and where that rounding moves your number the page says so.
Audio is copied through untouched by default. An MP4 can hold AAC, MP3, AC-3 and ALAC, so a source with any of those keeps its exact original audio bytes: lossless, instant, and usually smaller than a re-encode. A source with Opus or Vorbis audio cannot be copied into MP4, so it is re-encoded to AAC and the page names the reason. You can also force a re-encode at 96 to 256 kbps, or drop the audio entirely.
Nothing is downloaded automatically. When the run finishes the page shows the real output size, the real change as a percentage, how long it took, how far the sample prediction was from the truth, a player for the result, and the exact ffmpeg command line that produced it. Everything happens in your browser through ffmpeg compiled to WebAssembly; no file is uploaded anywhere.
Nobody can tell you before measuring, which is why this tool measures. CRF sets a quality, and how many bits that quality costs depends on the pictures. Press Measure a sample: it encodes two seconds of your video at your exact settings and scales the result. Loosely encoded camera and screen footage often drops to a fifth of its size; a file that is already tightly compressed may barely move.
Because it was already encoded at a higher quality than the setting you asked for. A second encode has to describe the first encode's compression artefacts as though they were real detail, which costs bits. The result panel says so plainly when it happens. Raise the CRF number, cap the frame size, or keep the original.
It changes the file. At the same CRF, ultrafast produced twice the bytes of veryfast on the test clip, and slow produced about two percent fewer than veryfast. Speed presets trade encoder effort for size, not for picture quality: the quality target is the CRF, and a faster preset simply spends more bits reaching it.
Only when it has to be. AAC, MP3, AC-3 and ALAC tracks are copied into the MP4 byte for byte, so they are lossless and instant. Opus and Vorbis cannot live in an MP4, so those are re-encoded to AAC and the page tells you that is what happened. You can also force a re-encode or remove the audio.
Because the video inside it is always H.264, and the container has to match the contents. Writing H.264 into a file named .webm produces something most players refuse. If you need a different container, use the Video Format Converter.
Because your source is 4:3, and 1280 by 720 is 16:9. Forcing it would stretch the picture by a third. The frame size setting is a cap on the height; the width follows the shape of your video, and both are rounded to even numbers because H.264 with 4:2:0 chroma cannot store an odd one.
Video is decoded and re-encoded on your own device. Large files never leave your machine.