Video File Formats Explained: MP4 vs MOV vs MKV vs WebM

By Andrew Butson · July 2, 2026 · 7 min read

The single most misunderstood thing about video files is that 'MP4' isn't actually a video format on its own: it's a box. MP4, MOV, MKV, WebM and AVI are containers: wrappers that bundle a video track, an audio track, subtitles and metadata into one file. What's actually doing the compressing inside that box is a codec, such as H.264, H.265, VP9 or AV1, and a single container can, in principle, hold several different codecs.

That distinction explains almost every confusing thing about video files: why one .mp4 plays fine and another one from a different source doesn't, why 'just convert it to MP4' is the internet's default advice, and why some conversions finish in seconds while others take minutes. This guide covers the containers you'll actually meet, what's usually inside them, and what a conversion is really doing when you run one.

Container vs codec: the distinction that explains everything

Think of the container as a shipping box and the codec as what's packed inside it. The box's job is just to hold and label the contents, such as the video track, audio track, subtitles and chapter markers, so a player knows where each one starts. The codec's job is the actual compression: turning raw, enormous video frames into something a fraction of the size. Whether a file plays depends on whether a device recognises both the box and what's inside it; a player that understands the MP4 container but not the codec inside a particular file will still fail to play it.

This is also why 'convert this video to MP4' is a slightly imprecise but broadly correct instinct: MP4 as a container is nearly universally recognised, but a working MP4 also needs a codec every target device supports, and today that almost always means H.264. So in practice, converting 'to MP4' usually means re-encoding the video into H.264 and repackaging it in the MP4 box: two different jobs happening at once, not one.

MP4 — the safe default

MP4 is the container almost everything can play: every phone, browser, smart TV and upload form accepts it, and it's the format most upload widgets expect by default. It most commonly wraps H.264 video, occasionally the newer, more efficient H.265, with audio nearly always AAC. If you're not sure what a video needs to be, MP4 with H.264 is the answer that works almost everywhere.

MOV — Apple's native format

MOV is Apple's QuickTime container, and it's what an iPhone or a Mac records straight to. Structurally it's a close cousin of MP4 (the ISO base media format MP4 is built on was derived from QuickTime), and it often holds the same H.264 or H.265 video, which is why a MOV will frequently just play in a browser. Where it causes trouble is on non-Apple platforms and upload forms that only expect MP4 by name, or with clips shot in Apple's ProRes codec, a professional, much larger, editing-friendly format that consumer devices don't decode.

MKV — the archive format

Matroska, MKV, is an open container built to hold almost anything: multiple audio tracks, dozens of subtitle languages, chapter markers, and any video codec at all, which is why it's the format of choice for high-quality archival rips and releases. The trade-off is patchy native browser support: Chrome plays MKV directly, Safari doesn't support the container at all, and Firefox only gained support from version 145 onward. Outside a browser it's well supported by dedicated media players: it's the web specifically that MKV struggles with.

WebM — built for the browser

WebM is an open, royalty-free container designed specifically for the web, almost always carrying the VP9 or newer AV1 codec. It compresses efficiently at web-friendly bitrates and is what many web platforms serve internally. Its weak point is the mirror image of MKV's: strong in-browser support, weaker support in general desktop software and older devices outside a browser context.

AVI — the one to leave behind

AVI is a Microsoft container from the early 1990s, and it shows: no efficient modern codec support to speak of, no proper streaming metadata, and file sizes far larger than MP4 or WebM for the same visual quality. It's still floating around in older archives and some capture software, but there's no reason to create a new AVI file today, and converting one to MP4 the moment you meet it is close to a straightforward upgrade.

Remuxing vs transcoding: why some conversions are instant and others aren't

Not every video conversion does the same amount of work. A remux repackages the existing, already-compressed video and audio streams into a new container without touching the compressed data itself: if the codec inside is already something the target container and device can handle, the streams are simply copied across. Remuxing is close to instant and completely lossless, because no pixel is ever decoded or re-encoded.

A transcode is a different job entirely: it fully decodes the video back to raw frames and re-encodes them with a new codec, or the same codec at different settings, which is unavoidably slow and, because it goes through a lossy codec, unavoidably a fresh generation of loss (see our lossy vs lossless guide for why that loss can't be undone later). Converting a MOV, MKV, AVI or WebM to MP4 needs a real transcode rather than a remux, because the source codec, which could be almost anything inside an MKV, isn't guaranteed to be something MP4 players expect. The safe, universal result is a fresh H.264 encode, which is what Morphr's video conversions do.

The practical upshot: expect a video-to-video conversion to take real time and to be a genuine re-encode, not a free repackage, and expect it to take proportionally longer for a longer or higher-resolution source, since the whole clip is being decoded and re-encoded rather than just relabelled.

Pulling just the audio out

Extracting the audio from a video — turning an MP4 into an MP3, or an interview MOV into a WAV — is one of the highest-intent video conversions there is, and it's a narrower job than a full transcode: only the audio track needs decoding and re-encoding, while the video is simply discarded. It's still a real re-encode of the audio, so it's a one-way lossy step whenever the target is MP3, AAC or another lossy codec, but it's faster than converting the whole clip because there's no video to touch.

What to honestly expect from a browser-based converter

All of this (transcoding, remuxing, audio extraction) runs in your browser rather than on a server, which is what keeps a video file from ever leaving your device. The trade-off is speed: a phone or laptop's CPU decoding and re-encoding a large video is slower than a dedicated server farm would be, so a long or high-resolution clip can genuinely take a few minutes rather than a few seconds. That's the cost of the conversion staying private and free. For a short clip it's barely noticeable; for a long one, it's worth expecting.

Frequently asked questions

What's the actual difference between MP4 and MOV?

Very little at the container level: MOV is Apple's original QuickTime container and MP4 is the standardised, more universally supported descendant of it. The bigger practical difference is what's typically inside them: MOV sometimes carries Apple-specific codecs like ProRes that MP4 rarely does.

Why does my MKV file play in Chrome but not in Safari?

Native MKV support varies a lot by browser: Chrome decodes it, Safari does not support the container at all, and Firefox only added support from version 145 onward. Converting to MP4 sidesteps the inconsistency entirely.

Does converting a video to MP4 lose quality?

Usually yes, a little. 'Convert to MP4' typically means re-encoding the video into H.264, a lossy codec, so it's a fresh generation of compression on top of whatever the source already had. It's the same trade-off as re-saving a JPEG: necessary sometimes, best not repeated on the same file.

Why does converting a video take so much longer than converting an image?

A video is effectively thousands of images, its frames, plus an audio track, and a transcode has to decode and re-encode every one of them. Doing that in a browser, on your own device's CPU, is inherently slower than the near-instant recompression of a single image.