The first thing to know about MP4 versus MKV is that neither is a video codec. They’re both containers - file formats that wrap around video, audio, and metadata streams without changing them. The video inside an MKV can be identical, bit-for-bit, to the video inside an MP4. The comparison isn’t “which one looks better.” It’s “which one plays where you need it to.”
#The one-sentence answer
Use MP4 unless you have a specific reason to use MKV. That reason is almost always “I need to preserve multiple audio tracks, embedded subtitles, or codecs (VP9, Vorbis, FLAC) that MP4 can’t carry.” Everything else stays in MP4 by default, because MP4 plays where MKV doesn’t: on iOS, in every browser, on Chromecast, on smart TVs, and inside a <video> tag on the web.
The same job, two lineages
- Descends from Apple’s QuickTime
.mov, standardised by MPEG - Structure: nested boxes (ftyp, moov, mdat)
- Index can be moved to the head for fast start
- Text subtitles: tx3g only, styling discarded
- The only container browsers accept in a video tag
- Independent open project, later standardised at the IETF
- Structure: EBML, a binary cousin of XML
- Index (Cues) sits wherever the muxer put it
- Text subtitles: SRT, ASS/SSA, WebVTT, plus bitmap subs
- Accepts essentially any codec anyone has written down
#Where they actually differ
Codec support
MP4 accepts H.264, HEVC, MPEG-4 Part 2, and AV1 for video, plus AAC, MP3, AC-3, and Opus for audio. MKV accepts all of those plus VP8, VP9, FLAC, Vorbis, DTS, TrueHD, and a long tail of others. If you have VP9 video (common for YouTube downloads) or Vorbis audio, it can live in an MKV but not in an MP4 anyone will play - a mapping exists on paper for some of these, but no mainstream player goes looking for it. See H.264 vs HEVC vs AV1 for how the codec choice inside affects file size, playback, and licensing.
What each container is allowed to carry
| Stream | MP4 | MKV |
|---|---|---|
| H.264 / AVC | Yes | Yes |
| HEVC / H.265 | Yes | Yes |
| AV1 | Yes | Yes |
| VP9 / VP8 | No in practice | Yes |
| AAC · MP3 · AC-3 | Yes | Yes |
| Opus | Partial patchy players | Yes |
| FLAC · Vorbis | No | Yes |
| DTS · TrueHD | No | Yes |
| Text subtitles | tx3g styling lost | SRT · ASS |
| Bitmap subtitles | No | PGS · VobSub |
| Chapters | Yes | Yes |
Multiple tracks
Both support multiple video, audio, and subtitle tracks. In practice MKV’s track handling is more robust - tools that produce MKVs tend to preserve every track (director commentary, dubbed languages, alternate angles), whereas MP4 export presets often drop everything but the primary audio. When you see a scene release ship as MKV, this is usually the reason: the packager wants the Japanese track, the English dub, the commentary, and the karaoke subs all in one file.
Subtitles
MKV embeds subtitle formats like SubRip (.srt) and Advanced SubStation Alpha (.ass) directly, along with bitmap subtitles (PGS from Blu-ray, VobSub from DVD). MP4’s only text-subtitle codec is TX3G / mov_text, which most tools don’t emit well, and MP4 has no home for bitmap subs at all. This is the single biggest practical reason a subtitle-heavy release ships as MKV - MP4 will silently lose most of it.
Streaming
MP4 has a defined fast-start mode where the file’s index (the moov atom) sits at the head, so a browser can start playback within milliseconds of opening the file. MKV’s index is at a predictable position by design, which is convenient for local players but doesn’t match how HTTP streaming actually works. See the moov-atom explainer for why front-loading the index matters.
File size
Nearly identical for the same content. MKV’s container adds slightly less overhead per stream, so an MKV can end up a few percent smaller than the same content in MP4. That’s the container overhead only - the compressed video and audio inside are the same size in either case.
#Which one plays where
This is the table that actually decides the question. Every row below assumes the same H.264 video and AAC audio inside - the only variable is the wrapper.
Same streams, different doors
| Destination | MP4 | MKV |
|---|---|---|
| iPhone / iPad | Plays | Never |
| Android | Plays | Plays |
| Windows 10 / 11 | Plays | Plays |
| macOS QuickTime | Plays | Never |
| Browser video tag | Plays | Never |
| Chromecast | Plays | Never |
| Apple TV · Roku · Fire TV | Plays | Model-dependent |
| Smart TV, USB stick | Plays | Some LG · Samsung |
| VLC, any OS | Plays | Plays |
| Premiere · Resolve · Final Cut | Imports | Resolve only |
Two details worth pulling out of the table. MKV does not play on iOS or iPadOS under any circumstances - not in Photos, not in Files, not in QuickTime, no matter what is inside it. And MKV has never played in a browser <video> tag, in any browser, at any point. If a video needs to live inside a webpage, MP4 is not the better choice; it is the only choice.
VLC, as always, is the escape hatch. It has been the answer to “why won’t this MKV play” since MKV existed, and it stays the answer wherever hardware support is missing.
#What happens when you convert MKV to MP4
Almost always: nothing changes about the video or audio. Most MKVs carry H.264 or HEVC video with AAC audio - exactly what MP4 accepts natively. The conversion is a remux: the container header is rewritten, but the compressed pixels and audio samples are copied bit-for-bit. Quality is identical because there’s no encoding step. See the remux vs re-encode explainer for the mechanical details of why this is so much faster than a full transcode.
The exceptions land in the outer edge cases. An MKV carrying VP9 video can’t be remuxed into an MP4 anything will play, so the video has to be re-encoded, which introduces small transcoding losses. Same story for Vorbis audio and some FLAC configurations.
Will your MKV copy, or does it have to be re-encoded?
- Path 1 H.264 or HEVC video + AAC, MP3 or AC-3 audio Seconds Straight remux. Every compressed byte is copied across unchanged and a new MP4 header is written around it. Picture and sound come out bit-identical. This covers the large majority of MKVs in the wild.
- Path 2 H.264 video + FLAC, Vorbis, DTS or TrueHD audio Under a minute Video still copies. Only the audio is decoded and re-encoded to AAC - a few seconds of work, and the one thing that changes is an audio track most listeners cannot distinguish from the source.
- Path 3 VP9 or VP8 video Real transcode Every frame is decoded and re-compressed as H.264. This is the only case where the picture genuinely changes, and it is the only case that deserves a long progress bar.
If your MKV is the common H.264+AAC kind, a proper MKV-to-MP4 converter takes seconds and produces a file with identical picture and sound. Wave runs the conversion entirely in your browser and shows the fast-copy path lighting up on files that qualify.
#What happens when you convert MP4 to MKV
The same, in reverse. MKV accepts everything MP4 does, so the conversion is always a remux - there’s never a quality loss. You’d do this when you’re packaging something for archival with multiple tracks or subtitles, or when your target software prefers MKV. Wave doesn’t offer this direction - the site’s scope is video into MP4 (with MP3 audio extract as the one adjacent shortcut) - but any local ffmpeg install does it in one command: ffmpeg -i in.mp4 -c copy out.mkv.
#When compatibility bites
The single biggest reason people convert MKV to MP4 is that iOS doesn’t play MKV. AirDrop an MKV to an iPhone and it sits in Files unplayable; neither Photos nor QuickTime touches it. The same MKV, remuxed into MP4, plays instantly. Nothing about the video changed - the container name did. This is the whole story of the MKV-on-iPhone problem, and it applies equally to the other containers iOS refuses (WEBM, WMV, OGV, MTS, VOB, and the rest).
The reverse case is subtler. When you export an MP4 from a video editor that includes multiple audio tracks (behind-the-scenes commentary, dubbed language, director commentary), consumer video players usually drop everything but the first track. Packaging as MKV instead preserves every track for viewers who use players that respect them.
Nothing about the video changed. The container name did.
The whole of the MKV-on-iPhone problem, in one line
#Common misconceptions
“MKV has better quality than MP4.” No. Both are containers. The visual quality is set by the codec inside - an H.264 stream at 8 Mbps looks the same whether you package it as MKV or MP4, because it’s literally the same H.264 stream. If two files of the same source look different, the encoder settings differed, not the container.
“Converting MKV to MP4 loses quality.” Not when the source uses MP4-compatible codecs (H.264, HEVC, AAC), which is the majority of MKVs. The remux path copies the streams bit-for-bit - there is nothing to lose. Any converter that shows a slow progress bar for this case is re-encoding unnecessarily.
“MKV is for pirates.” MKV has a reputation because it’s the format many BitTorrent releases use. That’s because MKV’s multi-track and subtitle handling suits scene releases with alternate audio and hard-coded subs. The container itself is an open, well-specified format - its use by any particular file has no bearing on what the container is.
“MKV is bigger than MP4.” Effectively no. The container overhead difference is a couple of percent at most. If your MKV is dramatically larger than a supposedly-equivalent MP4, the MP4 was re-encoded at a lower bitrate - that’s the actual difference, not the wrapper.
#The takeaway
MP4 wins on compatibility. MKV wins on preservation. The choice is mostly about who’s going to open the file. If you’re sending it to a phone, a browser, a TV, or an unknown recipient - MP4. If you’re archiving something with a rich structure you don’t want to lose - MKV.
The only question that matters
And when you need to convert between them, both directions are usually a container swap. Same bytes, different label. If a converter tells you it’s going to take fifteen minutes to convert a 500 MB MKV to MP4, close the tab - the honest answer is a few seconds. Want just the sound? The MKV-to-MP3 extract uses the same in-browser engine and finishes even faster because the video is discarded.