MKV or MP4 for archiving?

MKV is usually better suited for archiving because it carries multiple audio tracks, many subtitles and chapter markers losslessly. If you want to keep a film with its original language, a dubbed track and two subtitle tracks, MP4 handles those only in a limited way. But if you'll use your archive directly on a television or an older player, MP4 gives you fewer surprises.

Why does everyone use MP4?

Because compatibility beats everything else. The MP4 container and the H.264 codec inside it have hardware support on practically every device ever made: phones, televisions, browsers, car displays, consoles. There are technically better options, but the 'works everywhere' guarantee is worth more than that technical edge in most scenarios.

When does WEBM make sense?

When you're serving video on your own website and bandwidth cost matters. The VP9 codec inside WEBM uses noticeably less data than H.264 at the same quality, and every modern browser supports it. But if the file will be downloaded and opened in a local player, or shared around, MP4 is safer.

Should I convert the MOV files my phone produces?

Yes, if you're having trouble on a Windows computer or in some editing programs. But do the conversion right: iPhone MOV files usually carry H.264 or H.265 video and AAC audio, which means you can move to MP4 by remuxing — with no quality loss at all. If H.265 is the source of the problem, then re-encoding is required.

Which Video Format Should You Choose? MP4, MKV, WEBM and MOV Compared

Which format should you store a video in, share it in, publish it in? The answer depends on the use, and there's no such thing as a "best format" — only ones better suited to particular jobs. This article compares video containers through real scenarios.

Basic container comparison

| Feature | MP4 | MKV | WEBM | MOV | AVI | |---|---|---|---|---|---| | Device compatibility | Highest | Medium | Good on the web | High on Apple | Older devices | | Browser support | Full | None | Full (modern) | Partial | None | | Multiple audio tracks | Limited | Excellent | Limited | Good | Weak | | Subtitle support | Limited | Excellent | Limited | Medium | Weak | | Chapter markers | Partial | Yes | No | Yes | No | | Streaming | Very good | Weak | Very good | Medium | Bad | | Editing friendly | Medium | Medium | Weak | Very good | Weak | | Modern codec support | Good | Excellent | Limited (VP9/AV1) | Good | Weak |

Scenario 1: Sharing on social media

Instagram, YouTube, LinkedIn, WhatsApp.

Winner: MP4 (H.264 plus AAC).

There's no debate in this scenario. Every platform accepts MP4/H.264, and they re-encode into their own formats after upload anyway.

An important consequence: since the platforms will re-encode, there's no point sending an unnecessarily high bitrate — but don't send one that's too low either, because their encoding will add another loss on top of your quality. For 1080p, 8-10 Mbps is a reasonable upload quality.

Check platform-specific requirements: some want vertical (9:16), some square (1:1) aspect ratios; there are duration limits.

Scenario 2: A film and series archive

A long-term collection with multiple languages and subtitles.

Winner: MKV.

MKV looks like it was designed for this job:

Unlimited audio tracks. Original language, dubbed track, commentary track — all in one file.
Rich subtitle support. SRT, ASS/SSA (with formatting), PGS (Blu-ray image subtitles) — it carries all of them.
Chapter markers. For scene skipping.
It carries every codec. H.265, AV1, FLAC audio — no limits.
Lossless remuxing. Bringing a Blu-ray into MKV requires no re-encoding.

If you try to store the same content in MP4, you'll either lose tracks or have to keep subtitles in separate files.

MKV's cost: older televisions, some media players and some streaming devices can't read MKV. If you'll watch your archive directly on a television, test this.

Scenario 3: Putting video on my own website

Bandwidth cost matters and visitors will watch in a browser.

Winner: WEBM (VP9) plus an MP4 fallback.

VP9 uses noticeably less data than H.264 at the same visual quality. For a high-traffic site that's a serious difference in cost.

Every modern browser supports WEBM/VP9. Offer an MP4 fallback for older browsers:

<video controls>
  <source src="video.webm" type="video/webm">
  <source src="video.mp4" type="video/mp4">
</video>

The browser picks the first source it supports.

Also don't forget the linearize/faststart setting: in MP4 the metadata has to be at the start of the file so the browser can begin playing before the whole thing has downloaded. If that setting is off, the user waits for the entire file.

Scenario 4: Editing video

You're bringing footage into an editing program.

Winner: MOV, or intermediate codecs like ProRes/DNxHD.

Editing has different requirements from playback. Long GOP codecs like H.264 and H.265 are bad for editing: to access any frame you have to decode from the start of the GOP, which causes stuttering as you scrub the timeline.

Professional workflows use intermediate codecs: ProRes, DNxHD, Cineform. These encode every frame independently (I-frame only), so they give instant access during editing. The cost is file size — a ProRes file can be many times larger than the same content as H.264.

For simple cut-and-join work, working in the source format is enough; for color grading, multi-layer compositing and effects work, moving to an intermediate codec improves performance dramatically.

The MOV container carries these intermediate codecs natively and is the standard in macOS/Final Cut environments.

Scenario 5: Using phone video on a computer

iPhone MOV files or Android MP4s.

Winner: remux to MP4 (not re-encode).

iPhone videos usually sit in a MOV container carrying H.264 or H.265 video and AAC audio. Those codecs are compatible with the MP4 container, so a remux is enough — no quality loss, done in seconds.

If the problem stems from H.265 (some Windows programs and older software can't decode it), then re-encoding is required: convert to H.264.

There are also two problems commonly seen with phone video:

Variable frame rate. Phones can change the frame rate depending on light. In editing programs this causes sync drift. Forcing a constant frame rate during conversion fixes it.

Orientation metadata. A phone can record video horizontally and add "display vertically" metadata. Some programs ignore that metadata and the video appears sideways. Physically applying the rotation during conversion fixes it.

Scenario 6: Watching from USB on a television

You'll copy the file to a USB stick and open it on the TV.

Winner: MP4 (H.264 plus AAC), with a low profile.

Televisions are the most constrained devices when it comes to playback. Safe settings:

Container: MP4
Video: H.264, Main or High profile
Audio: AAC stereo (DTS and AC3 don't work on many TVs)
Resolution: don't exceed the TV's maximum
Subtitles: as a separate SRT file with the same name as the video

MKV works on some newer TVs but it isn't guaranteed. H.265 is supported on newer models but chokes older devices.

Scenario 7: I have an old AVI archive

DivX/Xvid files left over from the 2000s.

Winner: re-encoding to MP4.

The AVI container doesn't work well with modern codecs, and the old codecs inside it (DivX, Xvid, MPEG-4 Part 2) are supported less and less.

Conversion requires re-encoding, and that's a lossy-to-lossy transition — some quality loss is unavoidable. To limit it:

Keep the bitrate above the source's (since older codecs are less efficient, H.264 delivers the same quality with fewer bits; 70-80% of the source is usually enough).
Don't change the resolution.
Don't change the frame rate.

These files are usually low resolution (480p and below); trying to upscale them is futile.

Codec selection summary

The codec matters as much as the container:

| Use | Video codec | Audio codec | |---|---|---| | General sharing | H.264 | AAC | | Website | VP9 (plus H.264 fallback) | Opus (plus AAC) | | Archive (space matters) | H.265 | AAC or FLAC | | Editing | ProRes / DNxHD | PCM | | Television | H.264 | AAC stereo | | Maximum efficiency | AV1 | Opus |

Decision summary

When in doubt → MP4 plus H.264 plus AAC. Works everywhere.
Archive with multiple languages and subtitles → MKV.
Your own website → WEBM/VP9 plus an MP4 fallback.
Editing → MOV plus an intermediate codec.
Television → MP4, low profile, AAC stereo.
Fixing phone video → remux to MP4, avoid re-encoding if you can.

And most importantly: don't convert needlessly. If the video already works and the target device supports it, leave it alone. Every re-encode means some quality loss, and there's no going back.