MP4, WebM and MKV: Choosing a Video Format That Actually Plays

A container defines what can live inside the file: video tracks, audio tracks, subtitle tracks, chapter markers, metadata. A codec defines how the picture or sound is compressed. MP4 can hold H.264, HEVC or AV1 video with AAC or Opus audio; MKV can hold nearly anything; WebM is restricted to the open codecs, in practice VP8, VP9 or AV1 with Vorbis or Opus.

That split explains the two very different kinds of conversion. Repackaging — moving the same H.264 stream from an MKV into an MP4 — is a copy: fast, lossless, and only possible when the target container accepts the codec already inside. Re-encoding — turning HEVC into H.264 — decodes and re-compresses every frame: slow, lossy, and the only option when the device you are targeting cannot decode the original codec.

MP4 with H.264 video and AAC audio is the closest thing to a universal format: every phone, television, editor, social platform and presentation tool accepts it, which is why it is the safe answer for anything you are sending to someone else. HEVC in an MP4 is roughly 30 to 50 percent smaller at the same quality, but playback depends on the device having a licensed HEVC decoder, and older Windows machines and browsers often do not.

WebM with VP9 or AV1 is for the web: browsers decode it natively and it is typically smaller than H.264 at equal quality, which is why video sites serve it first with an MP4 fallback. It is a poor choice for a file someone will open on a television or drop into a video editor. MKV is a container for keeping things — multiple audio tracks, many subtitle languages, chapters — with excellent desktop player support and patchy support on Apple devices, smart TVs and phones. MOV remains the working format of the Apple ecosystem, and AVI is legacy: large, old codecs and increasingly unsupported.

A re-encode is one lossy generation. Do it once from the original and the result is usually indistinguishable; do it three times while chasing the right format and the artefacts compound — the second pass has to compress the smears created by the first, which makes the file both worse and, perversely, sometimes bigger.

Two settings dominate the result. Resolution is the biggest lever: 1080p downscaled to 720p at a sane bitrate looks better and is far smaller than 1080p squeezed to a low bitrate. And bitrate should match the content — a static talking-head needs a fraction of what fast motion does. Note also that converters optimised for turnaround, including most server-side ones, trade some encoding efficiency for speed; if you are producing a master or a file for broadcast, export from your own editor instead.

Subtitles are the most common casualty of container conversion. MKV happily carries a dozen subtitle streams; MP4 supports them but many tools drop them silently during conversion, and burned-in subtitles are a different thing entirely from a selectable track. If subtitles matter, keep them as a separate SRT or WebVTT file — which is also the format a web player expects — or check explicitly that the output still lists its tracks.

For web delivery there is one more detail worth knowing: the index at the start of an MP4. A file written with its index at the end has to be fully downloaded before it starts playing, while one written with the index first can play progressively. If a video on a page sits at a spinner until it is completely fetched, the container is fine and the layout of the file is the problem. And if you only needed the sound, extracting to MP3 or WAV is faster than any video conversion and gives you a file that plays anywhere.