HandBrake's RF slider is documented as a Constant Rate Factor. That single fact answers what most people are really asking when they ask about RF versus CRF: the two abbreviations name one HandBrake setting, not two competing ones.
What HandBrake's documentation does not do is publish a conversion to any command line. It documents its own slider, its own recommended ranges, and the conditions under which those numbers stop meaning anything — and that last part is the half worth reading. For how a command-line encoder defines its own flag, check the official documentation for that tool. Everything below is HandBrake's own.
The sentence that settles it
From HandBrake's Adjust Quality page, under "Differences between encoder quality scales":
"Most of HandBrake's official Presets use the x264, x265, or SVT-AV1 video encoders with a Constant Rate Factor, sometimes abbreviated CRF or simply RF."
RF is CRF. HandBrake calls it RF in the interface; the encoder calls it a Constant Rate Factor. One parameter, two labels.
The same section gives the direction of the scale for those three encoders: "a lower RF number produces higher quality video, and a higher RF number produces lower quality video."
And then the line that actually matters for anyone moving settings between tools:
"each encoder's quality scale corresponds only to its own internal rate control method"
Read that carefully. The scale is a property of the encoder, not of HandBrake — which is why everything below is about choosing a number for one encoder, not converting between them.
There is one place where HandBrake's documentation does name FFmpeg. Its source-formats page says HandBrake "uses FFmpeg libavformat and libavcodec libraries under the hood and generally can open whatever FFmpeg will, in addition to disc-based formats like DVD and Blu-ray." That statement is about opening files. HandBrake's documentation says nothing about mapping its quality slider onto a command line.
Which number to type
HandBrake publishes recommended RF ranges, and they are resolution-dependent. Quoting the Adjust Quality page verbatim — these apply to the x264 and x265 encoders only:
| Source | Recommended RF (x264 / x265) |
|---|---|
| 480p/576p Standard Definition | RF 18-22 |
| 720p High Definition | RF 19-23 |
| 1080p Full High Definition | RF 20-24 |
| 2160p 4K Ultra High Definition | RF 22-28 |
HandBrake lists a separate set for SVT-AV1: RF 22-32 for SD, RF 25-35 for 720p, RF 25-35 for 1080p, and RF 25-40 for 2160p 4K. Do not merge the two tables — they are not interchangeable. A 1080p target sits at RF 20-24 for x264 or x265 but RF 25-35 for SVT-AV1, even though the resolution never changed.
For anything else, HandBrake declines to give numbers at all: "For other encoders, start with a value in the middle of the scale, and adjust in small increments as desired."
Higher resolutions tolerating higher RF numbers looks backwards until you read HandBrake's reasoning: "When encoding higher resolution content, you have more information to work with. Therefore, you can get away with using lower quality values than you can with lower resolution content, as any loss is a smaller percent of the whole, and ultimately less perceptible."
One adjustment the same page endorses on top of the table: "Raising quality by a few steps may produce better results when encoding animated Sources (anime, cartoons)."
HandBrake's older page comparing constant quality with average bitrate adds two mechanics, described there rather than in the current recommendations. An RF of 0 applies no compression at all — it is lossless, and HandBrake's own answer to whether you should use it is no, because you end up with a file far larger than the source that does not look any better. That page also notes the slider is not linear for x264 but logarithmic, so small movements in the number produce large changes in the output. It still discusses DVD-era presets, so read it for the mechanism and take the numbers from the table above. Either way the practical advice on the Video tab is the same: "Begin by making small adjustments; plus or minus a few steps is usually noticeable."
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
That runs in this page — FFmpeg compiled to WebAssembly, re-encoding the file locally with nothing uploaded. It is the right call when you want a constant-quality re-encode once and would rather not install either program. If you want the knobs exposed instead of a preset, the video compressor has them, and the rest of the browser-side tools are at all Clapr tools.
Where the number stops carrying over
The number does not survive an encoder change. HandBrake is blunt about this: "You should not expect an x264 encode at RF 25 to be similar to an x265 encode at RF 25 or an SVT-AV1 encode at RF 25, as each encoder's quality scale corresponds only to its own internal rate control method." Switching encoders means re-choosing the value from scratch.
Some encoders run the scale backwards. HandBrake names the exception: "This is reversed for other encoders, such as Apple VideoToolbox, where a higher number produces higher quality." Apple VideoToolbox is the only encoder HandBrake names there, so "lower is better" is a rule about x264, x265 and SVT-AV1 rather than a universal one. What stays constant is the interface behaviour, not the arithmetic: "adjusting HandBrake's quality control to the right always increases quality."
Speed settings are a separate axis, and HandBrake's documentation of them is incomplete. HandBrake says only that "Some encoders expose a preset and tune system. These can be adjusted from the Video Tab," and that changing the preset may require changing the quality slider for good results. Its own page for this is marked "This article is a draft and may contain incomplete or incorrect information," and it does not list the available tunes. So if your two outputs differ at identical RF, the speed preset on each side is the first suspect — and you will have to read the value off HandBrake's Video tab rather than look it up.
A HandBrake preset changes more than quality. Official presets cap resolution and frame rate: "When selecting one of these Presets, higher resolution video will be downscaled to a maximum resolution, and higher frame rates will be peak limited to a maximum frame rate." Only downward — a 480p30 source picked up by a 720p30 preset "will not be scaled or peak limited." So two encodes at the same RF can come out different sizes simply because one of them was also resized or frame-rate limited by its preset. The same trap catches people using the Social presets that replaced HandBrake's Discord presets as of HandBrake 1.6.0.
Troubleshooting
Your output is bigger than your input. HandBrake warns that "Using higher than recommended quality settings can lead to extremely large files that may not be compatible with your devices" — and for x264, x265 and SVT-AV1, "higher quality" means a lower RF. Grainy sources make this worse: HandBrake notes they need a higher bitrate to preserve that extra detail, and suggests the Denoise filter. More on that failure mode in when HandBrake's output is larger than the original.
The same RF gives you a different file size every time. That is constant quality working as designed. HandBrake's documentation puts it plainly: because it takes a different bitrate to reach a given quality level in any given part of any video, the output size is unpredictable and varies from source to source. If you need a specific file size, the constant-quality slider is the wrong tool — see compressing video for Discord with FFmpeg, which targets a size instead.
You are not sure constant quality is the right mode. HandBrake's answer is not hedged: "Always use constant quality unless you have a specific reason not to." Its reasoning is that constant quality avoids a two-pass encode and avoids spending bits on the less complex frames that do not need them, so the file comes out smaller without giving up quality. The trade is the unpredictable size above.
FAQ
Is HandBrake RF the same as CRF? Yes. HandBrake's documentation describes its quality control as "a Constant Rate Factor, sometimes abbreviated CRF or simply RF" for the x264, x265 and SVT-AV1 encoders. It is one parameter with two names.
What CRF value matches HandBrake RF 20? HandBrake's documentation does not publish a mapping to any command-line tool — check the official documentation of the tool you are moving to. What HandBrake does say is that the value is tied to one encoder's own rate control: RF 20 on x264 is not RF 20 on x265 or SVT-AV1.
Is lower RF always better quality? For x264, x265 and SVT-AV1, yes. HandBrake names an exception: with encoders such as Apple VideoToolbox, a higher number produces higher quality. In the HandBrake interface, moving the control right always increases quality regardless of encoder.
What RF should I use for 1080p? HandBrake recommends RF 20-24 for 1080p with x264 or x265, and RF 25-35 for 1080p with SVT-AV1. Those are two different tables for two different encoder families; do not average them.
Why is my HandBrake output smaller than I expected at the same RF? Probably resolution or frame rate, not quality. HandBrake's official presets downscale higher-resolution video and peak limit higher frame rates to the maximums named in the preset — and only downward, so a source already below those maximums is left alone.
All HandBrake behaviour cited from the official HandBrake documentation, checked 23 September 2026. More command breakdowns live in the FFmpeg guides hub.
