MKV vs MP4 vs WebM: which video container should you use?
Three containers, three sets of trade-offs. When each one is the right choice, why your TV plays one and not the other, and how to convert between them without losing quality.
The most common video question we see is some version of “my file is .mkv and my TV won’t play it, should I convert it to .mp4?” The honest answer is usually “yes, and it will take ten seconds and lose nothing”, but to see why, you need the one idea that most explanations skip: a video file’s extension names the container, not the video.
Containers and codecs are different things
A container is a wrapper. It holds one or more streams (video, audio, subtitles), tells the player how they are timed against each other, and carries metadata such as chapters and titles. MKV, MP4 and WebM are containers.
A codec is how the pixels inside a stream are compressed. H.264, HEVC, VP9 and AV1 are video codecs; AAC, Opus, AC-3 and FLAC are audio codecs.
Any container can, in principle, hold any codec, but each one is picky in practice. That pickiness, not the container itself, is why a file plays on one device and not another. Two .mp4 files can be as different as H.264 with AAC (plays everywhere) and HEVC with AC-3 (plays on far fewer devices).
MP4: the one everything plays
MP4 is the ISO base media file format, standardised by MPEG and derived from Apple’s QuickTime container. It is the default output of phones, cameras, editing software and streaming encoders, and every browser, TV, console and phone plays it.
Its conservatism is the point. MP4 officially supports a defined list of codecs (H.264, HEVC, AV1, AAC, MP3, and a few more), which means a player that claims MP4 support knows exactly what it has to decode. Subtitles are limited to a timed-text format few tools use, so most MP4 files have none.
Use MP4 when the file has to play on something you do not control: a TV, a phone, a client’s laptop, a web page.
MKV: the one that holds anything
Matroska is an open container built around extensibility. It accepts any codec that exists, including ones invented after the container was, plus unlimited audio tracks, soft subtitles in every format (SRT, ASS, PGS), chapters, attached fonts and cover art.
That flexibility is why it dominates archival, multi-language releases and anything with real subtitle needs. It is also why it fails on devices: a player may support “MKV” and still refuse a specific file because of the codec inside, and Apple’s QuickTime and the default iOS player do not open it at all.
Use MKV when you are keeping a master copy, need several audio or subtitle tracks, or want chapters and attachments. Convert to MP4 for delivery.
WebM: the one built for the browser
WebM is a strict subset of Matroska defined by Google in 2010: the same container, restricted to royalty-free codecs (VP8, VP9, AV1 for video; Vorbis, Opus for audio). The restriction is what made browsers adopt it; there are no licensing questions.
Browser support is universal, hardware support outside browsers is not. Most TVs and many phones will not play WebM from a USB stick, and almost no camera or editor produces it. It is a delivery format for the web and a capture format for screen recorders, not a general-purpose one.
Use WebM when the only destination is a web page or a browser-based player, and you want AV1 or VP9 with Opus.
The honest comparison
| MP4 | MKV | WebM | |
|---|---|---|---|
| Plays on TVs, phones, consoles | nearly all | some | few |
| Plays in browsers | yes | no | yes |
| Codecs allowed | defined list | anything | royalty-free only |
| Multiple audio tracks | awkward | native | native |
| Soft subtitles | limited | excellent | WebVTT only |
| Chapters and attachments | limited | native | partial |
| Survives an interrupted recording | poorly | well | well |
| Streaming over HTTP | excellent | poor | good |
The last two rows explain two things people run into. OBS records to MKV by default because a crash mid-recording leaves a playable file, where MP4 leaves an unplayable one with no index. And streaming services use MP4 (fragmented) because its structure suits byte-range requests.
Converting without losing anything
If the codecs inside the file are ones the target container accepts, conversion is a remux: the streams are copied byte for byte into a new wrapper. It takes seconds and is lossless.
# MKV with H.264 + AAC inside -> MP4, no re-encode
ffmpeg -i movie.mkv -c copy movie.mp4
# MP4 -> MKV (always works; MKV takes anything)
ffmpeg -i movie.mp4 -c copy movie.mkv
# Find out what is inside first
ffprobe -hide_banner movie.mkv
A remux to MP4 fails, or drops tracks, in three common cases: the subtitles are ASS or PGS (MP4 cannot hold them), the audio is FLAC or Vorbis, or the video is a codec MP4 does not list. Then you need a real conversion:
# Re-encode video and audio to the universal pair
ffmpeg -i movie.mkv -c:v libx264 -crf 20 -preset medium -c:a aac -b:a 192k movie.mp4
Re-encoding is lossy, slow, and should be a last resort. Keep the original.
The two other names you will meet
AVI is Microsoft’s 1992 container, still produced by some cameras and found in older collections. It lacks chapters, subtitles and modern codec support; remux it to MKV or MP4 and move on.
MPEG transport stream (.ts, .m2ts) is the broadcast and Blu-ray container, built to survive packet loss. Recordings from TV tuners and camcorders arrive in it, and it remuxes cleanly to MP4 or MKV.
Which one, in one line each
- Sending it to someone, or putting it on a device: MP4.
- Keeping it, with all its tracks: MKV.
- Embedding it in a web page: WebM (with an MP4 fallback for safety).
And if a file will not play, check what is inside it before blaming the container. Drop it on the detector or run ffprobe; the codec is almost always the real answer.