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.
#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 Opus audio (WEBM’s default), it can live in an MKV but not a native MP4 - the container spec doesn’t hold it. See H.264 vs HEVC vs AV1 for how the codec choice inside affects file size, playback, and licensing.
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
Plays natively on the OS: MP4 works on iOS, iPadOS, macOS, Windows, Android, ChromeOS, and every desktop OS. MKV plays natively on Windows 10+ (via the built-in Films & TV app) and Android (with any third-party player). MKV does not play on iOS or iPadOS under any circumstances - not in the Photos app, not in Files, not in QuickTime.
Plays on the TV: MP4 works on Chromecast, Apple TV, Roku, Fire TV, and every current smart TV. MKV works only on a few smart TVs (some LG and Samsung models with wide codec support), and it doesn’t Chromecast at all.
Plays in a browser through a <video> tag: MP4 with H.264 or HEVC, in every current browser. MKV - never, in any browser, at time of writing. If you want a video to play inside a webpage, MP4 is the only sensible choice.
Plays through VLC (any OS): Both. VLC has been the fallback answer for MKV 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 - MP4 has no way to hold VP9 - so the video has to be re-encoded, which introduces small transcoding losses. Same story for Vorbis audio and some FLAC configurations.
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.
#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.
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.