Video Compressor
This free online video compressor shrinks MP4, MOV, WebM, AVI and MKV files by up to 90% without uploading them anywhere. Pick a quality level or a target file size, cap the resolution, and download a universally compatible MP4. Everything runs on your own device, so your videos stay private.
Compression settings
Lower keeps more detail and makes a bigger file.
Bitrate is calculated from this and the clip length.
Lowering this is the single biggest speed win.
Done
Nothing is uploaded. The whole compression runs inside your browser using ffmpeg compiled to WebAssembly. Your video never leaves your device, which is also why the first run downloads about 32 MB of engine. That is cached afterwards.
Why there is a size limit. WebAssembly has a fixed memory ceiling of roughly 2 GB, and ffmpeg needs the input, the output and its working buffers to fit inside it at once. Past a few hundred megabytes it will run out of memory partway through, so we say no up front rather than wasting ten minutes of your time first.
Keep this tab visible while it runs. Browsers aggressively throttle background tabs, which can slow an encode to a crawl or stall it. The encode itself runs on a background worker, so the page stays responsive and Cancel works instantly.
How this video compressor re-encodes with real x264, and why it rebuilds its engine after every run
This tool does not trim quality by simply lowering resolution and calling it done. It runs an actual H.264 encode through libx264, the same open source encoder behind most desktop video software, compiled to WebAssembly as ffmpeg.wasm and executed inside a Web Worker in your browser. Nothing is uploaded. The video file is read locally, written into FFmpeg’s virtual filesystem, encoded there, and handed back as a downloadable blob.
The library loads dynamically at runtime rather than through a page <script> tag, and it deliberately picks the single-thread FFmpeg core over the faster multithreaded one, because the multithreaded core needs SharedArrayBuffer, which browsers only expose on pages sent with COOP and COEP cross-origin isolation headers. Most ordinary web pages, including this one, don’t send those, so the single-thread core is the one that actually runs everywhere. If the page happens to be cross-origin isolated, the tool detects window.crossOriginIsolated and upgrades to the multithreaded core automatically.
Two compression strategies, one encoder
-crf.
-b:v with a matching -maxrate and -bufsize to keep the encoder from overshooting.
Every job also runs -preset veryfast, x264’s speed-versus-compression tradeoff dial, and -pix_fmt yuv420p, which is not a quality setting but a compatibility one: it forces standard 4:2:0 chroma subsampling so the output plays correctly in every mainstream video player and browser, since some source footage uses pixel formats that not every decoder understands. Audio, when kept, is re-encoded to AAC at 96 kbps. The optional resolution cap uses an FFmpeg scale filter written as scale=-2:min(H,ih), which only ever shrinks the video, never enlarges it above its source resolution.
| Setting | FFmpeg flag | What it actually does |
|---|---|---|
| Quality (CRF mode) | -crf | Lower number, higher quality, larger file; 18 to 40 range exposed here |
| Target size | -b:v, -maxrate, -bufsize | Backs into a bitrate that should land near your MB target |
| Resolution cap | scale=-2:min(H,ih) | Never upscales, only limits the taller dimension |
| Cap frame rate at 30 | fps=min(30,source_fps) | Leaves footage already at or under 30fps untouched |
| Mute | -an | Strips the audio track entirely instead of re-encoding it |
| Fast start | -movflags +faststart | Moves the MP4 index to the front of the file so it can start playing before it fully downloads |
Where compression stops helping
Compression has a floor
If your source file is already efficiently encoded, running it through again can produce a similar or even larger file, since you’re re-encoding already-compressed data. The tool checks the size delta after each job and surfaces a warning if the output isn’t actually smaller, rather than silently handing you a bigger file.
Large files can exhaust browser memory
Because the whole video is loaded into an in-browser virtual filesystem rather than streamed from disk the way a desktop encoder would, very large source files (past roughly 500MB) risk hitting the tab’s memory ceiling. The tool flags large uploads before you start and reports an out-of-memory condition plainly if the encode fails for that reason.
Video codec references
- x264 project page, the open source H.264 encoder doing the actual compression work inside FFmpeg.
- FFmpeg’s H.264 encoding guide, explaining CRF, presets and the quality-versus-size tradeoffs this tool exposes as sliders.
- ffmpeg.wasm documentation, the WebAssembly build of FFmpeg powering this tool’s browser-side encoder.
- MDN on crossOriginIsolated, the flag this tool checks to decide between the single-thread and multithreaded FFmpeg core.
Size limits people run into
Shrinking a phone recording below an email attachment limit, getting a screen capture under a platform’s upload cap, preparing footage for a slower connection or a limited storage device, and hitting an exact file size ceiling for a forum or ticketing system that rejects anything larger. The target size mode in particular is built for that last case, where merely smaller is not good enough and you need to land under a specific number.
FAQ: Video Compressor
Drop your video into the tool above, pick a quality level or target size, and click Compress Video. The compression runs entirely inside your browser using FFmpeg compiled to WebAssembly, so the file never leaves your device. When it finishes, you preview the result and download the compressed MP4 directly.
That download is the FFmpeg engine itself, the same video processing software used across the industry, packaged to run in a browser. It downloads once, your browser caches it, and every later compression starts instantly. It is the trade that makes fully private, no upload compression possible.
MP4, MOV, WebM, AVI and MKV inputs all work. The output is always MP4 with the H.264 video codec and AAC audio, the most widely compatible combination there is — it plays on every phone, browser, TV and editing app.
Some quality is always traded for size, but at balanced settings the difference is hard to spot. The quality slider uses CRF encoding, which spends data where your eyes need it most. For the smallest visible impact, keep the slider in the Near lossless to High range and avoid dropping resolution. For maximum savings, 720p at Balanced quality typically cuts files by 60 to 90 percent.
Switch Mode to Target file size and type the megabytes you need, for example 25 for Discord or 16 for WhatsApp. The tool calculates the exact bitrate that fits your video’s duration into that size and encodes to match. Long videos squeezed into small targets will look soft — lowering the resolution at the same time helps a lot.
Browser memory is the practical limit, roughly 2 GB of working space. Files up to about 500 MB compress reliably; beyond that, success depends on your device’s RAM. For very large files, trim the video first or compress it in parts. Processing runs at roughly real-time speed, so a 10 minute video takes around 10 minutes — keep the tab open while it works.
Yes, on modern mobile browsers like Chrome, Safari and Firefox. Phones have less memory and slower processors than laptops, so stick to shorter clips and expect longer processing times. If a large file fails on mobile, try the same file on a desktop browser.
From the blog
Format guides and gotchas
What each format stores, and what quietly disappears in conversion.
