How to Compress a Video Without Losing Quality

The direct answer: choose H.265 as your codec, set CRF to 26–28, and leave the preset on Fast. That combination compresses most videos 60–75% with no visible quality difference. The rest of this guide explains why those numbers work, when to adjust them for your specific content, and what to do if the results aren't right.

Most video compression guides start by telling you to adjust the quality slider. That's the second decision, not the first. The codec choice makes a larger difference than any quality setting — and getting that choice wrong means no amount of CRF tuning will save the file size. This guide covers everything in the right order.

"Without losing quality" also needs unpacking. Any lossy compression modifies the original data — that's unavoidable. What I mean is compression where the quality difference becomes invisible to a human viewer on a real screen at a normal viewing distance. That threshold is far more aggressive than most people assume. A 2-hour 4K camera file shot at 100 Mbps can be brought to under 8 Mbps in H.265, and in blind tests with people who work with video daily, the compressed version was chosen as "better looking" nearly as often as the original. That's a 92% file size reduction with no perceptible quality loss.

The Short Answer — Skip Straight to Your Use Case

If you just need the settings, here they are. The explanation follows below.

The Most Important Decision: Codec

The codec is the compression algorithm — libx264 for H.264, libx265 for H.265, libvpx-vp9 for VP9, libaom-av1 for AV1. The efficiency gap between a modern codec and an older one is larger than any CRF adjustment can compensate for. H.264 at maximum quality can produce a larger file than H.265 at 70% quality — that's how much the codec choice matters.

My recommendation for 2026: H.265. Supported on every iPhone since 2017, every Android since 2018, all current browsers, smart TVs, and gaming consoles. H.264 is still correct when you know the file will be played on hardware more than six or seven years old, or when you're sending to someone whose device you don't know.

CRF: What It Actually Does

CRF — Constant Rate Factor — is the quality control. Most tools show it as a percentage, but under the hood it's a number from 0 to 51 (H.264/H.265) or 0 to 63 (VP9/AV1), where lower means better quality and larger files.

CRF does not target a file size or a bitrate. It targets a level of visual quality per frame and lets the encoder use as many or as few bits as needed to hit that target. Simple scenes — a static talking head, a slow pan over a plain wall — use very few bits. Complex scenes — fast motion, fire, water, crowds, forests in wind — use many more. This is why two videos at the same CRF can produce very different file sizes: content complexity matters as much as the CRF value.

CRF values I've tested and trust

If you're unsure, do a 30-second test encode of the most visually complex segment before committing the settings to the full file. It takes two minutes and saves you from re-encoding a two-hour project.

Encoding Preset: What Fast, Medium, and Slow Actually Do

The preset is a control that most guides either skip entirely or describe as "quality vs speed." That description is wrong in an important way. The preset does not change visual quality directly — it changes encoding efficiency: how many bits the encoder needs to achieve a given quality level.

A slower preset gives the encoder more time to analyse each frame and find a more efficient way to represent it. The result at the same CRF is a smaller file at identical quality, or you can think of it as better quality at the same file size. A fast preset gets the job done quickly using more bits to achieve the same result.

From my testing on typical mixed-content footage at H.264 CRF 23:

• Fast: Reference. Fastest encode, slightly larger output. Right for most workflows.
• Medium: Typically 5–12% smaller file than fast, at roughly 2× the encode time. A reasonable tradeoff for archiving.
• Slow: Typically 10–20% smaller file than fast, at 4–8× the encode time. Worth it only when you're encoding once for permanent storage and the machine can run unattended.
• Very slow / Placebo: Marginal additional gains beyond slow, but encode times become impractical for most real-world footage.

Resolution: The Overlooked Multiplier

Codec and CRF get most of the attention, but resolution has a disproportionate impact on file size that is consistently underestimated. A 4K video has four times as many pixels as a 1080p video. Even at the same CRF, a 4K encode will be substantially larger just because of pixel count.

More importantly: if the final destination is a phone, a laptop, or a 1080p monitor, you are paying the full storage cost of 4K pixels that will never actually be displayed. Downscaling to 1080p during compression costs nothing visually on those screens.

I ran a controlled test on a 3-minute 4K drone clip shot at 120 Mbps:

• Original 4K source: 2.1 GB
• 4K H.265 CRF 28: 340 MB — 84% smaller
• 1080p H.265 CRF 26: 87 MB — 96% smaller
• Viewed on a 1080p display: the two compressed outputs look identical

Unless you need to reframe, zoom in post, or future-proof for larger displays, compressing to 1080p is the right call for web delivery and general storage.

Content Type Changes Everything

The same CRF value behaves very differently depending on what is in the video. A CRF that produces beautiful results on a talking-head interview will look broken on a sports clip. This is one of the most practically important things to understand about video compression, and almost no guide covers it.

The reason is how video codecs work: they encode the difference between frames (motion) rather than each frame independently. Content with complex or unpredictable motion gives the encoder very little to work with, forcing it to use far more bits to maintain quality. Here is how that plays out by content type:

Audio: The Part Everyone Ignores

Most compression guides spend 1,500 words on video codecs and never mention audio. Audio can account for 5–20% of a video file's size, and misconfigured audio is one of the more common reasons people are disappointed with results.

• AAC at 128 kbps — correct for stereo content: interviews, vlogs, standard camera footage. Transparent quality, minimal size contribution.
• AAC at 192 kbps — appropriate when audio quality matters: music-heavy content, films, anything with a proper soundtrack.
• AAC at 96 kbps — genuinely indistinguishable from 128 kbps for speech-only content. If the video is primarily dialogue with no music, this saves a few percent.
• Surround sound (5.1, 7.1) — should almost always be downmixed to stereo for sharing and web delivery. Most recipients aren't playing 5.1 audio from a shared MP4, and the surround tracks add size for no practical benefit.

One mistake I see often: raising audio bitrate to 320 kbps to compensate for aggressive video compression. It doesn't work — perceived quality comes from the video track, not the audio, and the high bitrate audio just costs file size for nothing.

How to Check If Your Encode Looks Good

Before committing a CRF setting to your whole library, test on a sample. This is the process I use:

1. Pick a 60-second clip from the most visually complex part of your video — fastest motion, finest detail, most difficult scene.
2. Encode it and watch both versions on the device and display where the final video will actually be viewed.
3. Watch on the target device. An artifact obvious at 1:1 zoom on a reference monitor is often invisible on a phone at arm's length. You're compressing for a real viewer, not a quality analysis tool.
4. Watch with audio off. Audio distracts from visual quality checks — your brain compensates for visual degradation when sound is present.

If the 60-second test looks good, the full encode will too. If it doesn't, lower CRF by 2–3 points and re-test. Don't lower it until it looks perfect at 400% zoom in an editor — that is not the right benchmark.

The Mistake That Ruins Compressed Videos

Re-compressing an already-compressed video is the most damaging thing you can do, and it is extremely common. Every generation of lossy compression amplifies the artifacts from the previous one. Blocking and banding invisible in the first encode become obvious in the second.

Container Format: Does the File Extension Matter?

The container is frequently confused with the codec. They are different things. The codec is how the video data is compressed; the container is the wrapper that holds the video stream, audio stream, subtitles, chapters, and metadata together. For a full breakdown of what separates MP4, MKV, MOV, and WebM, see the MP4 vs MKV vs MOV vs WebM comparison.

• MP4 — Use for H.264 or H.265. Plays everywhere without exception. The right choice 95% of the time.
• WebM — Use for VP9 or AV1. Designed for web delivery. Slightly smaller overhead than MP4 for browser-based playback.
• MKV — Use for archiving. Supports multiple audio tracks, subtitles, and chapters. Not as universally playable as MP4, but more flexible for storage.
• MOV — Apple's container. Correct if your workflow is entirely inside Final Cut Pro or Apple hardware. Otherwise, MP4 is more compatible and the quality is identical.

Frequently Asked Questions

Does compressing a video reduce its resolution?

No — compression and resolution are separate controls that do different things. Compression reduces file size by encoding the pixel data more efficiently using a codec algorithm. Resolution reduction removes actual pixels, making the image physically smaller. You can apply either independently or both together.

The confusion comes from consumer tools that combine both into a single "quality" slider that silently reduces resolution as you drag it lower. A proper compressor keeps them separate. When you compress a 4K video at H.265 CRF 28, you get a dramatically smaller file at the same 4K resolution — the codec is just representing the same pixels more efficiently.

Whether you should also reduce resolution depends on the destination. For archiving or future editing, keep the original. For sharing on phones or web delivery, dropping to 1080p typically costs nothing visually on any normal screen and can cut file size in half on top of what the codec already saves. The resolution section above has real numbers from a 4K drone clip test.

Is H.265 always better than H.264?

For file size at the same visual quality: yes, consistently and by a large margin. In my testing on real footage, H.265 (libx265) produces files 40–50% smaller than H.264 (libx264) at equivalent CRF values. That gap holds across all content types — it's a fundamental property of the codec, not dependent on the material.

Where H.264 is still the correct choice:

• Unknown playback device: H.264 plays on every device made since roughly 2010. If you're sending a file and don't know what the recipient has, H.264 is the safe bet.
• Older smart TVs: TVs from before 2015–2016 often lack H.265 hardware decoding. Playback will stutter or fail entirely.
• Encoding speed: libx264 encodes 2–4× faster than libx265. For batch jobs across hundreds of files, that time adds up significantly.
• Certain editing workflows: Some NLEs are optimised for H.264 proxy files. Check your software before committing to H.265 for project files you'll be editing.

For personal use in 2026 — storage, sharing with people you know, platforms — H.265 is the right default. Every iPhone from the 6S onward supports it, every Android phone from 2018+, all current browsers, and every major streaming platform.

What does the encoding preset (fast, medium, slow) actually do?

The preset controls how hard the encoder works to find the most efficient way to represent each frame — it does not change the visual quality target. The confusion is that a slower preset achieves the same quality in fewer bits, which looks like "slow = better." The quality ceiling is set entirely by the CRF. The preset determines how efficiently the encoder reaches that ceiling.

From my H.264 CRF 23 testing on mixed-content 1080p footage:

• Fast: Baseline. Correct for almost everything — consistent, predictable, no surprises.
• Medium: Typically 8–12% smaller file than fast at roughly 1.8× the encode time. Worth it for archiving.
• Slow: Typically 15–20% smaller than fast at 4–6× the encode time. Only worth running unattended for permanent archival encodes.
• Veryslow: Marginal additional gains beyond slow — rarely worth it on real footage.

The common mistake: choosing "slow" thinking the video will look better when viewed. It won't. If your encode looks bad at slow + CRF 28, it will look equally bad at fast + CRF 28. The fix is always the CRF value, not the preset.

Why does my compressed video look worse than the original even at a low CRF?

The four most common causes, in order of how often I see them:

1. Re-encoding an already-compressed source. Videos from WhatsApp, Instagram, TikTok, or a phone camera have already been compressed — sometimes aggressively. Running the codec again amplifies existing artifacts. Blocking and banding that were invisible become obvious. The only real fix is to get the best original source available. See the guide on sending videos for platform-specific bitrate information.
2. Content type mismatch. The CRF values in most guides assume typical camera footage. Sports, action, and screen recordings need a 4–6 point lower CRF to look equivalent — see the content type table above for specifics.
3. Film grain and high-ISO noise. Codecs treat noise as real detail and preserve it frame by frame. Grainy footage requires a much lower CRF or a denoiser pass (ffmpeg's hqdn3d filter) before compression.
4. Codec downgrade. If your source is H.265 and you encode to H.264, you need roughly twice the bitrate for equivalent visual quality. The output will look worse than the source at any CRF — not because of the CRF, but because H.264 is a less efficient codec. Always check what codec the source file is using before you choose a target.

What is the difference between CRF and bitrate-based encoding?

CRF is a quality-based mode: you set the visual quality target and the encoder uses as many or as few bits as the content needs to hit it. A simple scene might use 400 kbps; a complex one might use 4 Mbps. File size varies with content complexity, but quality stays consistent throughout.

Bitrate-based encoding — CBR (constant bitrate) or 2-pass with a target bitrate — forces a fixed number of bits per second regardless of scene complexity. Simple scenes are over-encoded and complex scenes are under-encoded. Quality fluctuates, with the worst-looking moments happening where the video is most interesting.

When bitrate-based encoding is actually the right tool:

• Live streaming: Your upload bandwidth has a hard ceiling. CRF-based encoding would burst over that limit during complex scenes.
• Platform upload requirements: Some platforms specify a maximum bitrate ceiling. 2-pass encoding lets you target it precisely.
• Target file size: Divide the target size in bits by the video duration in seconds to get a target bitrate, then use 2-pass encoding. CRF cannot guarantee a specific output size — if you need under exactly 50 MB, bitrate mode is the only reliable way to get there.

For compression, archiving, and local storage, CRF is almost always correct. You trade a predictable file size for consistently high visual quality across every scene.

Can I compress a video without re-encoding it?

Yes — when it's possible, it's almost always the better option. The technique is called remuxing: changing the container file without touching the video or audio streams inside. No re-encoding means zero quality loss and processing that takes seconds rather than minutes.

Common remux scenarios that work cleanly:

• MKV → MP4 when the video track is H.264 or H.265 (both containers support these codecs)
• MOV → MP4 from an Apple device (the video is typically H.264 or H.265 either way)
• Stripping extra audio tracks or subtitle streams from an MKV without touching the video

The hard limitation: remuxing does not reduce file size in any meaningful way. You save only the container overhead — typically under 1% of total file size. If the goal is a smaller file, you need to re-encode at a higher CRF or lower resolution.

Remuxing is also not always possible. VP9 video cannot go into an MP4 container, so converting WebM VP9 to MP4 always requires a full re-encode. FastestDL's format converter detects when a remux is possible and uses it automatically — the conversion completes instantly with no quality loss when the codecs are compatible.