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.
| CRF | What it looks like | Common use | |---|---|---| | 0 | Visually lossless. Massive files. | Mastering, archival. | | 18 | "Visually transparent" — no perceptible quality loss on most content. | Editing copy, professional delivery. | | 23 | Default for H.264. Good balance for web video. | Most online video. | | 28 | Noticeable but acceptable artifacts. Much smaller files. | Compressed for share, social media. | | 35+ | Visibly low quality. | Old phones, low bandwidth. |
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.
| H.264 CRF | HEVC CRF | Quality | |---|---|---| | 18 | 22 | Visually transparent | | 23 | 28 | Web video default | | 28 | 32 | Compressed share |
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:
| H.264 CRF | AV1 CRF | Quality | |---|---|---| | 18 | 28 | Visually transparent | | 23 | 35 | Web video default | | 28 | 45 | Compressed share |
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
| Task | Codec | CRF | Preset | Expected size (1 min 1080p) | |---|---|---|---|---| | Archive original | H.264 | 17 | slow | ~250 MB | | YouTube upload | H.264 | 20 | medium | ~120 MB | | Email attachment | H.264 | 26 | medium | ~25 MB | | Discord (under 25 MB) | H.264 | 28 | medium | ~18 MB | | Twitter/X video | H.264 | 23 | medium | ~50 MB | | iMessage to Apple users | HEVC | 24 | medium | ~70 MB | | iMessage fallback to email | H.264 | 28 | medium | ~20 MB | | Phone backup of family video | HEVC | 22 | slow | ~110 MB |
Numbers are approximate — actual sizes depend on content (motion, detail, color) and source bitrate. Treat them as starting points.
ffmpeg one-liners
```bash
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:vproduces 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
- ffmpeg: explicit
-crf Nflag
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:
| Mode | Codec | CRF | Preset | Typical 1-min 1080p output | |---|---|---|---|---| | Maximum Quality | H.264 | 19 | slow | ~180 MB | | Recommended | H.264 | 23 | medium | ~50 MB | | Web Optimized | H.264 | 26 | medium | ~30 MB | | Tiny | H.264 | 30 | medium | ~12 MB |
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 requires -crf 0 or -qp 0 plus the --lossless flag, which produces files about as large as the original 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".