"Compress this video without losing quality" is one of the most-searched video editing queries on Google. It's also one of the most-misunderstood — because strict "no quality loss" is mathematically impossible with any lossy codec (H.264, HEVC, AV1).
What people actually mean is visually lossless — a compressed file that's indistinguishable from the source at normal viewing distance. This is achievable. Here's how, ranked from "no work" to "every byte counts."
Why "no quality loss" is complicated
Every modern video format you'd ship — MP4, MOV, WebM — uses a lossy codec to compress frames. H.264, HEVC, AV1, VP9 — all of them throw away data. That's the whole point. The data they throw away is data that, by design, your eye doesn't notice in motion.
A "lossless" video codec exists (the encoding flag -crf 0 in H.264, or specific lossless codecs like FFV1 or HuffYUV) but the resulting files are usually larger than the original. Lossless H.264 of a 1080p video can be 100-300 Mbps, equivalent to 750 MB to 2.2 GB per minute. That defeats the point of compressing.
The pragmatic goal: smallest file size where you can't see the difference on playback.
The single most-useful rule
H.264, CRF 18, preset slow. This produces "visually transparent" output for almost any source. The file is typically 50-70% the size of the original (assuming a reasonably high-bitrate source).
``bash ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a copy output.mp4 ``
If you want it 30-50% smaller for the same visual quality, switch to HEVC:
``bash ffmpeg -i input.mp4 -c:v libx265 -crf 22 -preset slow -tag:v hvc1 -c:a copy output.mp4 ``
These two one-liners cover 90% of the "compress without losing quality" cases.
Why CRF matters more than bitrate
If you've ever set a target bitrate (e.g., 5 Mbps) and gotten visible artifacts in fast scenes, that's why CRF exists. CRF tells the encoder "spend whatever bits you need to hit this perceptual quality" — it varies the bitrate moment by moment.
A quick scale to remember:
| CRF (H.264) | What it produces | |---|---| | 0 | True mathematical lossless — usually larger than source | | 14-17 | Visually identical to source even on critical viewing | | 18-19 | Visually transparent — the "no quality loss" sweet spot | | 20-23 | High quality, web-friendly | | 24-28 | Noticeable but acceptable for casual viewing |
For "no visible quality loss", CRF 18 in H.264 or CRF 22 in HEVC is the right pick. Below CRF 18 the file size grows quickly for minimal visible gain.
For the deep dive on CRF: What is CRF in video compression?
The audio question
Most "compress this video" workflows mess up the audio. The fix is usually to copy the original audio stream rather than re-encode:
``bash ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a copy output.mp4 ``
-c:a copy keeps the original AAC/MP3/whatever audio bit-perfect. No quality loss on the audio side at all.
If the audio is huge (uncompressed or PCM), re-encode to AAC at 192 Kbps:
``bash ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 192k output.mp4 ``
192 Kbps AAC is transparent for music and dialogue. Don't go below 128 Kbps if "no quality loss" is the goal.
The "slow" preset is worth it
ffmpeg's encoder preset controls how hard it tries:
ultrafast → superfast → veryfast → faster → fast → medium → slow → slower → veryslow → placebo
For "no quality loss" compression, slow is the sweet spot. It's ~30% slower than medium for ~10-15% smaller output at the same CRF. Visually identical. The encoding-time hit is worth it.
veryslow doubles encoding time for marginal additional savings — diminishing returns. Don't bother unless you're compressing the same source many times.
Apple Silicon hardware encoding caveat
Mac's VideoToolbox hardware encoder (used by QuickTime, iMovie, and -c:v h264_videotoolbox in ffmpeg) is fast but quality-inferior to software libx264/libx265 at the same file size. For "no quality loss":
- If speed matters: hardware encode (VideoToolbox) at higher CRF/bitrate. Quality drops modestly, speed gain is 5-10x.
- If quality matters: software encode (libx264/libx265) at a lower CRF. Slower but consistently smaller file at the same visual quality.
Most GUI Mac apps (including QuickVid and HandBrake) default to VideoToolbox for speed. For "no quality loss" specifically, you'll get smaller-but-equal-quality output from libx264/libx265 software encoding. The tradeoff is encode time.
Realistic file size expectations
If your source is a typical iPhone 1080p 60 fps video at ~30 Mbps:
| Method | Output bitrate | 1-min output size | Visual quality | |---|---|---|---| | Source (no compression) | 30 Mbps | 225 MB | Pristine | | H.264 CRF 17 slow | 12 Mbps | 90 MB | Visually identical | | H.264 CRF 18 slow | 10 Mbps | 75 MB | Visually transparent | | HEVC CRF 20 slow | 7 Mbps | 53 MB | Visually identical | | HEVC CRF 22 slow | 5 Mbps | 38 MB | Visually transparent | | AV1 CRF 28 medium | 4 Mbps | 30 MB | Visually transparent |
For a 1-minute iPhone video, you can realistically expect ~30-50% of the source size at "visually lossless" quality. For ScreenFlow / OBS captures of slides or screen recordings (lots of static content), savings are even larger — 5-10x is common.
The GUI path on Mac
If you don't want to type ffmpeg flags:
HandBrake
1. Open HandBrake, drop video in 2. Preset: "Fast 1080p30" then adjust 3. Video tab → Encoder: H.264 (x264), Framerate: Same as source 4. Slider: "Constant Quality" → RF 18 (HandBrake's RF == CRF) 5. Preset dropdown (in the picker): "Slow" 6. Audio tab: keep source audio 7. Start
Output is functionally identical to the ffmpeg one-liner.
QuickVid
1. Drop video into QuickVid 2. Pick "Maximum Quality" mode (internally maps to CRF 19, preset slow) 3. Save
For more control, Pro mode exposes the CRF slider directly — same recipe (CRF 18 H.264 or CRF 22 HEVC, preset slow) without typing flags.
Compressor (Final Cut companion)
Apple's Compressor has a "ProRes 422" preset that's near-lossless (and large). For "compress while keeping quality": custom job → H.264 → Quality Slider all the way to the right → Encoder: Multi-pass. Slightly slower than ffmpeg software encode but tightly integrated with FCP.
When you can NOT get smaller without quality loss
A few cases where you should accept the source size:
- Already-compressed source. A video that's been re-encoded multiple times by Discord, WhatsApp, or social platforms is already at the floor. Re-encoding makes it worse, not smaller.
- Animated content with sharp edges (cartoons, slide decks with text). Lossy codecs blur text edges. Use lossless or near-lossless H.264 (
-crf 12). - Source files <50 MB total. The compression savings probably aren't worth the encoding time. Just send the original.
- Audio-heavy content (music videos, podcasts with video). The audio is most of the bitrate; you can't shrink that without affecting audibly.
A practical recipe table
| Use case | Codec | CRF | Preset | 1-min 1080p estimate | |---|---|---|---|---| | Archive original quality | H.264 | 17 | slow | ~100 MB | | Visually lossless for sharing | H.264 | 18 | slow | ~75 MB | | Visually lossless, small | HEVC | 22 | slow | ~40 MB | | Smallest visually transparent | AV1 | 28 | medium | ~30 MB | | Quick proxies (faster encode) | H.264 | 18 | medium | ~85 MB |
Save this table or pin the CRF guide — most "compress without quality loss" questions are about one of these rows.
Closing
"No quality loss" really means "no visible quality loss". CRF 18 H.264 with the slow preset is the canonical right answer. For ~30% additional savings at the same visual quality, switch to HEVC at CRF 22.
If you compress video weekly and don't want to remember flags, QuickVid Compress wraps these recipes into named modes — drop, pick mode, save. Maximum Quality mode is the visually-lossless preset.
Related reading: What is CRF in video compression? for the deep dive, Compress video for Discord on Mac for the size-cap-targeting case, iMessage attachment too big for the iMessage-specific recipes.
FAQ
Can I compress a video without any quality loss at all?
True mathematical lossless compression (-crf 0 in H.264 or a lossless codec) is possible but typically produces files larger than the source. "Visually lossless" — compression that produces files indistinguishable from the source on normal playback — is achievable at CRF 17-18 in H.264 (about 30-50% the source size).
What is the best codec for compressing MP4 without losing quality?
H.264 at CRF 18 (preset slow) is the canonical "no visible quality loss" recipe — universally compatible, produces files about 30-50% the source size. For smaller files at the same visual quality, HEVC at CRF 22 (preset slow) is 30% smaller but requires more modern players. AV1 at CRF 28 is the smallest but takes 5-10x longer to encode.
Why is my compressed video lower quality than the source?
Most "video compressor" tools default to fast presets and middle-of-the-road CRF values (often CRF 23-26) for speed and small file size. For visually lossless output, you need CRF 17-19 in H.264 or CRF 21-23 in HEVC plus the slow preset. Many GUI tools hide these settings under "advanced" — use a tool that exposes them, like ffmpeg, HandBrake, or QuickVid Pro mode.
How small can I make a video without seeing quality loss?
For a typical 1080p iPhone video, you can realistically get down to ~30% of the source size at H.264 CRF 18, or ~20% at HEVC CRF 22, without visible quality loss on normal playback. Screen recordings with lots of static content can shrink to 5-10% of the source. Below those thresholds, compression artifacts become visible.
Should I use hardware encoding or software encoding on Mac?
For "no quality loss" — software encoding (libx264, libx265) at a lower CRF. Hardware encoding (VideoToolbox on Apple Silicon) is 5-10x faster but produces visibly worse output at the same file size. For everyday speed-vs-quality tradeoffs, hardware encoding is fine. For visually lossless archival, software is the right pick — slower but consistently higher quality at the same bitrate.