Free Online Video Compressor

Video files are the heaviest content most people work with on a computer. A two-minute phone clip easily weighs fifty megabytes; a screen recording of a short meeting can pass one gigabyte in the time it takes to get a coffee. That size is fine when the footage lives on an SD card, but it becomes a real problem the moment you need to email it, upload it to a CMS with a strict file-size limit, drop it into a chat app that caps attachments at twenty-five megabytes, or send it to a collaborator on a slow connection. Compressing before sending is the universal answer, and for years the only realistic options were desktop apps like HandBrake or paid cloud services that asked you to upload your video to their servers.

This tool removes that trade-off. It runs ffmpeg.wasm — a WebAssembly build of the same ffmpeg library that powers HandBrake, VLC, YouTube's ingest pipeline and most professional video workflows — directly in your browser. When you pick a file, it is read from local disk into browser memory, handed to the ffmpeg engine, encoded to a new MP4, and written back to local disk when you click download. No byte of your video ever touches a server. No account is required. There is no upload progress bar because there is no upload. The only network traffic is the one-time fetch of the ffmpeg core binary (a few megabytes) when you first open the page; after that, the compressor works even if you disconnect from the internet.

The compression presets map to the same CRF values professional editors use. Small file uses CRF 32 and produces the smallest output, typically four to seven times smaller than the original, with a visible but acceptable quality drop that is fine for social media clips, chat attachments, and email. Balanced uses CRF 28, the quality most YouTube uploads sit at, reducing size roughly two to four times with a drop most viewers cannot detect on a phone screen. High quality uses CRF 23, which is the default in professional tooling and typically reduces size one and a half to two times while keeping output visually identical to the source on a desktop monitor. In every case the encoder is libx264 with the veryfast preset, which strikes the right balance between speed and compression efficiency for browser-based encoding.

Resolution control is the other major lever. Most footage captured today is 1080p or higher, but a large fraction of playback happens on phone screens where the difference between 1080p and 720p is invisible and the file-size saving is substantial. Dropping from 1080p to 720p alone typically halves the file size before CRF even kicks in; going to 480p quarters it. The tool uses a scale filter that preserves the aspect ratio automatically and forces even pixel dimensions so the H.264 encoder does not complain. If you want to keep the native resolution — useful for archival or for large screens — pick Keep original and let the CRF preset do the size reduction.

Two optional features cover common real-world needs. Remove audio strips the audio track entirely, which is the right choice when you are sharing a screen recording for visual reference, a silent product demo, or a tutorial that will receive a voice-over later. Removing audio saves a predictable extra ten to fifteen percent on file size depending on the original bitrate. Trim video lets you cut the clip to a sub-range by entering a start second and an end second. Trimming happens inside the same ffmpeg pass, so there is no quality loss from a second re-encoding, and trimming a long recording down to the relevant thirty seconds is usually the single biggest size reduction you can make.

The privacy angle is the main reason many users pick a browser-based tool over a cloud service. Videos often carry sensitive context: a screen recording might include a dashboard with customer data; a phone clip might show a face, a license plate, a handwritten password on a whiteboard, a private location. Uploading that to a third-party server introduces every classic cloud risk — retention in logs, caching on CDN edges, employee access, data-breach exposure, and cross-border data transfer problems under GDPR or similar laws. A browser-based compressor has none of those attack surfaces. The footage is present only on your machine, and the only outbound request is a static binary fetch from a CDN. If you are on a corporate laptop behind a proxy that blocks outbound file uploads, this tool will still work the same way it does on a home network.

Performance depends almost entirely on the device you use. On a modern laptop with at least eight gigabytes of RAM, a two-minute 1080p clip compresses in roughly one to three minutes — slower than a native desktop ffmpeg but fast enough for everyday use. On older machines or phones, the same clip can take five to ten minutes. This is the price of running a full H.264 encoder in WebAssembly inside a browser sandbox instead of native code on the CPU's vector units. For clips beyond ten minutes or files above five hundred megabytes, it is usually more pragmatic to trim first and compress the relevant portion; the tool shows a warning when a file is large enough to risk running out of memory. The hard limit is two gigabytes, above which the browser simply cannot allocate enough memory to decode the input.

There is a frequent confusion worth clearing up: compression is not the same as format conversion. This tool always produces MP4 with H.264 video and AAC audio, which is the universal format every device, social platform, and editing app accepts natively. If your source is already MP4, the tool re-encodes it with the settings you picked; if your source is MOV, WEBM, MKV or AVI, the tool transcodes it into an MP4 along the way. Either path produces a file that works everywhere. If you simply want to change the container without re-encoding (for example to repackage a MKV into an MP4 while keeping the same bytes), a separate remuxing tool is a better fit; compressing always involves a re-encode and therefore always takes time.

Browser compatibility is broad but not universal. The engine works on Chrome, Edge, Firefox, and Safari in recent versions, on both desktop and mobile. Very old browsers without WebAssembly support — essentially Internet Explorer and ancient Android System WebView versions — cannot run the tool at all. On mobile browsers, compressing short clips of up to about a minute is comfortable; longer clips sometimes trigger memory pressure and cause the tab to reload. The safest mobile workflow is to trim first, then compress, and Omnvert's trimming tool in the Audio category can help prepare the clip before you bring it into this compressor.

This tool pairs well with the other Omnvert media utilities. After compressing, you can run the output through the [EXIF Remover](/tools/exif-remover) if the source was a phone recording and you want to scrub any embedded location metadata before sharing. If you only need the audio from the video — for example to extract a podcast or voice note — the MP4 to MP3 converter is the right next step. For batch workflows where you need to combine several clips into one file before compressing, the audio/video merger handles concatenation, and you can then bring the merged file here to compress the result. All of these tools follow the same browser-only privacy model, so an entire video preparation workflow can happen in a single tab without a single file touching a server.

A final practical tip about file-size expectations. MP4 compression is a three-way trade-off between resolution, bitrate (controlled by CRF), and duration — you can only substantially reduce two at a time. A fifteen-minute 4K drone shot will still be large after compression even at CRF 32 simply because of the duration; a ten-second 1080p clip will compress to almost nothing at CRF 32 because there is very little data to preserve. The presets in this tool give you sensible starting points, but if the result is still too large, the next lever in order of effectiveness is: shorten with the trim feature, drop resolution one step, then move to a smaller preset. Going the other way — if quality is more important than size — increase to High quality, keep original resolution, and the tool will still produce meaningful savings on almost any source by removing redundant data that the original camera encoder left in place.