A video file’s size is bitrate × duration — nothing else. Every technique for shrinking a file is really pulling one of four levers on that equation: play less (trim), show fewer pixels (resolution), describe pixels more efficiently (codec), or describe them less precisely (quality setting). The trick is knowing which lever to pull first, because they’re not equally destructive.
Here’s the order that preserves the most quality per megabyte saved, with real numbers for each step.
First, Diagnose: Why Is This File Big?
Thirty seconds of diagnosis beats blind compression. The usual suspects:
- It’s a screen or game recording. OBS and capture tools record at generous bitrates on purpose — there’s usually 50%+ savings sitting there with zero visible cost.
- It’s from an old or inefficient codec. AVI-era files, MJPEG camera footage, and ProRes editing masters are enormous by design, not necessity. (Why masters are supposed to be huge is its own topic — see Understanding Video Codecs: H.264, ProRes, and When to Use Each.)
- It’s a GIF. Not technically a video, which is exactly the problem — skip straight to lever 5.
- It’s 4K when it’ll be watched at 1080p or smaller. The most common case of paying for pixels nobody sees.
Lever 1: Trim First (Free Quality)
Duration multiplies everything, and it’s the only lever with zero quality cost. Cutting a 90-second recording down to the 20 seconds that matter cuts the file by ~78% before any compression decision gets made. Dead air at the start of screen recordings, the fumbling before the take, the long tail after the point is made — trim it first, always.
This is step one rather than an afterthought because every other lever’s savings multiply against the trimmed duration, not the original.
Lever 2: Resolution (The Quadratic Lever)
File size scales roughly with pixel count, and pixel count scales with the square of resolution:
| Downscale | Pixel reduction | Typical size reduction |
|---|---|---|
| 4K → 1080p | 75% | 60–75% |
| 1080p → 720p | 56% | 40–55% |
| 4K → 720p | 89% | 80%+ |
The question is never “do I want 4K?” — it’s “will this be watched at 4K?” A clip destined for a chat message, an email, a web page column, or a phone screen gets displayed at 1080p or below no matter what you send. Downscaling to the display size discards only pixels the viewer physically couldn’t see.
Keep the original resolution when the video will be watched full-screen on large displays, when text must stay legible (screen recordings die at 720p), or when a platform re-encodes uploads and you want to feed it maximum quality.
Lever 3: Codec — Re-Encode Old and Inefficient Formats
Not all compression is equal. H.264 describes the same picture in a fraction of the bits that AVI-era codecs, MJPEG, or an editing codec like ProRes use. If your source is any of those, re-encoding to H.264 MP4 is close to free money: an old AVI often drops to a fraction of its size, and iPhone MOV footage frequently comes out smaller too — converting MOV to MP4 in your browser handles that case, HEVC included, with nothing uploaded anywhere.
Two codec notes worth knowing:
- Already-efficient files gain little here. Re-encoding an H.264 MP4 to H.264 again saves only what the quality slider takes; the codec lever is spent.
- For web embeds specifically, VP9 often edges out H.264 at web resolutions — converting MP4 to WebM can trim a hero/background video further, with the compatibility trade-offs covered in MP4 vs WebM vs MOV.
Lever 4: The Quality Setting (CRF, Explained in One Paragraph)
Modern encoders don’t ask for a bitrate; they ask for a quality target. FFmpeg’s H.264 encoder calls it CRF (Constant Rate Factor): a 0–51 scale where lower means better, 18 is visually lossless for most content, and 23 is the default. The encoder then spends bits wherever the picture needs them — more on complex motion, fewer on static shots. Browser-based converter tools expose the same control as a 0–100 quality slider (higher = better) alongside resolution presets, so you’re setting CRF whether the UI says so or not.
The useful property: quality-vs-size is very non-linear. The first chunk of compression is nearly invisible; the damage arrives at the aggressive end. In slider terms:
- 85–100 — visually lossless territory; large files. For masters and footage headed into an edit.
- 70–85 — the sweet spot. Halves many files with no difference you’ll spot at normal viewing. High-bitrate OBS recordings usually land here happily.
- 50–70 — visible softening on fine detail; acceptable for previews and drafts.
- Below 50 — blocky motion, smeared text. For when the size limit is the only thing that matters.
Start at 80. If the file’s still too big, drop by 5 and re-check — don’t start at 50 “to be safe.” And never compress in repeated passes: each lossy re-encode stacks generation loss, so go back to the best source you have and compress once with the settings you actually need.
Lever 5: If It’s a GIF, Stop Everything
The single biggest file-size win in any media workflow isn’t a setting — it’s escaping the GIF format. GIF stores every frame as a full image with zero motion compression, so converting a GIF to MP4 typically shrinks it by 90–95% at default settings, no quality slider heroics required. An 8 MB GIF becomes a few hundred kilobytes that plays more smoothly and in better color.
On a web page, a muted looping autoplay <video> tag behaves identically to the GIF it replaces. The full decision logic — including the cases where GIF genuinely earns its bulk — is in GIF vs MP4: Which Is Better for Short Animations?
Putting It Together: The Cheat Sheet
| Scenario | Do this | Expect |
|---|---|---|
| OBS/screen recording to share | Trim, keep resolution, quality ~75 | 50–70% smaller |
| iPhone 4K clip for chat/email | Trim, 1080p, quality 80, MOV → MP4 | 70–85% smaller |
| Old AVI/camera archive | Re-encode to H.264 MP4, quality 80+ | Often 60–80% smaller |
| GIF over 2 MB | Convert to MP4 | 90–95% smaller |
| Hero video on your website | 720p, WebM (or MP4), quality 70–75 | Small enough to autoplay politely |
| Master/archive copy | Don’t compress it — store it and compress copies | — |
What Not to Do
- Don’t zip video. H.264 output is already near-maximum entropy; a zip saves ~1% and adds a step.
- Don’t compress the master. Keep one high-quality original; make small versions per destination. Storage is cheaper than re-shooting.
- Don’t upscale-then-compress. Resolution only ever spends bits; it never adds detail.
- Don’t re-compress a re-compression. Generation loss compounds — always return to the source.
Every conversion mentioned here — MOV, WebM, GIF, plus MKV, AVI, and the audio extractors — runs in the browser via the free converter tools: the trim fields, resolution presets, and quality slider are the levers from this guide in UI form, and files never leave your device. For codec choices specific to motion graphics work — alpha channels, editing masters, archival — the deeper dive is Best Codec for Motion Graphics: H.264 vs ProRes vs WebM.
