CRF Explained: Compress Video Without Losing Quality
If you have ever opened HandBrake, or typed an FFmpeg command from a forum, you have met CRF. There is a slider, or a number after -crf, and everybody online has an opinion about it. “Use 18.” “Use 23.” “Use 20 for anime.” “Anything over 28 is garbage.”
I wanted to know what those numbers actually do, so I encoded a 5 second 1080p clip at six CRF values and measured file size and quality for each one. This article gives you the results, explains what CRF is doing under the hood, and tells you which value to choose for the job in front of you.
What CRF is
CRF means constant rate factor. It is the quality mode of the x264 and x265 encoders (and the same idea exists in VP9 and AV1 with their own scales). Instead of telling the encoder “use 8 megabits per second”, you tell it “give me this level of quality”, and the encoder decides how many bits each frame needs to reach it.
That is a big difference. A static shot of a wall needs very few bits to look good, so the encoder spends little. A shot of rippling water needs many, so it spends more. The file size comes out as whatever it takes. The bitrate rises and falls with the content, while the perceived quality stays about the same.
A fixed bitrate does the opposite. The bits per second stay constant, and quality rises and falls. Easy scenes look wonderful and hard scenes fall apart. That is why CRF is the better choice for most files you keep or upload, and a fixed bitrate is for situations with a hard size or bandwidth limit.
The number is on an arbitrary scale. For x264, it runs from 0 (lossless) to 51 (awful). Lower is better. The default is 23, and the sensible range is roughly 17 to 28.
The experiment
I took a 5 second 1080p clip from an open-source animated film. It has fur, foliage and fast camera moves, so it is demanding. I encoded it with x264 using the medium preset at CRF 18, 21, 24, 27, 30 and 33. Then I compared each result to the source frame by frame using PSNR (a measure of how close the pixels are, in decibels) and SSIM (a structural similarity score from 0 to 1).
Here is what I got:
| CRF | File size | PSNR | SSIM |
|---|---|---|---|
| 18 | 7.2 MB | 44.8 dB | 0.989 |
| 21 | 4.8 MB | 42.9 dB | 0.985 |
| 24 | 3.4 MB | 40.8 dB | 0.977 |
| 27 | 2.4 MB | 38.5 dB | 0.962 |
| 30 | 1.6 MB | 36.2 dB | 0.939 |
| 33 | 1.1 MB | 34.2 dB | 0.906 |
A few patterns stand out.
Each step of three CRF points cuts the file by about 30 percent. From CRF 18 to 21, 7.2 to 4.8 MB. From 21 to 24, 4.8 to 3.4. From 24 to 27, 3.4 to 2.4. The rule of thumb that “+6 CRF halves the file size” holds up well: CRF 18 at 7.2 MB and CRF 24 at 3.4 MB is a little more than half.
Quality falls at a steady 2 dB per three points at first, then faster. PSNR drops 1.9, 2.1, 2.3, 2.3 and 2.0 dB across the steps. SSIM tells a more dramatic story. It changes by 0.004 from 18 to 21, by 0.008 from 21 to 24, but by 0.033 from 30 to 33. The curve bends downward at the end.
The sweet spot is somewhere in the middle. CRF 21 saved a third of the size over CRF 18 and lost only 0.004 in SSIM. CRF 24 saved more than half and still scored 0.977. By CRF 30 and 33 you are in clear damage territory.
PSNR and SSIM are not human eyes. A change of two dB does not always look like two dB. But these numbers match what people see in practice: little visible change in the high-quality range, and a quickly growing problem near the bottom.
What each value looks like in practice
Based on the numbers above and the usual experience of encoding a lot of footage, here is how I would describe the range:
- CRF 14 to 17: archival. Files are large, and you will not see the difference from the source on a normal screen. Use it for masters you will edit again.
- CRF 18 to 20: near transparent. This is my default for anything I keep. It is also the right range for video you plan to upload to a platform that will re-encode it.
- CRF 21 to 23: good for distribution. You may notice small losses in grass, noise or dark gradients if you look for them, but most viewers will not.
- CRF 24 to 27: noticeably compressed on a monitor, still acceptable on a phone. Fine for large archives of casual video.
- CRF 28 and above: visible blocks in anything busy. Use only if size is the only thing that matters.
Content changes the picture. Cartoons and screen recordings with large flat areas are easy: CRF 23 may look perfect. Grainy film, rain, confetti and fast action need lower values. When a video looks blocky at CRF 23, it is usually because the footage is hard, not because 23 is wrong.
CRF is not the whole story: presets
CRF decides the quality target. The preset (ultrafast to veryslow) decides how hard the encoder works to hit it. Slower presets find smarter ways to describe the same picture, so at the same quality they produce smaller files. Or, at the same file size, they give a better picture.
I ran the same clip at CRF 23 with five presets. Here is the surprise: the output is not equivalent. At CRF 23, veryfast produced a 2.5 MB file with a PSNR of 38.3 dB. medium produced 3.8 MB at 41.6 dB. slow made 3.8 MB at 41.7 dB, and veryslow was 3.4 MB at 41.7 dB. The ultrafast preset produced an enormous 19 MB file at 37.7 dB, because it skips many tools and wastes bits. On time, the same encode took about 1.0 seconds at ultrafast, 1.6 at veryfast, 4.4 at medium, 5.8 at slow and 14.5 at veryslow on my machine, so veryslow cost over three times as long as medium for a roughly ten percent smaller file.
That tells you two things. First, “CRF 23” on a fast preset is not the same quality as “CRF 23” on medium, so if you compare numbers with someone else, ask which preset. Second, the jump from veryfast to medium bought more than three dB for about 50 percent more data, while going from medium to veryslow bought almost nothing and saved about 10 percent. For most work, medium or slow is the sensible choice, and veryslow is rarely worth the wait.
CRF versus a fixed bitrate
If you need a file that fits within a size limit, such as 25 MB for email or 8 MB for a chat app, use a target bitrate. Work out the budget: size in megabits divided by duration in seconds, minus audio. Then use two-pass encoding so the encoder can plan where to spend bits. A 60 second clip with a 25 MB cap, minus audio at 128 kbps, gives you a video bitrate of about 3 Mbps.
If you do not have a size limit, use CRF. A file of unknown size with consistent quality is a better result than a file of exact size with inconsistent quality.
There is also a middle road called constrained CRF: you set a CRF and a maximum bitrate with -maxrate and -bufsize. The encoder aims for the quality you asked for but never exceeds the maximum. It is useful for streaming and for devices that cannot handle high peaks.
Commands you can copy
For a high-quality copy of a video:
ffmpeg -i input.mp4 -c:v libx264 -preset slow -crf 18 -c:a copy output.mp4
For a smaller file for sharing:
ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4
For HEVC at a similar quality to x264 CRF 23:
ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 -tag:v hvc1 -c:a aac -b:a 128k output.mp4
The hvc1 tag helps Apple devices recognize the file. More on this codec in my H.264 versus H.265 test.
And if you want to cap the peaks:
ffmpeg -i input.mp4 -c:v libx264 -crf 20 -maxrate 12M -bufsize 24M -c:a copy output.mp4
CRF in HandBrake
HandBrake calls it “Constant Quality” and shows it as RF. The slider is the same CRF number. The recommended values in its documentation are in the neighborhood of 18 to 22 for 1080p and a bit higher for lower resolutions. If your HandBrake output looks bad, the first thing to check is that you did not choose a “Fast” preset with a high RF, and that you did not choose “Average bitrate” with a tiny number. I have a guide for blocky HandBrake output.
Why a video can look worse at the same CRF
Sometimes a file at CRF 20 looks poor, and you wonder what happened. A few reasons:
- The source is already degraded. CRF preserves what it is given. If the input is blocky, the output is blocky, just at a different size.
- The footage is noisy. The encoder tries to keep the noise, burning bits. Denoise first and the same CRF gives a cleaner result, and a smaller file. In my noise test, the file at CRF 23 shrank from 9.4 MB to 5.4 MB after a denoise.
- The scaling is poor. If you resize with a bad filter, no CRF will rescue it.
- The wrong pixel format. 8-bit encodes with gradients can show banding at any CRF. Try 10-bit if your players support it.
A sensible default
If you want one setting to use on everything and stop thinking about it: x264, -preset slow, -crf 20, -pix_fmt yuv420p, AAC audio at 192 kbps, and -movflags +faststart for web playback. It will give you excellent quality at reasonable size on nearly any footage. Raise to 22 or 23 for big archives of casual video, and drop to 17 or 18 for masters.
Picking a value by content type
The numbers above came from one demanding clip. Your footage will be easier or harder, so here is how I would adjust.
Talking head, lecture, slides. These are easy. A static background and small motion mean the encoder needs few bits. CRF 23 to 26 usually looks clean, and the files are tiny. If there is text on screen, stay at the lower end of that range so the text edges stay crisp.
Screen recording. Large flat areas compress well, but sharp text and sudden window changes expose any weakness. I would use CRF 18 to 22, and a slower preset, because the cost in size is small. Also remember that chroma subsampling blurs colored text no matter what CRF you pick.
Gameplay. Fast motion and particle effects are hard. CRF 18 to 20 with a slow preset is a good start. If you record with OBS, the recording quality matters more than the CRF you later use for the upload.
Handheld camera footage and travel video. Medium difficulty. CRF 18 to 21.
Grainy low-light footage. Hard, and the grain eats the budget. Denoise first, then CRF 20 to 22. If you leave the grain in, you need CRF 16 to 18 to keep it from turning into blocks.
Animation and cartoons. Easy in flat regions, but gradients can band. CRF 18 to 22, and consider 10-bit.
Old, low-resolution footage. The source has little detail to keep. CRF 20 to 23 is fine, but if you plan to upscale it, encode after the upscale, not before, and use a CRF in the 17 to 20 range so that the new pixels are not crushed.
Doing the size math for a fixed target
Sometimes a limit is a limit. Suppose you must send a 4 minute video and the cap is 50 MB. Convert: 50 MB is 400 megabits. Four minutes is 240 seconds. So the total budget is about 1.67 Mbps. If audio takes 128 kbps, video gets about 1.5 Mbps. At 1080p that is thin, and you will see blocks in moving areas. At 720p, 1.5 Mbps is far more comfortable. So the fix is to reduce the resolution, not to push the bitrate down at 1080p.
For this job, I would use two-pass encoding. The first pass analyzes the video, the second spends the bits wisely:
ffmpeg -y -i in.mp4 -c:v libx264 -preset slow -b:v 1500k -pass 1 -an -f null /dev/null
ffmpeg -i in.mp4 -c:v libx264 -preset slow -b:v 1500k -pass 2 -c:a aac -b:a 128k out.mp4
On Windows, replace /dev/null with NUL. Two-pass costs you twice the time, and for a hard size cap it is worth it.
How to test your own CRF
You can run a smaller version of my experiment on your own footage in five minutes. Cut a 10 second section with the hardest content you have. Encode it at CRF 18, 22 and 26 with the preset you intend to use. Play the three files at full screen, one after another, in the same player. Find the largest CRF where you cannot see a difference from the lowest. That is your personal limit for that kind of footage, and you can reuse it.
If you want numbers as well as eyes, FFmpeg can compute them:
ffmpeg -i encoded.mp4 -i source.mp4 -lavfi "[0:v][1:v]ssim;[0:v][1:v]psnr" -f null -
It prints SSIM and PSNR at the end. Remember that both are rough proxies. Two files with the same score can look different, and a small drop in score in a place the eye notices, such as a face, matters more than a larger drop in a patch of grass.
Common myths
“CRF 0 is the best quality, so I should use it.” It is lossless, and it produces files many times larger than the source. There is no benefit unless you are archiving a lossless master.
“Lower CRF always looks better.” Up to a point. Below about 16 or 17, you cannot see an improvement and you are only spending storage.
“CRF 23 is always fine.” It is a default, and the right value depends on the footage. Busy scenes may show damage at 23.
“x265 CRF 28 is the same as x264 CRF 28.” It is not. The numbers are tuned differently.
“Two-pass is always better than CRF.” For quality per bit, two-pass at the same average bitrate and CRF are very close. Two-pass is for hitting a size, not for improving quality.
Summary
Treat CRF as a dial that trades size against quality, with a sensible zone between about 18 and 24 for most 1080p work. Choose the preset for how long you can wait, usually medium or slow, and remember that the same CRF at different presets does not give the same picture. When you must hit a size, use two-pass bitrate encoding and consider reducing the resolution rather than starving a big frame.
If a file looks blocky and you no longer have the original, you can try the free preview to see what cleanup can do for it.
Got a pixelated video right now?
Upload it and see a free before and after preview in about a minute.
Fix my videoFrequently asked questions
What does CRF mean in video encoding?
CRF stands for constant rate factor. It is a quality setting for x264 and x265: lower numbers mean higher quality and larger files, higher numbers mean smaller files with more compression.
What CRF should I use for x264?
CRF 18 is close to visually lossless for most footage, 20 to 23 is a good everyday range, and the default is 23. Above 28 the damage is usually visible.
Is CRF the same in x264 and x265?
No. The scales are similar but not equal. CRF 28 in x265 is roughly comparable to CRF 23 in x264, which is why their defaults differ.
Does CRF 0 mean lossless?
For 8-bit x264 it does, and the files are enormous. It is almost never what you want.
Should I use CRF or a fixed bitrate?
Use CRF when you care about consistent quality and do not have a strict size limit. Use a target bitrate with two passes when the file must fit a size cap or a streaming budget.
Keep reading
What Bitrate Do You Need for 1080p Video?
I encoded the same 1080p clip at six bitrates and measured the damage. Here is what each one costs you, and the number I would actually use.
H.264 vs H.265: I Measured the Quality Difference
x264 and x265 at CRF 20, 24 and 28 on the same 1080p clip: file size, PSNR, SSIM and encode time, plus when HEVC is actually worth using.
Why Is My Video Pixelated After Exporting?
The editor preview looked fine, the export did not. Here are the real causes, in the order I check them, and how to fix each one.
HandBrake Output Pixelated? Settings That Fix It
HandBrake video looks blocky or blurry after conversion? Check quality mode, preset, filters and framerate settings with real CRF numbers.