CRF is the single most useful encoding setting most people have never touched, and the one where the advice online is most contradictory. Here is what it is, what the numbers mean, and how to choose one.
What CRF is
CRF stands for Constant Rate Factor, and it inverts the usual question. Instead of telling the encoder how many bits per second it may spend and letting the quality vary, you tell it what quality to hold and let the size vary.
The encoder then does something genuinely clever: it spends bits where they are needed and saves them where they are not. A static shot of a wall gets almost nothing; a fast pan through foliage gets a great deal. The perceived quality stays roughly constant across the whole timeline, which is the thing viewers actually notice, and the file size is whatever falls out at the end.
The consequence is that a CRF encode of a ten-minute talking head might be 80 MB while a CRF encode of a ten-minute action sequence at the same setting is 900 MB. That is the mode working correctly, not a fault.
The x264 scale
In libx264 — the encoder behind most H.264 video, and the default one behind this site’s compressor — CRF runs from 0 to 51. Lower is better quality and larger files. The useful range is much narrower than the scale suggests:
- 0 — lossless. Enormous files, no practical use outside archiving.
- 17–18 — visually lossless for most viewers on most content. If you cannot tell the difference in an A/B test, this is where that stops.
- 20–23 — the sweet spot for delivery. 23 is libx264’s default and it is a well-chosen one.
- 24–28 — visibly compressed on close inspection, entirely acceptable for web video and for screen recordings with no small text in them.
- 29+ — obviously degraded. Reserve for cases where small is more important than good.
The rule of thumb worth memorising: a change of roughly 6 in CRF halves or doubles the bitrate. Going from CRF 23 to CRF 29 produces a file around half the size. Going from 23 to 17 roughly doubles it. That single relationship turns CRF from a mystery dial into something you can reason about.
The x265 scale is not the same scale
This is the most common mistake in the entire topic. x265 also uses a 0–51 range, and its default is 28 rather than 23 — but the numbers do not correspond. A given CRF in x265 produces a different quality level from the same number in x264.
As a working approximation, x265 CRF 28 is roughly comparable to x264 CRF 23. If you are moving a workflow from H.264 to H.265 and you keep your CRF value, you will get a noticeably different result from the one you expected, in a direction that surprises people.
Do not port CRF numbers between codecs. Re-establish them by looking at output.
Both encoders are present in the browser build here, so the mistake is available to you locally as well as on the command line. The tool does not expose CRF directly — it works in bitrate targets — but the same non-correspondence applies to any number you carry across, and to any expectation you carry across about how long the encode will take. x265 in WebAssembly is several times slower than x264 on the same footage.
How to choose a value
Encode a sample, look at it, adjust. There is no substitute, because the right value depends on content, on the resolution, and on how the video will be watched.
The efficient version of that loop: take the hardest thirty seconds of your source — the busiest motion, the most detail — and encode it at CRF 23. If it looks fine, try 26 and see whether it still does. Whichever value is the last one that looks acceptable on the hardest section is your value for the whole file, because everything else is easier.
Two adjustments worth knowing:
- Content type matters more than anything else. Screen recordings, slide decks and talking heads survive high CRF values that would wreck sports footage. A slide deck at CRF 28 often looks perfect; a football match at CRF 28 does not. The exception is small text — a code editor at 1080p wants 20 to 23 before the letterforms stop smearing.
- Small output means you can go higher. If the video will be played at 640 pixels wide, artefacts that would be obvious full-screen are invisible. Downscale first, then set CRF — in that order.
Preset changes what a CRF value costs
Presets — ultrafast through veryslow — do not change the target quality. They change how much computation the encoder spends looking for efficient ways to reach it. A slower preset at the same CRF produces a smaller file at the same quality; a faster one produces a larger file at the same quality.
This matters here specifically. A browser-based encoder has to use fast presets to remain usable, so a file produced in a browser tab will be larger than the same CRF from HandBrake on slow. Same quality target, different amount of thinking. That is the honest trade-off of encoding in a browser, covered in more detail in the comparison with HandBrake.
When CRF is the wrong tool
CRF’s defining property is that you do not know the output size in advance. When something will reject your file above a specific number of megabytes, that property is fatal.
For a hard limit, you want bitrate targeting: work out the bits available from the size and duration, and encode to that. The size-target pages do this arithmetic for you and then verify the result, and the file size calculator does it if you would rather run the encode yourself.
The clean division:
- A hard limit — Discord, an email attachment, an upload form — use a bitrate target.
- A preference — “smaller, but still good” — use CRF.
Trying to hit an exact file size with CRF means guessing, encoding, measuring and guessing again. Trying to get consistent quality with a bitrate target means over-spending on easy scenes and starving the hard ones. Each tool is bad at the other’s job.
Related reading
- What is video bitrate? — the quantity CRF is indirectly controlling.
- H.264 vs H.265: the real file size difference — why the scales differ and what you gain.
- Reduce video size without losing quality — settings by content type.
- FFmpeg versus this compressor — the exact commands, including the CRF ones.