How to Compress Videos Without Losing Quality: The Practical Guide

"Compress without losing quality" sounds like a contradiction, and in the strictest mathematical sense it is: every lossy re-encode discards information. But here's the practical truth that matters — most video files are dramatically larger than they need to be, because cameras and phones encode in real time with generous safety margins. A modern encoder, given time to think, can routinely cut file sizes by 50–90% with no difference a human eye can detect on a real screen. The skill isn't avoiding loss; it's making sure every megabyte you throw away is one nobody would ever miss. This guide covers the concepts you need (briefly), then gets to what you came for: settings and recipes that work.

The three levers: bitrate, resolution, and codec efficiency

Every compression decision pulls one of three levers.

Bitrate is how much data per second the file spends describing the picture — the single biggest factor in file size. A file's size is simply bitrate × duration, so halving bitrate halves the file. Quality drops only when bitrate falls below what the content actually needs, and that threshold varies wildly: a static slideshow looks perfect at bitrates that would turn a confetti-filled concert into mush.

Resolution is pixel count. Downscaling 4K to 1080p cuts pixel data by 75%, and if the video will be watched on a phone or embedded small in a web page, nobody will notice. But resolution is a blunt instrument — dropping it when bitrate was the real problem just gives you a small and soft-looking file. Reduce resolution only when the display context genuinely doesn't need the pixels.

Codec efficiency is the free lunch. Newer codecs describe the same picture with less data: H.265/HEVC needs roughly 30–50% fewer bits than H.264 for equivalent quality, and AV1 improves on HEVC by another 20–30%. If your source is H.264 from a phone or an old download, re-encoding to HEVC or AV1 shrinks it substantially before you sacrifice anything at all.

The best compressions pull all three levers deliberately: pick the most efficient codec your viewers can play, keep resolution matched to the viewing context, and let a quality-based encoder set the bitrate.

CRF: the setting that changes everything

If you take one technique from this article, take this one. Don't set a bitrate — set a quality level, and let the encoder spend bits where the content needs them. That's Constant Rate Factor (CRF) encoding, and it's how x264, x265, and SVT-AV1 all prefer to work.

With CRF, you choose a number where lower = better quality and bigger files. The encoder then allocates bitrate scene by scene: lots of bits for the fast pan across water, very few for the static interview backdrop. The result beats a fixed bitrate at the same file size, every time.

Useful CRF ranges differ per encoder because the scales aren't equivalent:

Encoder	Visually lossless	Great default	Acceptable minimum	Notes
x264 (H.264)	17–18	20–22	26	The reference scale
x265 (HEVC)	20–21	23–25	28	Roughly x264 value +3
SVT-AV1	25–28	30–35	40	Different scale entirely (0–63)

Two rules of thumb: below CRF 17 (x264 scale) you're burning space on differences no display can show, and each +6 CRF roughly halves file size. Start at the "great default" column, check the output on the screen it'll actually be watched on, and adjust by 2 if needed.

The encoder preset (ultrafast → veryslow) is the other half of the equation: slower presets compress more efficiently at the same CRF. slow is the sweet spot for x264/x265; for SVT-AV1, preset 4–6 balances speed and efficiency well on modern CPUs.

When you actually need a target size: two-pass encoding

CRF's one weakness is that you can't predict the output size. When a hard limit exists — "this must be under 25 MB" — use two-pass encoding: the first pass analyzes the whole video, the second distributes your exact bitrate budget optimally across it.

Compute the bitrate from your budget: total bits ÷ duration. For 25 MB and a 60-second clip: (25 × 8,388,608 bits) ÷ 60 ≈ 3.5 Mbps total, so about 3.3 Mbps video after reserving 128 kbps for audio, with a little headroom for container overhead.

# Two-pass x264 targeting ~3.3 Mbps video
ffmpeg -i input.mp4 -c:v libx264 -b:v 3300k -pass 1 -an -f null NUL
ffmpeg -i input.mp4 -c:v libx264 -b:v 3300k -pass 2 -c:a aac -b:a 128k output.mp4

(On macOS/Linux, replace NUL with /dev/null.)

Switching codecs: when H.264 should become HEVC or AV1

Re-encoding H.264 source material with a modern codec is the highest-leverage compression move available, but it has prerequisites.

Switch to HEVC or AV1 when: the file will be stored or watched on hardware from roughly 2016+ (HEVC) or 2021+ (AV1); you're archiving and size matters; or the source bitrate is clearly bloated (phone footage, screen recordings, old high-bitrate downloads).

Stay on H.264 when: the file must play on unknown or old devices; you're uploading to a platform that re-encodes anyway (YouTube, Instagram — send them high quality H.264 and let them worry about it); or encoding time matters more than size.

One warning that saves heartbreak: don't re-encode repeatedly. Each lossy generation compounds artifacts. Keep your original as the master, encode compressed versions from that original, and never use a compressed output as the source for the next compression.

Audio deserves thirty seconds of attention too: it's rarely the size problem (128 kbps AAC ≈ 1 MB/minute), but sloppy settings waste space. Stereo AAC at 128–160 kbps or Opus at 96–128 kbps is transparent for most content; mono voice recordings are fine at 64–96 kbps. Copy the audio untouched (-c:a copy) when it's already sensible.

Practical recipes

The all-purpose shrink (visually identical, plays everywhere)

ffmpeg -i input.mp4 -c:v libx264 -crf 20 -preset slow \
  -c:a aac -b:a 128k -movflags +faststart output.mp4

Maximum compression for modern devices (HEVC)

ffmpeg -i input.mp4 -c:v libx265 -crf 24 -preset slow -tag:v hvc1 \
  -c:a aac -b:a 128k output.mp4

The -tag:v hvc1 flag makes the file play natively on Apple devices.

Archival AV1 (smallest, needs recent hardware to play smoothly)

ffmpeg -i input.mp4 -c:v libsvtav1 -crf 32 -preset 5 \
  -c:a libopus -b:a 112k output.mkv

Email attachment (~25 MB limits on most providers)

For a short clip, two-pass to a computed bitrate as shown earlier. For anything over a couple of minutes, be realistic: downscale to 720p and accept visible compression, or use a file-sharing link instead — a 10-minute video simply doesn't fit in 25 MB at watchable quality.

Discord (10 MB free-tier limit)

The harshest budget in common use. For a 30-second clip: 10 MB ≈ 84 Mbits ÷ 30 s ≈ 2.6 Mbps total. Combine tricks: 720p, HEVC or AV1 if your server-mates have modern devices, 96 kbps audio, two-pass video at ~2.4 Mbps. For clips over ~90 seconds, upload elsewhere and paste a link — the math stops working.

Web upload / self-hosted page

CRF-encode at 1080p (x264 CRF 21 or AV1 CRF 32), always with +faststart for MP4 so playback starts before the file finishes downloading. Consider serving an AV1/WebM version with an MP4 fallback if bandwidth matters.

Doing it in HandBrake (no command line required)

Everything above maps directly onto HandBrake's interface:

1. Open your file and pick a preset as a starting point — "Fast 1080p30" for general use, or an "H.265 MKV" preset for maximum compression.
2. Video tab: the "Constant Quality" slider is CRF. Set 20–22 for x264 or 23–25 for x265. Set the encoder preset dropdown to "Slow" if you can spare the time.
3. Dimensions tab: downscale here only if the viewing context justifies it (4K phone footage destined for a group chat → 1080p).
4. Audio tab: AAC at 128–160 kbps, or "Auto Passthru" to copy the original track untouched.
5. Preview before committing: encode a 30–60 second range (Preview button) to sanity-check quality on a demanding scene — dark footage and fast motion reveal problems first — before running the full encode.

HandBrake's queue makes batch work painless: configure once, add ten files, walk away.

FAQ

Why does my compressed video look worse than the original even at high settings?

Usually one of three causes: you compressed an already-compressed file (generational loss), you judged quality on dark scenes — where all encoders struggle most and banding appears first — or hardware encoding (NVENC/Quick Sync) was enabled when you assumed software. Try software x264 at CRF 18 on the same clip; if that looks right, work upward from there.

Is there truly lossless video compression?

Yes — x264 and x265 have lossless modes, and codecs like FFV1 exist for archival. But lossless video is enormous (often larger than camera originals) and it's the wrong tool for sharing. "Visually lossless" CRF encoding is what you want in practice.

Should I use my GPU to encode faster?

For quick shares where "good enough" is fine, absolutely — NVENC, Quick Sync, and VideoToolbox are 5× faster or more. For size-critical or archival encodes, software encoders still deliver meaningfully better quality per megabyte. Speed or efficiency: pick per job.

What's the single best setting if I remember nothing else?

x264, CRF 20, preset slow, AAC 128k. It's not the smallest option, but it's visually transparent, plays on everything, and beats whatever your camera produced by a wide margin.

Does compressing audio matter much?

Rarely for size — audio is typically under 5% of a video file. But don't upscale it either: re-encoding 128 kbps audio at 320 kbps wastes space without recovering anything.

The takeaway

Compression without visible loss is a solved problem — the tools are free and the recipes fit on an index card. Encode from originals, use CRF instead of guessing bitrates, reach for HEVC or AV1 when your audience's hardware allows, downscale only when the screen justifies it, and reserve two-pass encoding for hard size limits. Master those five habits and you'll never squint at a blocky, oversized video file of your own making again.