Supported video formats: MP4, MOV, MKV, WebM and AVI

Container and codec are not the same thing

This is the confusion behind most format questions, and it takes one paragraph to clear up.

The container is the file format — the extension you see. MP4, MOV, MKV, WebM and AVI are containers. A container's job is to hold streams, index them, and record how they line up in time. It does not compress anything.

The codec is what actually compresses the picture and the sound. H.264, HEVC, VP8, VP9 and AV1 are video codecs; AAC, Opus, MP3 and Vorbis are audio codecs.

One container can hold many different codecs, which is why "it's an MP4" tells you much less than people assume. Two MP4 files can be internally completely different. It is also why changing the extension by renaming the file never works: the bytes inside are still laid out for the old container.

The practical consequence here: the container you open barely affects anything, because FFmpeg demuxes them all. The container you export to matters, because it constrains which codecs can be written into it.

Formats you can open

Because the engine is FFmpeg rather than a hand-written parser, this list is a description of what is tested rather than a hard whitelist — most other containers FFmpeg can demux will open too. The one thing that is genuinely limited is the preview, which is discussed below.

Formats you can export, and which to choose

Notice that three of the four options produce the same encode. If you are choosing between MP4, MOV and MKV you are choosing a wrapper, not a quality level. WebM is the only genuinely different output, and it is the only one with a real cost attached.

If changing the container is the whole job, you do not need to add an edit: the converter pages go through each pair — MOV, MKV, WebM or AVI to MP4, and MP4 to WebM or MOV — and the editor's apply button becomes "Convert video" as soon as you pick a different output format.

What the encoder actually writes

For MP4, MOV and MKV the video is encoded with libx264 at the ultrafast preset with CRF 28, and the audio with AAC. Both settings are chosen for the fact that the encoder is running on your CPU inside a browser tab rather than on a rented machine: ultrafast spends bits to save time. One consequence worth expecting is that the output is sometimes larger than the input even though the video got shorter.

MP4 and MOV are written with +frag_keyframe+empty_moov, which produces a fragmented file. This is what lets FFmpeg write the output straight through without seeking back to patch a header afterwards — necessary when the "filesystem" is a block of memory inside a browser tab. Fragmented MP4 plays in browsers, on phones, on modern TVs and in current editors; very old software occasionally does not like it.

WebM is encoded with libvpx (VP8) targeting roughly 1 Mbps, with Opus audio, using a realtime deadline. VP9 would compress better, but the VP9 encoder in this WebAssembly build is not stable at usable speeds, so VP8 is the deliberate choice. This is the honest reason to prefer MP4 unless WebM is a requirement.

There is also a max-resolution control that applies a scale filter to cap the output at 1080p, 720p or 480p. It only ever scales down — a 480p source is never upscaled — and it is by far the most effective way to make a long clip encode faster and land smaller.

Why some files open but will not preview

The scrubbable player above the timeline is your browser's own <video> element, and browsers support a much narrower set of containers and codecs than FFmpeg does. In practice MP4, MOV and WebM preview reliably; MKV and AVI often do not.

This is a display limitation, not an editing one. FFmpeg decodes the file correctly either way, so the cut or speed change is applied exactly as specified — you are simply positioning it with the timeline and the numeric start and end fields rather than by eye. If you plan to do fine work on an MKV or AVI, one practical approach is to export it to MP4 first with no edits, then reopen that copy with a working preview.

Screen recordings and variable frame rate

Screen recorders and phone screen capture frequently produce variable frame rate video: instead of a steady 30 frames every second, frames are written only when the picture changes, which keeps a mostly-static recording small.

VFR is a common source of "the audio drifts out of sync after I edit it" complaints in other tools. Here the footage is decoded and passed through a filter graph before being re-encoded, so the output is written with regular timing regardless of how irregular the input was. That is usually an improvement — but it does mean a long, mostly-static screen recording can produce a noticeably larger file than it started as, because the output no longer gets to skip the frames where nothing happened. Capping the resolution is the fix.

Using it as a converter

Opening a file in one container and exporting it in another does convert it, and for a stubborn old AVI that nothing will play, that is a perfectly reasonable thing to do. Be clear about the trade, though: a container change here is a full decode and re-encode, not a remux. A dedicated converter that can copy the compressed streams into a new container is faster and lossless where this is neither.

The re-encode is unavoidable here because every operation runs through a filter graph, and you cannot stream-copy a stream you are filtering. The one shortcut is muting with nothing else changed, which is attempted as a stream copy first and re-encoded only if the source codec cannot go in the chosen container. The full explanation of that trade is worth reading if quality is your main concern, and the FFmpeg guide has the commands for a genuine lossless remux.

Questions about video formats