Video compression FAQ

No. Your video is processed entirely inside your browser using WebAssembly. It never leaves your device and is never sent to any server. We do not collect, store, or see any of your files.

There are no accounts, no record of any file you compress, and no cookies set by this site. Page views are counted by a cookieless analytics service I host myself, which sees the URL, the referrer, an approximate country and your browser class — and nothing at all about your video. The privacy page sets out exactly what that does and does not include.

Yes. Because everything happens locally in your browser, it is safe to use on confidential videos — corporate recordings, personal content, anything. The data never travels over the network.

It depends on the quality slider. The default (balanced) targets roughly 56% of the original bitrate — for most content that is hard to notice. Move the slider left to keep more quality, right to shrink the file further. The tool always targets a bitrate below the original, so the output is always smaller.

It controls what fraction of the original bitrate the encoder targets. At the gentlest position (~78% of the input bitrate) the result is close to the source and only modestly smaller. At maximum compression (~20% of the input bitrate) the file gets very small but visible quality loss is likely, especially on high-motion content. The tool shows the figure it will aim for, and roughly what it lands at, before you start the encode.

"Best compression" runs the codec you picked at its fastest usable settings and reliably shrinks any source. "Fast compress" swaps in the MPEG-4 encoder when the codec is H.264, which finishes sooner and compresses less well — a reasonable trade on non-H.264 sources like old AVI or MOV files. With H.265 or VP9 selected there is no MPEG-4 shortcut to take, so fast mode only loosens the speed settings of that encoder.

Choose "Target size" and type a ceiling in megabytes. The tool reads the length of your clip, divides the byte budget by it, subtracts an audio allowance and encodes to the bitrate that falls out. It then measures the finished file, and if the encoder overshot it scales the bitrate by exactly how far over it landed and runs again, up to three passes. Presets for the common ceilings are on the /compress-to/ pages.

Use a target size when something will reject your file above a specific number — an attachment limit, an upload form, a chat platform. Use the quality slider when you just want the file smaller and have no hard ceiling, because it targets a fraction of your source bitrate and therefore adapts to how much slack the source actually has.

Because the arithmetic needs a known number to subtract. A copied audio track has whatever bitrate it arrived with, which the tool cannot see reliably, so the budget could not be split correctly. Target mode re-encodes audio at 64, 96 or 128 kbps depending on how tight the overall budget is.

Only if you specifically need a smaller resolution. Dropping from 1080p to 720p cuts video data by about 56%. If your goal is just a smaller file at the same resolution, the quality slider is usually enough.

There is no hard cap, but your browser must hold the entire file in RAM. Devices with 8GB+ of RAM generally handle files up to 2–4GB without issues. The tool shows a warning for files over 1GB. Very large files may cause the tab to run out of memory.

The first time you use the tool, your browser downloads approximately 30MB of the FFmpeg WebAssembly binary. This is cached by the browser, so all subsequent compressions start immediately.

Video encoding is computationally intensive. WebAssembly is fast, but it is still running on your CPU via JavaScript. Longer videos, higher resolutions, and slower presets all increase encoding time. For a typical 10-minute 1080p video, expect 2–10 minutes depending on your device.

FFmpeg supports virtually every video format in existence. You can upload MP4, MKV, MOV, WebM, AVI, WMV, FLV, and more. If your browser can read the file, FFmpeg can usually process it.

You can compress to MP4, MKV, WebM or MOV. Each container offers the codecs it can legally hold: H.264 or H.265 in MP4 and MOV, VP9 in WebM, all three in MKV. Audio is AAC everywhere except WebM, which takes Opus. MP4 with H.264 is the most universally compatible and is the one to send to other people. There is no AV1 encoder in the build.

H.264 unless you have a reason. H.265 lands roughly a third smaller at the same quality, but it takes several times longer to encode in WebAssembly and older phones, TVs and browsers will show you a black frame instead of a video. VP9 is the only thing WebM accepts, and it is likewise slow here and unreadable to MP4-only players. Both are worth it when the file is for you and your own hardware; neither is worth it when someone else has to open it.

Remux copies the video stream without touching it, and WebM only accepts VP8, VP9 or AV1. An H.264 stream copied out of an MP4 has nowhere to go inside a WebM, so the muxer would fail rather than produce a file. Pick MKV if you want the stream kept as-is in a different wrapper, or re-encode to VP9 if you specifically need WebM.

Yes. By choosing a different output format from your input, you are effectively converting. For example, you can upload an MKV and download an MP4.