“Lossless” compression is mostly a myth for video. What’s actually achievable is compression where the quality loss is invisible to the viewer. That’s a realistic goal, and it’s mostly about matching the right settings to the content.
First: understand what “quality” actually means
Quality is not a single number. It depends on:
- Bitrate relative to resolution — a 1Mbps 480p video looks fine; a 1Mbps 4K video looks terrible
- Content type — talking heads compress far better than action scenes or film grain
- Viewing context — a video on a 5-inch phone screen can get away with far less bitrate than the same video on a 55-inch TV
The techniques below reduce file size by working within these variables.
Use the right CRF
CRF 23 is x264’s default, and it is a good starting point — but the right value depends entirely on what is in the frame. (If CRF and bitrate are new to you, start here.) Rough starting points by content type:
- Animated content: CRF 20–22 often sufficient (low noise = easy to compress)
- Talking heads, slide decks and screen recordings with no small text: CRF 24–26 often fine
- Screen recordings with code or spreadsheets in them: CRF 20–23
- Film grain, sports, high motion: CRF 18–21 needed for acceptable quality
- Archival storage: CRF 17–19
Test by encoding a short clip at CRF 22 and CRF 26, then compare at 100% zoom on your target display. The difference is often invisible at 26.
Strip unnecessary audio channels
Many videos — especially screen recordings and conference calls — carry stereo audio with identical content in both channels. Compressing or downmixing that track removes data you were never going to hear. Use the audio setting in the browser video compressor: compress it to a lower bitrate, or strip it entirely if the video does not need sound.
Reduce resolution only when it fits your use case
1280×720 is 921,600 pixels against 1920×1080’s 2,073,600 — about 56% fewer. File size does not fall by exactly that ratio (a downscaled frame is also easier for the encoder to predict, so the saving is usually larger), but pixel count is the right first approximation.
Do this only if the video will be viewed at a size where 720p is sufficient, and you still have the original to re-encode from if needed. Never reduce resolution on footage you plan to edit later.
Cut before you compress
Trim your video before compressing it. Every second of unused footage wastes bits. If your 30-minute recording has 10 minutes of useful content, the other 20 are consuming bitrate that the part you care about could have had.
A straight top-and-tail does not need an editor. The compressor on this site will cut the front and the back for you as part of the encode, and every size calculation downstream runs on the length you kept rather than the length you started with. An editor is still the answer when the part to remove is in the middle, or when two separate moments have to be joined, because one range cannot express either.
Choose the right codec for the destination
| Destination | Codec | Why |
|---|---|---|
| Web embedding | VP9 (WebM) | Newer generation than H.264; generally reaches the same quality at a lower bitrate |
| Email / messaging | H.264 (MP4) | Universal compatibility — the safe default |
| Apple devices | H.264 (MP4) | Native support everywhere |
| Long-term archive | H.265 (HEVC) | Better compression than H.264, at the cost of narrower playback support |
How much a newer codec actually saves you is content-dependent and heavily disputed between published comparisons, so treat “more efficient” as a direction rather than a percentage. The reliable way to know is to encode the same 30-second clip both ways and compare the two file sizes yourself.
If your video is going on a web page and your audience is on modern browsers, WebM with VP9 is worth trying, and you can produce it here by setting the output container to WebM. Budget for the wait: libvpx-vp9 in WebAssembly is a good deal slower than x264, and on anything long the difference is obvious. More on containers and codecs here.
Use a slower encoder preset
The preset controls how hard the encoder works to find efficient compression. It does not change the target quality — it changes how much effort is spent reaching it, so a slower preset produces a smaller file at the same CRF, purely by taking longer.
x264’s presets, from fastest to slowest: ultrafast, superfast, veryfast, faster, fast, medium (the default), slow, slower, veryslow, placebo. Each step down costs meaningfully more encoding time and buys a smaller file at the same visual quality, with diminishing returns at the slow end — FFmpeg’s own guide advises using the slowest preset you have patience for, and explicitly warns off placebo.
For a one-off export where you will wait anyway, stepping down a couple of presets is usually worth it. In a browser-based encoder the calculus is different: encoding is already slower there, so this site uses a fast preset and leans on bitrate targeting instead. That is also why picking H.265 or VP9 here buys you less than the codec comparison charts suggest — those charts assume presets nobody can afford to run in a tab.
Example workflow
Scenario: 45-minute interview, 1080p, 12GB source. Target: under 500MB for web embedding.
- Trim dead air at start and end (assume 40 minutes remain)
- Format: WebM (VP9), since it is going on a web page — expect the encode to take a while
- Resolution: 720p — a seated talking head does not need 1080p
- CRF: 26
- Audio: compressed, voice only
- Preset: as slow as you are willing to wait for
Work the budget rather than guessing at the result: 500 MB over 40 minutes is 500 × 8 × 1024 / 2400 ≈ 1,700 kbps for everything, so roughly 1,600 kbps for video after audio. That is a comfortable figure for 720p talking-head footage, which is what tells you this target is achievable before you start. Encode two minutes first, check the size, and scale up.
Most of that workflow maps onto the browser compressor here: trim, resolution, container, codec, audio and a 500 MB ceiling in target-size mode, none of it uploaded anywhere. The two it does not give you are CRF and the preset, which are fixed at fast settings so a tab stays usable. If you want those dials, that is a job for FFmpeg.
Keep reading
- What is video bitrate and why does it matter? — the foundation for everything above.
- How to compress video for the web — settings for embedded and shared video.
- Shrink a video to a target file size — when you have a hard limit to hit.
- Why are iPhone videos so big? — the most common source of a file that needs this treatment.
- Compress to a target size — when the limit is a number rather than a preference.
Sources
- FFmpeg H.264 encoding guide — CRF, presets and the advice on choosing the slowest one you can tolerate.
- FFmpeg VP9 encoding guide — VP9 rate control and encoding speed.
- MDN: web video codec guide — codec support and trade-offs across browsers.