You AirDrop an MKV to your iPhone. It arrives instantly, sits in Files, and refuses to open. Photos won't import it. QuickTime says the format isn't supported. The clip that played fine on your laptop is now an unreadable rectangle on your phone.

The instinct is to blame the video. It's almost never the video. The picture and sound inside the MKV are, in the great majority of cases, exactly what an iPhone can play - H.264 or HEVC video with AAC audio, the same codecs the iPhone's own camera writes. What the iPhone refuses is the container: the outer wrapper the file uses to package its streams. (For the fuller comparison of what each container holds, see MP4 vs MKV.)

#Codecs vs containers, in one paragraph

A codec is how a stream of pixels or sound samples is compressed - H.264, HEVC, AAC, Opus. A container is a file format that wraps one or more of those streams together with an index and some metadata - MP4, MKV, MOV, WEBM. iPhones ship with hardware decoders for a specific short list of codecs and a specific short list of containers. When either doesn't match, playback fails, even if the other half would have been fine on its own.

iOS supports these containers natively: MP4, M4V, MOV, and 3GP. That's it. Everything else - MKV, WEBM, AVI, WMV, FLV, OGV, TS, MTS, VOB - is ignored regardless of what's inside. The codec inside can be identical; the wrapper alone is enough to stop playback.

#Why iOS keeps the list so short

Apple bakes container support into the operating system and, historically, into the hardware. Adding a new container means a firmware-adjacent code path - parsers for the file structure, hooks into the decoder pipeline, timing-model translations. Apple has consistently chosen the smaller list because a smaller attack surface means fewer bugs and fewer security patches. The trade-off is that anything outside the MPEG family of containers is your problem to convert.

Windows, Android, and desktop browsers each ship broader parser sets. VLC on any platform ships an even broader set. iPhones are the strictest common device, which is why "won't play on iPhone" is by far the most common reason people hit a converter site in the first place.

#The one-minute fix

When the streams inside are already MP4-compatible (H.264 or HEVC video with AAC audio - the case for the majority of MKV, MOV, and TS files you'll encounter), the fix is a remux: rewrite the container header without touching the video pixels or audio samples. The bytes on disk are almost the same. The picture and sound are identical. The wrapper says MP4 instead of MKV, and iOS plays the file.

A remux is fast because there's no re-encoding involved (see remux vs re-encode for the full mechanical story). A 500 MB MKV can be remuxed to a 500 MB MP4 in a few seconds on any modern laptop - the CPU is only reading and writing bytes, not decoding and re-encoding frames. Our own MKV to MP4 converter does exactly this in your browser: no upload, no server, no wait.

#When it's not just a remux

A minority of files inside your MKV-that-won't-play use a codec MP4 doesn't hold - most often VP9 video (common in YouTube downloads) or Opus audio. Those need a real re-encode, which is slower and introduces a small quality loss. WEBM files fall into this bucket by definition (VP9 + Opus is the WEBM standard); so do OGV files (Theora + Vorbis) and WMV files (Microsoft-specific codecs). A converter has to actually decode and re-encode, not just re-wrap.

You can tell which path your file is going to take before converting: if the source is MKV, MOV, TS, MTS, M4V, F4V, or 3GP, expect the fast path. If it's WEBM, OGV, WMV, VOB, or MPEG (the old MPEG-1 / MPEG-2 kind), expect a re-encode.

#What about AirDrop's "convert on send" option?

Recent iOS versions offer a "Most Compatible" AirDrop option that converts HEIF images and HEVC videos on send. It doesn't convert containers - an MKV going by AirDrop is still an MKV when it lands. The option only touches Apple's own codec families. Everything else is up to you.

#The takeaway

"Won't play on iPhone" is nine-tenths a container problem. If the file is an MKV, MOV, or TS with H.264 or HEVC inside - which is what the great majority of MKVs actually are - a container swap fixes it in seconds without touching the picture or sound. If it's a WEBM, WMV, or OGV, expect a real transcode and a small quality dip. Either way, it's not the codec you thought was wrong.