Why is my video bigger after compression? CRF, bitrate and what to do

Short answer: the file got bigger because CRF sets a quality target, not a size target. If the source is already heavily compressed (low bitrate) and you re-encode it at a CRF that asks for better quality than it has, the encoder spends more bytes to hold on to every detail, including the compression artifacts already in the picture. The fix is to cap the bitrate, or not to re-encode at all.

If you would rather drag a file in and get a smaller one, QuickVid Compress (an app I make for Mac) has presets by target size; the rest of this page is the do-it-yourself ffmpeg route.

What CRF does and does not control

Lower CRF means higher quality and a bigger file; higher CRF means lower quality and a smaller file (see CRF explained). What CRF never looks at is how large your input was. It asks "what quality should each frame reach?", not "how many bytes should this end up?".

A measured example

I generated a 10-second 1280×720 test clip with ffmpeg, encoded at 1.5 Mbps: 1.95 MB. Then I re-encoded it with different settings:

Even CRF 28 did not beat the source. The test clip is a synthetic fractal animation with a lot of fine detail, so real footage will give different numbers, but the pattern holds: the lower the source bitrate, the easier it is to make a file bigger with a low CRF.

Fix 1: cap the maximum bitrate

Keep CRF for quality, add a ceiling the encoder may not exceed:

ffmpeg -i in.mp4 -c:v libx264 -crf 23 -maxrate 1200k -bufsize 2400k -preset medium -c:a copy out.mp4

On the same test clip this produced 1.55 MB, smaller than the source. A -bufsize of about twice -maxrate is a common starting point.

Fix 2: two-pass, aim at a bitrate

For a predictable size, give the encoder a target bitrate and run two passes:

ffmpeg -y -i in.mp4 -c:v libx264 -b:v 1200k -pass 1 -an -f null /dev/null
ffmpeg -i in.mp4 -c:v libx264 -b:v 1200k -pass 2 -c:a copy out.mp4

The test clip came out at 1.55 MB. Bitrate is roughly target size divided by duration: 8 MB over 60 seconds is about 1090 kbps, leaving a little for audio.

Fix 3: do not re-encode

If the file is already small, or you only want a different container or a trimmed start and end, copy the streams. Size cannot grow and quality is not touched:

ffmpeg -i in.mp4 -c copy out.mp4

Check the source bitrate first:

ffprobe -v error -show_entries format=bit_rate -of default=nw=1:nk=1 in.mp4

The cost

A bitrate cap lowers quality. Measured against the source with PSNR (higher means closer to the original): CRF 18 scored about 46.7 dB, CRF 23 about 43.0 dB, and the 1200k-capped version about 35.8 dB. The smaller the file, the further from the original. PSNR is a crude yardstick; with real footage, judge by eye.

Two other common causes

• HEVC to H.264. At similar quality HEVC is usually much smaller than H.264. iPhones record HEVC by default, so converting to H.264 and using a low CRF often makes the file larger. Stay on HEVC (libx265, with -tag:v hvc1 for Apple devices) if you want small.
• Same resolution, new codec. To really shrink a file you often need to lower the resolution or frame rate too, for example -vf scale=-2:720.

FAQ

Does a higher CRF always make the file smaller? Yes for a given input: higher CRF, lower quality, smaller file, roughly half the size per +6 in H.264 as a rule of thumb. It only stops helping when the source was already compressed hard.

Will CRF 18 always make a smaller file than the original? No. CRF 18 asks for very high quality, and on a low-bitrate source the output is often bigger than the input.

My phone video got bigger after compressing. What now? Check its bitrate with ffprobe, then use Fix 1, or stay on HEVC instead of converting to H.264.