Same -crf 23, so why does one video come out at 200 MB and another at 100? Why do forums everywhere call CRF 23 the "default quality" when your export at 23 looks mushy? This article starts from x264's rate-control model, explains CRF all the way through, and ends with a cheat sheet you can copy as-is.
CRF Is Not a Bitrate — It's a Quality Target
There are two fundamentally different approaches to encoding video with FFmpeg:
Constant bitrate (CBR): every second gets the same number of bits, whether the frame is a static black screen or a fast-moving explosion. Static scenes waste bits; motion scenes don't get enough and turn into blocky mush.
CRF (Constant Rate Factor): the reverse — you set a quality target, and the encoder allocates bits based on how complex each scene is. Simple scenes get fewer bits, complex scenes get more. The result: constant quality, variable file size.
# CRF mode: specify quality, not bitrate
ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4
# For comparison: CBR mode (shown for contrast — generally not recommended)
ffmpeg -i input.mp4 -c:v libx264 -b:v 2M output.mp4
This is why the same -crf 23 produces files several times larger for live-action sports footage than for animation — CRF's output size depends on the content. That's a feature, not a bug.
The Number Range: Lower Is Sharper, Higher Is Smaller
x264's CRF runs from 0 to 51, where 0 is lossless and 51 is nearly unwatchable. Every +6 roughly halves the bitrate; every −6 roughly doubles it:
| CRF | Perceived quality | Typical use |
|---|---|---|
| 0 | Lossless | Intermediate processing, archiving masters |
| 16–18 | Visually lossless (differences only on close comparison) | High-quality archiving |
| 20–23 | High quality, the default range | Everyday transcoding, publishing |
| 24–27 | Slightly noticeable loss, clearly smaller files | Cloud backup, casual sharing |
| 28–35 | Visible compression artifacts | Draft previews |
| 36+ | Mushy | Rarely a reasonable choice |
x264's default is 23 — when you specify nothing, FFmpeg uses -crf 23.
Don't Copy x264 Numbers to x265
x265 (HEVC) also uses a 0–51 CRF range, but the scale is completely different — x265's 28 roughly matches x264's 23. Copying your x264 habits to x265 gives you a much smaller file with noticeably worse quality:
# To match the look of x264 -crf 23, use roughly -crf 28 with x265
ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4
The same applies in reverse: moving from x265 back to x264, remember to drop the value by about 5.
Cheat Sheet by Scenario
If you'd rather skip the theory, just copy these (x264 values):
| Scenario | Recommended CRF | Notes |
|---|---|---|
| Phone/camera footage, re-encode for storage | 18–20 | Preserves detail at manageable sizes |
| YouTube / Instagram upload | 18–21 | Platforms re-encode on their side — upload the cleanest file you can |
| Email or messaging | 23–26 | Size first, as long as it's watchable |
| Rescuing old footage for the archive | 16–18 | Invest once, benefit long-term |
| Screen recordings and tutorials | 16–20 | Text is extremely sensitive to compression loss |
One special note on screen recordings: large areas of black text on white are "high-frequency detail" to x264, and compression loss shows up first as blurry text edges. Better to lower the CRF when recording than to try to fix it afterward.
CRF and Preset Are Two Different Things
People often conflate these. CRF decides "how much quality"; preset decides "how much time you'll spend to reach that quality at a smaller size":
ultrafast→medium→veryslow: encoding gets slower, files get smaller at the same quality- Preset doesn't change the quality baseline — only the compression efficiency
# A good speed/size balance for most cases
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset fast output.mp4
# No hurry, chasing minimum size (e.g., archiving)
ffmpeg -i input.mp4 -c:v libx264 -crf 20 -preset veryslow output.mp4
Practical tip: find the CRF you like with -preset fast, then switch to a slower preset for the final export — the two knobs are independent.
Common Misconceptions
"CRF 23 means 23 Mbps" — No. There's no direct conversion between CRF and bitrate; the output bitrate is determined entirely by content complexity.
"Lower CRF is always better" — No. Past CRF 18 you can't see the difference; going lower just wastes file size, and high-bitrate files can even stutter during playback.
"I'll just re-compress until I like it" — Stacking lossy encodes on top of lossy encodes accumulates damage. Encode once from the original source when possible, and re-evaluate CRF for any second pass.
"I changed the CRF but the file size didn't change" — Check whether you forgot -c:v libx264 (or a preset silently selected a different encoder). Different encoders attach completely different meanings to CRF.
Try It Yourself
The final judge of any setting is your own eyes and your target file size. Open the Video Compressor and compare a few CRF values right in your browser; if you want full control over every parameter including preset, run complete commands in the FFmpeg Command Lab — both run locally, with no queue and no uploads.
FAQ
Q: My CRF encode came out larger than the source. What now? A: That means the source's bitrate is already below what your CRF target requires (typical for casual phone footage). Re-encoding won't make it smaller, only worse — the right move is to raise the CRF or reduce the resolution.
Q: What's the difference between -crf and -qp?
A: -qp is a fixed quantization parameter that ignores picture content entirely; CRF adapts it based on a model of human perception. Unless you're doing frame-by-frame debugging, always use CRF.
Q: Can I use CRF on GIFs? A: No. CRF belongs to video codecs like H.264/H.265. GIF is a completely different encoding system with different compression levers (color reduction, frame dropping, lossless optimization).