What is CRF in video compression? A practical guide for non-engineers

If you've ever tried to compress a video and seen the term CRF thrown around — in ffmpeg flags, HandBrake settings, or QuickVid's "Custom" mode — you've probably searched for what it means and gotten one of two unhelpful answers:

1. "CRF stands for Constant Rate Factor and uses a perceptual quality model" (technically correct, practically useless) 2. "Use CRF 23 for the best results" (no context for why)

This post is what I wish I'd read when I first encountered CRF. It's everything you need to know, no math, with concrete numbers for the situations Mac users actually face.

What CRF actually is

CRF is a single number you give to a video encoder (H.264, HEVC, AV1) that controls how aggressively it compresses each frame. The encoder then encodes the entire video targeting that quality level, regardless of how much that ends up costing in file size.

That last part is the key insight.

The alternative — target bitrate (e.g., "encode at 2 Mbps") — is the opposite philosophy: you commit to a file size up front, and the encoder does its best to fit the video into that budget. Calm scenes get over-allocated; chaotic scenes get under-allocated.

CRF flips this: the encoder spends as many bits as needed to hit your quality target. A still talking-head video might end up at 500 Kbps; a fast-action scene in the same file might balloon to 8 Mbps. The encoder is honest about what each frame needs.

For most "compress this video for sharing" cases, CRF is the right knob. Target bitrate is what you use when the destination has a hard cap (Twitter's bitrate ceiling, Discord's 25 MB total file size).

How the numbers work

CRF runs roughly 0 to 51, where lower numbers = higher quality and counterintuitively bigger files.

For H.264 specifically, the rules of thumb that hold up:

• CRF 17 is considered the "you won't see the difference from source" threshold
• CRF 23 is the libx264 default (this is what HandBrake's slider sits at by default)
• CRF 28 is when you start to see compression artifacts, especially in shadows, gradients, and fast motion

Each step of +6 roughly halves the file size. So going from CRF 23 to CRF 29 cuts the file approximately in half — at noticeable but often acceptable quality cost.

HEVC (H.265) uses different numbers

HEVC's CRF scale is shifted: subtract about 6 from the H.264 number to get the rough HEVC equivalent.

So libx264 -crf 23 ≈ libx265 -crf 28 in quality. HEVC files at the same quality are typically 30-50% smaller, but encoding takes 2-4x longer.

AV1 uses very different numbers

AV1 (the codec inside .mp4 files marked "AV1" or .webm) uses CRF 0-63 with even more shifting:

AV1 produces smaller files than HEVC at the same quality, but encoding is 5-20x slower. As of 2026, AV1 is most useful for archival of large content libraries where compute is cheap and bytes matter.

The encoder preset matters too

Alongside CRF, every modern encoder takes a preset flag that controls how hard it tries:

ultrafast → superfast → veryfast → faster → fast → medium → slow → slower → veryslow → placebo

Faster preset = quicker encode, larger file (at the same CRF). Slower preset = more compute, smaller file.

For x264:

• ultrafast is about 8x faster than medium but produces ~30% larger files
• medium is the default — most users should stay here
• slow is roughly 30% slower than medium for ~10% smaller files
• veryslow doubles encoding time for marginal savings — diminishing returns

For most "compress this for upload" cases, medium is the right preset. Use slow only when you'll re-encode many times from the same source and the time is worth it.

A practical CRF recipe table

Numbers are approximate — actual sizes depend on content (motion, detail, color) and source bitrate. Treat them as starting points.

We measured it: the same clip at three CRF values

Rules of thumb are easy to repeat and hard to trust, so we re-verified them for this update (September 2026) by encoding the same 15-second 720p test clip with ffmpeg 6.1, -preset medium, on the same machine:

Two things the numbers confirm:

• Each +5 CRF cut the file by roughly 35–55% on this clip — consistent with the "+6 ≈ half the size" rule of thumb. Quality degrades gradually; size falls off a cliff.
• Encode time barely moves with CRF. The preset, not the CRF value, is what you're paying time for.

And one thing that surprises people: we also ran *x265 at the same CRF 23, and it produced a bigger file (6.6 MB) than x264 at CRF 23 — while taking 2.7× as long. That's not x265 being bad; it's the point made above about scales: HEVC's CRF numbers don't map to H.264's.* Encode x265 at its equivalent CRF 28 and you get 3.7 MB — 31% smaller than the x264 result, as advertised. If you take one thing from this table: never carry a CRF value from one codec to another.

Reproduce it yourself — environment: ffmpeg 6.1.1 (Ubuntu 24.04 build), software encoders libx264/libx265, no hardware acceleration. Source: 15 s, 1280×720, 30 fps, generated with ffmpeg -f lavfi -i "testsrc2=size=1280x720:rate=30:duration=15" -c:v libx264 -crf 10 -preset ultrafast -an master.mp4 (26.1 MB). Each encode: ffmpeg -i master.mp4 -c:v libx264 -crf N -preset medium -an out.mp4 (and -c:v libx265 -tag:v hvc1 for the HEVC runs). Synthetic test-pattern source, so treat the absolute sizes as illustrative — the ratios are what hold on real footage; your times will scale with your CPU.

ffmpeg one-liners

# H.264 CRF 23, medium preset, AAC audio — best general-purpose recipe
ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

# HEVC CRF 28 for smaller files — Apple ecosystem
ffmpeg -i input.mov -c:v libx265 -crf 28 -preset medium -tag:v hvc1 -c:a aac -b:a 128k output.mp4

# Target a specific file size by trying CRF 28, then tweak
ffmpeg -i input.mov -c:v libx264 -crf 28 -preset medium -c:a aac -b:a 96k output.mp4

The -tag:v hvc1 flag matters for HEVC in Apple's ecosystem — without it, QuickTime, iOS Messages, and Final Cut may refuse to play the file.

Why CRF is better than bitrate for most cases

Three reasons:

1. Consistent quality across the entire video. A target-bitrate encode under-allocates fast scenes (you see compression artifacts during action) and over-allocates calm scenes (wasted bits). CRF spends bits where they're needed.

2. Honest with you about size. If you set CRF 23 and the file ends up 200 MB instead of your hoped-for 50 MB — that's the encoder telling you the content genuinely needs that many bits to look acceptable at that quality. Target bitrate would have squeezed it into 50 MB but the result would have artifacts.

3. Easier to reason about. "CRF 23" is portable. The same CRF on similar content produces similar quality. "2 Mbps" depends entirely on resolution, framerate, and motion — what's enough for a 480p webinar is starvation for 4K sports.

When CRF isn't the right answer

A few legitimate reasons to use target bitrate instead:

• Discord's 25 MB cap, exactly. You want the file to be 24.5 MB no matter what. Calculate the bitrate, target it.
• Streaming or fixed-bandwidth contexts. RTMP, HLS, DASH all require bitrate-constant outputs.
• Two-pass encoding for archival. Two-pass with -b:v produces extremely consistent file size, useful when delivery specs require it.
• Specific delivery codecs (broadcast TV, Blu-ray) — strict bitrate envelopes per the spec.

For everyday "compress a video to share" — CRF wins.

Where CRF lives in GUI apps

Every major Mac video tool exposes CRF, sometimes calling it something else:

• HandBrake: the "Quality" slider on the Video tab is CRF (labeled "RF" — Rate Factor — but it's the same number)
• Compressor (Final Cut): hidden in advanced encoder settings; defaults are bitrate-targeted
• QuickVid Compress: Pro tier exposes CRF in Custom mode; presets internally use CRF 22-30 depending on the mode
• FastFlix: open-source ffmpeg GUI; its "Quality" setting is CRF passed straight through — closest to HandBrake, with wider codec coverage (AV1 via SVT-AV1) but a more utilitarian interface
• ffmpeg: explicit -crf N flag

If you find yourself wanting CRF control without ffmpeg's flag surface, QuickVid Pro mode is the gentle on-ramp.

What QuickVid's presets translate to

For the curious, here's what QuickVid's named modes correspond to in CRF:

If your case matches "Tiny" (small enough for any chat app), you don't need to think about CRF. If your case is between two presets, drop into Pro mode and dial in CRF directly.

A final mental model

Think of CRF like JPEG's quality slider, but for video. JPEG quality 80 means "encode each block to a target perceptual quality of 80." CRF 23 means "encode each frame to a target perceptual quality of 23."

The number is inverted (lower CRF = higher quality, opposite of JPEG quality) but the concept is identical. Once you internalize that, the rest of video compression makes a lot more sense.

Closing

If you compress video more than monthly, save this post or pin the CRF table. The shorthand:

• CRF 23 H.264 medium = the general-purpose right answer
• CRF 28 HEVC medium ≈ same quality, 30% smaller, Apple ecosystem only
• CRF 30 H.264 medium = the "fits in any chat app" answer
• CRF 18 H.264 slow = archival quality

For dragging-and-dropping rather than typing flags: QuickVid Compress wraps these recipes into named modes. The CRF math is the same; the UI just hides it.

FAQ

What is the best CRF value for compression?

CRF 23 is the libx264 default and produces visually high-quality H.264 video at modest file sizes — typically 50-80% smaller than the source. For HEVC, the equivalent is CRF 28. For lossless-feeling archival, drop to CRF 18 (H.264). For aggressive compression where artifacts are acceptable, go up to CRF 28-30.

Is CRF 18 lossless?

No — CRF 18 is "visually transparent" or "visually lossless" but mathematically still loses information vs the source. True lossless H.264 in ffmpeg is -c:v libx264 -qp 0 (with 8-bit x264, -crf 0 does the same thing; the --lossless flag belongs to the standalone x264 CLI, not ffmpeg). Either way the files come out about as large as raw video. CRF 18 is what video professionals call "transparent quality" — indistinguishable from source on normal playback.

What's the difference between CRF and bitrate?

CRF targets a perceptual quality level and lets file size vary based on content complexity. Target bitrate (e.g., -b:v 2M for 2 Mbps) fixes the file size and lets quality vary. CRF is better when you want consistent quality across the video; target bitrate is better when you need a specific file size for upload limits.

Does CRF work with HEVC and AV1?

Yes, but the numerical scale shifts. H.264 CRF 23 ≈ HEVC CRF 28 ≈ AV1 CRF 35 for similar quality. Each codec has its own quantizer math, but the principle is identical: lower number = higher quality, larger file.

How do I use CRF in HandBrake?

HandBrake's "Quality" slider on the Video tab is CRF (labeled "RF"). Set it to your target — 20 for high quality, 23 for general use, 26 for smaller files. Make sure the "Constant Quality" radio is selected (not "Average Bitrate"). Pick H.264 (x264) or H.265 (x265) as the video codec and "Constant Quality" mode under "Video".