Video Compressor: How to Shrink a Video File Without Wrecking It
A video compressor is not one button. It is a trade between three numbers that pull against each other: how the file looks, how many bytes it takes, and how long the encode runs. Set two and the third is decided for you. Most "compress this video" pages hide the trade and pick for you. The one in this guide shows all three and runs entirely in the browser, on your own machine, so nothing is uploaded while you experiment.
Here is the practical part first. If you only want a smaller file and do not want to learn the vocabulary, drop your clip in, click Balanced, and encode. Everything after that is for the cases where Balanced is not right: a file that must fit under a mail limit, an archive copy that must stay clean, or a web embed that has to start fast.
What actually makes a video file smaller
Compression takes advantage of two kinds of repetition.
The first is between frames. Frame 240 and frame 241 of a talking-head video are nearly identical. Instead of storing both as complete pictures, the encoder stores a full keyframe now and then, and in between it records only what moved and which small corrections are needed. That is inter-frame compression, and it is where the bulk of the saving comes from.
The second is inside a single frame. Fine texture in grass, film grain, subtle gradients in a dark room: the eye does not need every bit of that. The encoder throws some away, and how aggressively it does so is exactly what the quality setting controls.
Everything else in a compressor, resolution, frame rate, audio bitrate, is a way of throwing away something you can name. Quality settings throw away something you cannot easily name, which is why they are the hard part.
CRF versus bitrate: pick one and understand why
Two families of rate control exist, and confusing them is the most common reason people end up with a file that is either far too big or visibly broken.
Constant bitrate spends a fixed number of bits per second whether the scene needs them or not. A still shot of a whiteboard is over-served, a fast drone pan is starved. The file size is predictable; the look is not.
Constant quality, called CRF in FFmpeg and in this tool, does the opposite. You set how much detail the encoder is allowed to discard, and the bitrate lands wherever the footage demands. A screencast at CRF 28 comes out tiny. A snowboarding clip at CRF 28 comes out much larger, and both look correct for their content.
| Setting | What it fixes | File size | Best for |
|---|---|---|---|
| CRF 18 | Almost nothing visible is lost | Large | Masters, archives, footage you will edit again |
| CRF 20 to 23 | Grain and fine texture survive | Medium | YouTube uploads, client review copies |
| CRF 26 to 28 | Detail in motion softens | Small | Web pages, chat apps, email |
| CRF 30 to 34 | Surfaces go smooth, banding appears | Very small | Slide decks, screen recordings |
| Target size in MB | The exact byte budget | Predictable | Upload forms with a hard limit |
| Percentage of original | A proportional cut | Proportional | "Make it half the size" requests |
A change of six CRF points roughly halves or doubles the bitrate. That single rule is enough to navigate the scale: if the output is too large, add six, if it looks soft, subtract three or four and compare again.
Which codec: H.264, H.265, VP9 or AV1
The codec is the algorithm that does the compression. The extension on the file says nothing about it: an MP4 can hold H.264, H.265 or AV1 and look completely different at the same size.
H.264 is the safe default. Every browser, phone, television and video editor made in the last fifteen years plays it, and it encodes faster than anything else here. Its weakness is efficiency: it needs roughly twice the bits of H.265 for the same visible quality.
H.265, also called HEVC, halves the bitrate at the same quality, especially above 1080p. The catch is compatibility and time. Some browsers and many older Android devices cannot decode it, and the encoder is noticeably slower because it searches a larger space of prediction options.
VP9 is Google's royalty-free codec and the one YouTube has leaned on for years. Quality per bit is close to H.265, playback is solid in Chrome, Firefox, Edge and Safari 14 and later, and it belongs in a WebM or MKV file.
AV1 is the newest of the four and the most efficient, typically thirty percent better than H.265 at the same quality. It is also the slowest to encode, which matters when the encoder is running in WebAssembly on one CPU core.
| Codec | Size at equal quality | Encode speed | Plays on |
|---|---|---|---|
| H.264 | Baseline | Fast | Everything |
| H.265 | About 50% of H.264 | Moderate | Apple devices, most 4K TVs, recent GPUs |
| VP9 | Close to H.265 | Moderate to slow | Chrome, Firefox, Edge, Safari 14+ |
| AV1 | About 30% below H.265 | Slow | Recent Chrome, Firefox, Edge, Safari 17+ |
The compressor restricts the pairs that make sense: MP4 takes H.264, H.265 or AV1; MOV takes H.264 or H.265; WebM takes VP9 or AV1; MKV takes H.264, H.265 or VP9. A WebM holding H.264 would be a file that players refuse, so the option is not offered.
Where the biggest savings usually are
Before touching CRF, check the three settings that give away bytes for free.
Resolution. Halving the frame size quarters the number of pixels, and the encoder spends bits per pixel. A 4K clip at 1080p is a quarter of the work and usually looks identical on a phone or a laptop screen. The tool offers 144, 240, 360, 480, 720, 1080, 1440, 2160 and 4320 pixel heights plus a custom width, and it will not upscale a source that is already small.
Frame rate. Thirty frames per second instead of sixty halves the frames to encode. For talking heads and screen recordings the difference is invisible; for sports it is not.
Trim. Two minutes of dead time at the head and tail cost exactly as many bytes as the content you want. Trim first, compress second, and the savings add up rather than compete.
Audio is the fourth lever and the smallest. A 128 kbit/s AAC track is about 1 MB per minute, so on a heavily compressed video the audio can quietly become a large share of the file. Dropping to 96 kbit/s mono, or removing audio entirely for a silent web background, is often the last few percent that gets a file under a limit.
A repeatable workflow
Start by deciding what the file is for, because that decides the target.
For email, aim at 20 MB. Use MP4 with H.264, CRF 26 to 28, 720p, 30 fps, and 96 kbit/s audio. A two minute clip usually lands between 8 and 15 MB.
For a social upload, use MP4 with H.264 at 1080p and CRF 22. Platforms re-encode everything, so send them a clean source at the resolution they want rather than a huge file that gets flattened twice.
For a web embed, use WebM with VP9 or AV1 at 720p and CRF 32. The first frame matters more than the last bit of detail, and both codecs start playing sooner at a lower bitrate.
For an archive, use MKV or MP4 with H.265 at CRF 20 and keep the original resolution. The point is to save space without deciding later that the copy is not good enough.
For a fixed budget, switch to target size and enter the number. The tool estimates the outcome before it starts and shows the estimate in the queue, so a wrong guess costs seconds, not minutes.
Batching is where the tool earns its place: five files per run, 500 MB in total, one settings panel for all of them, and a single zip at the end. Compressing twelve screen recordings one at a time through a site that uploads each file is a very different afternoon.
Subtitles, trimming and the rest
Two options sit outside the quality discussion and are worth knowing about.
Trim sets a start and an end time, and only that range is encoded. If the source has a title card and a slow fade at the end, cutting both saves as much as dropping six CRF points.
Subtitles can be handled in two ways. Burning them into the picture means every player shows them and no viewer can turn them off, which is what short social clips want. Copying the track keeps them as a separate stream inside an MP4 or MKV, which lets a player toggle them but requires a player that supports it.
Why on-device encoding changes the math
Cloud compressors upload the file, queue it, encode it on a server, and send it back. That is fine for a five second clip and painful for a 500 MB one, especially on a connection with a slow upstream. It also means your footage sits on someone else's disk for as long as their retention policy says.
A browser compressor replaces that round trip with a WebAssembly build of FFmpeg loaded by the page. The file is read locally, encoded on your CPU, and offered back as a download from memory. There is no upload, no queue behind other users, and no copy left behind.
The cost is memory. A large 4K source has to fit in the tab, and phones with little free RAM will struggle where a desktop does not. Five files and 500 MB in total is a sensible ceiling for that reason, not an arbitrary one.
Frequently Asked Questions
Does the video compressor upload anything?
No. The page reads the file with a local file input and encodes it with WebAssembly on your device. Nothing is sent to a server and nothing is stored, so the tool is usable on client footage that cannot leave the machine.
Why is my H.265 file larger than the H.264 one?
Two reasons are common. The source was already an efficient H.264 encode, so re-encoding adds a generation with little to gain. And CRF numbers are not comparable across codecs: CRF 28 in H.265 is not CRF 28 in H.264, so a low value can spend more bits than the original had.
Can I compress a video on a phone?
Yes, the page works in a mobile browser, and the same settings are available. Expect slower encodes and lower limits on how large a source will fit, since the tab needs the whole file in memory.
What happens to MPEG-TS files from a camcorder?
They are refused with an explicit message rather than queued, because the browser build of FFmpeg cannot reliably demux that container. A clear refusal beats a queue entry that hangs. Convert the clip once with a desktop tool, then compress it here.
Does re-encoding always lose quality?
Every encode loses something, but a well-chosen CRF keeps the loss below what a viewer notices on a phone or a laptop. Repeated re-encoding is the real danger: three generations of CRF 28 look worse than one of CRF 22 at the same size, so work from the best source and encode once.
How do I hit a hard size limit exactly?
Use target size and enter the limit in megabytes. The encoder calculates a bitrate from the duration and spends that budget, landing within a few percent on normal footage. If the file must be under the limit with no margin, aim slightly lower and confirm the download size.
Can I compress several videos at once?
Up to five files per batch, 500 MB in total, processed one after another in the same tab. Results can be downloaded individually or as one zip archive.
Which container should I keep?
MP4 if the file leaves your machine, since it plays everywhere. WebM for a web page, MKV for keeping subtitle tracks without fuss, MOV only when an Apple workflow expects it.
The short version
Set the codec by where the file is going, set the quality by what you can afford to lose, and cut the resolution and the dead time before you touch either. A video compressor is a budget tool: the work is deciding which budget matters, and the rest is arithmetic the encoder can do faster than you.
Australia · SO reputation 2000 · Badges: 0🥇14🥈13🥉 · SO member since 2012