Video File Formats Explained: MP4, MOV, MKV, AVI, and WebM

Someone sends you a video and it will not play. The file is there, it has a reasonable size, your player opens it and shows a black rectangle with sound, or sound with no picture, or an error message that explains nothing. Meanwhile the person who sent it insists it plays fine on their machine. This is the most common frustration in all of digital video, and it comes down to a distinction that almost nobody is ever taught: the difference between the box a video comes in and the compression used inside it.

Once that distinction is clear, video formats stop being mysterious. You can look at a file, understand why it behaves the way it does, predict where it will and will not play, and convert it correctly instead of running it through whatever tool comes up first and hoping. You also stop making the expensive mistake of re-encoding files that only needed their wrapper changed.

This guide covers the five formats you will actually encounter, the codecs that live inside them, why each one exists, which to use for editing, delivery, web, archive, and social, and how to convert between them with the least possible damage. It is written for people who work with video rather than people who build codecs, so the focus stays on decisions you can act on.

Container vs Codec: The Difference That Explains Everything

A video file is not one thing. It is a package holding several separate streams that have to stay synchronized: at least one video stream, usually one or more audio streams, and often subtitle tracks, chapter markers, cover art, and metadata such as the recording date and camera model.

The container is the packaging

The container defines how all of those streams are interleaved into a single file, how a player finds the start of any given second, and what extra information can be stored alongside the picture and sound. The file extension names the container and nothing else. When you see .mp4, .mov, .mkv, .avi, or .webm, you have learned what shape the box is. You have learned nothing about what is inside it.

Containers differ in what they permit. Some allow multiple audio tracks, some allow only one. Some support embedded subtitle formats, some do not. Some are designed so that a player can begin decoding before the whole file has downloaded, which matters enormously for streaming. Some carry chapter markers and some cannot.

The codec is the compression

Inside the container, the video stream is compressed with a codec. The name is a contraction of coder and decoder. H.264, H.265, VP9, and AV1 are the four that matter today. The codec determines the file size, the encoding time, the picture quality at a given size, and, critically, whether a given device can play it at all.

Devices decode video in hardware wherever possible, using a dedicated chip designed for one specific codec. If a device has an H.264 decoder and receives H.265, it either falls back to slow software decoding, which drains battery and may stutter, or it fails entirely. This is why codec support is much less forgiving than container support.

Why this causes so much confusion

Two files can both be named .mp4 and be entirely different in practice. One might hold H.264 video and AAC audio, which plays on a fifteen year old device. The other might hold AV1 video and Opus audio, which will not open on anything more than a few years old. Same extension, same container, completely different compatibility.

The reverse is equally true. An MKV file and an MP4 file might contain byte for byte identical H.264 video. The MP4 plays in a browser, the MKV does not, and the difference is purely the wrapper. Converting between them requires no re-encoding at all, which is why that particular conversion takes seconds rather than minutes and loses nothing.

A useful mental model: the container is the envelope and the codec is the language the letter is written in. A player has to accept the envelope and read the language. Failing either one produces the same symptom, which is why the error messages are so unhelpful.

MP4: The Format That Plays Everywhere

MP4, properly MPEG-4 Part 14, was standardized in 2001 and has become the default video format of the internet. If you only ever remember one thing about video formats, remember that MP4 containing H.264 video and AAC audio is the safest file you can hand to another person.

Why it won

MP4 arrived at the right moment with the right properties. It was an open international standard rather than one company's format, so hardware manufacturers adopted it without licensing anxiety about the container itself. It handled streaming well. And it became the format that Apple used for the iPod and iTunes at exactly the point when portable video went mainstream, which meant every competing device had to support it too.

Twenty five years later the result is near total ubiquity. Every browser, every phone, every smart television, every game console, every social platform, and every video editor accepts MP4. There is no other video format about which that can be said.

What MP4 does well

• Universal playback. The practical compatibility ceiling for video. Nothing else comes close.
• Progressive streaming. With the index placed at the start of the file, a player can begin showing video before the download finishes. This is the single most important property for web video.
• Low overhead. The container structure adds a fraction of one percent to file size.
• Broad codec support. H.264, H.265, and AV1 video all sit comfortably inside MP4, alongside AAC, MP3, and increasingly Opus audio.
• Metadata and chapters. Enough support for titles, cover art, and chapter markers to serve normal needs.

Where MP4 falls short

• Subtitles are awkward. MP4 supports timed text but implementation is inconsistent, and many players ignore embedded subtitles entirely. Separate .srt files remain more reliable.
• Multiple audio tracks are poorly handled. Technically permitted, unevenly supported. If you need five language tracks, MKV is a better choice.
• Damage recovery is poor. If the index at the start or end of the file is corrupted, the whole file can become unplayable even though the actual video data is intact.
• No alpha channel in practice. Transparent video does not survive a normal MP4 export, which matters for motion graphics and overlays.

The streaming index detail worth knowing

MP4 files store an index describing where each frame sits in the file. That index can be written at the end, which is easier when encoding, or at the start, which lets a player begin immediately. Files with the index at the end must be downloaded in full before playback starts, which on a web page looks like a video that will not load.

Moving the index to the front is called faststart, and it is a rearrangement of existing data rather than a re-encode. If a video plays fine locally but stalls when embedded on a page, this is very often the cause, and it costs nothing to fix.

MOV, MKV, AVI, and WebM Compared

The other four formats each exist for a real reason. Knowing what each was built for tells you immediately whether you are holding the right file for the job.

MOV: the editing format

MOV is Apple's QuickTime container, released in 1991. It is worth knowing that MP4 was derived from it, which is why the two are structurally so similar and why converting between them is usually trivial.

MOV survives because professional video production runs on it. It carries features that editing genuinely requires and delivery does not: timecode tracks for syncing multiple cameras, alpha channels for transparent overlays, multiple high bitrate audio tracks, and support for intermediate codecs such as ProRes and DNxHD that are designed to be decoded quickly and re-encoded repeatedly without visible degradation.

Those same features make MOV wrong for delivery. A ProRes MOV of a five minute video can be six gigabytes. Windows machines may need extra software. Browsers do not play it reliably. Most social platforms reject it or handle it badly.

The practical rule is that MOV should be the format you edit in and never the format you send. If a camera or an editor handed you a MOV and someone else needs to watch it, running it through a MOV to MP4 converter is the right move. When the MOV already contains H.264 video, which is what most iPhones produce, the conversion is a pure container change: identical picture, identical quality, a file that now plays on everything.

MKV: the archive and media library format

MKV, short for Matroska, is the most capable container that exists. It is open, royalty free, and deliberately unrestricted. It will hold essentially any video codec, any audio codec, an unlimited number of tracks of each, multiple subtitle formats, chapters, attachments such as fonts, and rich metadata. It also recovers gracefully from corruption, since a damaged section usually costs you only that section rather than the whole file.

This makes it the correct format for archiving and for media libraries. A film stored as MKV can carry the original video, several language audio tracks, a commentary track, and subtitles in a dozen languages in one file.

The cost of that flexibility is compatibility. No major browser plays MKV. Most smart televisions and streaming devices either refuse it or support only some of what it can contain. Many editors will not import it. Social platforms reject it. And because MKV accepts anything, an MKV file is a genuine unknown until you inspect it.

When an MKV will not play, converting it with an MKV to MP4 converter is the standard fix. If the video inside is already H.264 or H.265, the conversion is a remux and finishes almost instantly with no quality change at all. Be aware that MP4 cannot carry everything MKV can, so extra subtitle tracks and unusual audio formats may be dropped in the process. That is usually acceptable for a file you just need to watch or send.

AVI: the legacy format

AVI, Audio Video Interleave, was introduced by Microsoft in 1992. It predates essentially every modern video concept, and its limitations are the limitations of early nineties computing.

• The original specification imposed a four gigabyte file size limit, which extensions worked around imperfectly.
• Variable bitrate audio was never properly supported, which is the direct cause of the audio drift that AVI files are notorious for.
• There is no clean way to store B frames, so modern codecs cannot use one of their most valuable efficiency techniques.
• Subtitles have no native support at all.
• Container overhead is high compared with modern formats.

Despite all of that, AVI is still everywhere, because enormous quantities of it were produced. Camcorders from the 2000s, dashboard cameras, security recorders, scientific and industrial capture equipment, and two decades of home video archives all output AVI. People still find these files on old drives and need to do something with them.

The answer is almost always the same: convert them. Running old footage through an AVI to MP4 converter produces a file that is typically far smaller, plays on modern devices and browsers, imports into any editor, and fixes the audio sync problems that came from AVI's handling of variable bitrate audio. There is essentially no reason to keep video in AVI unless a specific piece of legacy software demands it.

WebM: the open web format

WebM was introduced by Google in 2010 as a royalty free format for the open web. It is technically a restricted subset of Matroska, deliberately limited to a small set of codecs so that browsers can implement it completely and predictably. It carries VP8, VP9, or AV1 video with Vorbis or Opus audio, and nothing else.

Its advantages are real. It is free of patent licensing concerns, which is why browser vendors adopted it enthusiastically. VP9 and AV1 produce substantially smaller files than H.264 at the same quality. And it is the native output of browser based recording, so if you record your screen or your webcam through a web application, WebM is very often what you get.

Its disadvantage is everything outside the browser. Most video editors will not import WebM. Many social platforms reject it. Older devices, televisions, and media players do not recognize it. Safari support arrived late and remains less complete than in Chrome and Firefox.

The consequence is a very common workflow problem: you record something in a browser tool, receive a WebM, and then discover that the client, the editor, or the platform will not take it. Converting with a WebM to MP4 converter resolves it. This one usually does require a genuine re-encode, since VP9 and AV1 cannot simply be moved into an MP4 and expected to play everywhere, so use a good quality setting and keep the original WebM in case you need to export again.

Side by side

Codecs: H.264, H.265, VP9, and AV1

The container decides where a file will open. The codec decides how big it is, how long it takes to make, and how good it looks. Four codecs cover almost everything you will meet.

H.264 (AVC)

Standardized in 2003 and still the most widely deployed video codec in the world. Every device with a video decoder made in the last fifteen years handles H.264 in hardware. It is fast to encode, fast to decode, and produces perfectly good quality at reasonable bitrates.

It is not the most efficient codec available, and that no longer matters much for most purposes. Storage and bandwidth are cheap relative to the cost of a file that will not play. H.264 remains the correct default for anything you are handing to another person.

H.265 (HEVC)

The successor to H.264, delivering roughly the same visual quality at 40 to 50 percent of the bitrate. It also handles 4K, 8K, and high dynamic range far better, which is why phones now record in it by default.

The catch is licensing. H.265 patents are held by several pools with complicated terms, which made browser vendors reluctant to implement it. Chrome and Firefox support is limited and inconsistent. That is why a video recorded on a recent iPhone often refuses to play when uploaded somewhere: the container is fine, the H.265 inside is the problem. Converting the codec to H.264 fixes it at the cost of a larger file.

VP9

Google's royalty free answer to H.265, with broadly similar efficiency. It is what YouTube serves for most high resolution streams. Browser support in Chrome, Firefox, and Edge is complete, and Safari support is now reasonable. Hardware decoding is common on modern devices but less universal than H.264.

VP9 is a genuinely good choice for web delivery, particularly inside a WebM container with an MP4 fallback. It is a poor choice for a file you email to someone.

AV1

The current state of the art, developed by an industry consortium and released royalty free in 2018. It is roughly 30 percent more efficient than H.265 and VP9, which makes it about half the size of H.264 at equivalent quality.

The trade is encoding time, which can be many times slower than H.264, and hardware decoder support that is now common on recent devices but absent on older ones. Streaming services use it heavily because they encode once and serve millions of times, which is exactly the situation where slow encoding does not matter. For individual files it is usually more effort than it is worth, unless size is the dominant constraint.

Audio Codecs and Subtitles

The audio stream gets far less attention than the video stream and causes a surprising share of playback failures.

The audio codecs that matter

• AAC is the standard partner for H.264 in MP4 files. It is efficient, universally supported, and the correct default at 128 to 192 kbps for stereo.
• MP3 still appears in older files. It is less efficient than AAC at the same bitrate but plays absolutely everywhere.
• Opus is the modern royalty free choice and is genuinely excellent, particularly at low bitrates for speech. It lives in WebM naturally and increasingly in MP4.
• AC-3 and DTS are surround sound formats found in films and MKV rips. They frequently fail on devices expecting stereo, and are a common reason a file plays with no sound.
• PCM is uncompressed audio found in professional MOV and AVI files. Perfect quality, enormous size.

If a video plays with picture but no sound, the audio codec is nearly always the cause. Re-encoding just the audio track to stereo AAC resolves it without touching the video at all, which keeps the picture bit for bit identical.

Subtitles: embedded, burned in, or separate

There are three ways to attach subtitles to a video and they behave very differently.

• Soft subtitles are a separate track inside the container. They can be turned off, restyled, and searched. MKV handles them brilliantly, MP4 handles them inconsistently, AVI cannot handle them at all.
• Hard subtitles, also called burned in, are drawn permanently into the video pixels during encoding. They cannot be turned off or translated, but they appear on absolutely every player and every platform. This is what social media captions are.
• External files, typically .srt or .vtt, sit next to the video. Universally supported by desktop players and web video, but they get separated from the video file the moment anyone shares it.

For social media, burn them in. Most viewers watch without sound and platforms do not reliably display soft subtitles. For a personal media library, use soft subtitles in MKV. For a web page, use an external .vtt file with the video element.

How to Tell What Is Actually Inside a Video File

Since the extension tells you almost nothing, the useful skill is finding out what a file really contains before you decide what to do with it. Every operating system exposes at least some of this without extra software.

The quick checks

• On Windows, right click the file, open Properties, and look at the Details tab. It lists frame width and height, frame rate, data rate, total bitrate, and often the video and audio codec names.
• On macOS, select the file and press Command and I for Get Info, or open it in QuickTime Player and choose Show Movie Inspector, which reports format, codec, dimensions, and data rate.
• In VLC, on any platform, open Tools and then Codec Information. This is the most complete free option and shows every stream in the file individually.
• In a browser tool, many converters display the detected codec, resolution, duration, and bitrate as soon as you drop a file in, before any processing happens.

What to look for and what it means

Five values tell you almost everything you need. The video codec tells you where the file will play and how efficiently it was compressed. The resolution tells you the largest screen it can fill without softening. The frame rate tells you whether it is cinematic, standard, or high motion footage, and whether it is variable, which predicts sync problems. The bitrate tells you whether it is a capture file with headroom to spare or an already compressed delivery file with nothing left to give. The audio codec tells you whether silent playback on the recipient's device is likely.

A concrete example. A file called clip.mp4 reports H.265 video, 3840 by 2160, 60 fps variable, 96 Mbps, and AAC stereo audio. That is unmistakably a recent phone recording in its high efficiency mode. You now know three things without opening it: it will probably not play in a browser or upload cleanly to older platforms because of H.265, it has an enormous amount of bitrate headroom so it will compress dramatically, and the variable frame rate means you should force a constant frame rate on export to avoid drift.

Contrast that with a file reporting H.264, 1280 by 720, 30 fps, 1.8 Mbps, AAC. That is an already compressed delivery file. It will play anywhere, and there is very little size left to recover. Trying to compress it further will visibly damage it for almost no gain. Knowing this before you start saves you from a pointless export.

Things the container carries that people forget

• Rotation metadata. Phones record in one physical orientation and store a rotation flag. Players that respect the flag show the video upright, players that ignore it show it sideways. This is why a video looks correct on a phone and rotated on a desktop.
• Display aspect ratio. Some formats store non square pixels, so the stored resolution and the intended display shape differ. Legacy DVD and broadcast sources do this constantly.
• Color space and transfer characteristics. HDR and log footage carry tagging that tells a player how to interpret the pixel values. Strip or mislabel it and the picture looks grey and washed out.
• Timecode. Professional formats store an absolute time reference used to sync multiple cameras. Delivery formats drop it, which is one reason you never edit from delivery files.

These are all container level metadata rather than pixel data, which means they can be corrected without re-encoding. A sideways video usually needs a rotation flag fixed, not a re-render.

Choosing the Right Format for Your Situation

Format choice is entirely determined by what happens to the file next. Work backward from the destination.

Sending a file to a person

MP4 with H.264 and AAC. Every time, without thinking about it. The recipient might be on a ten year old Android phone, a locked down work laptop, or a smart television. H.264 in MP4 is the only combination that survives all of those. The modest size penalty against H.265 is worth far less than the file working on the first attempt.

Embedding video on a website

Provide two sources in your video element. Put a WebM file with VP9 or AV1 first, then an MP4 with H.264 as the fallback. Browsers pick the first source they can play, so modern browsers take the smaller file automatically and older ones fall back safely. Make sure the MP4 has faststart enabled so playback begins before the download completes.

Uploading to social platforms

MP4 with H.264, at the highest quality you can reasonably upload. Every platform re-encodes what you send, so your file is the source material for their encoder rather than the final product. Give it good input. Burn captions into the picture rather than relying on subtitle tracks.

Editing

Whatever your camera produced, ideally MOV with ProRes or a similar intermediate codec if the project is large. Editing directly from heavily compressed delivery files is slow, because every frame has to be reconstructed from surrounding frames, and it degrades further with each export.

Long term archiving

MKV with the highest quality video you have, all audio tracks, and all subtitles. This is exactly what MKV was designed for. Store the original camera files too if you have room. Storage is cheaper than the footage you cannot recreate.

Email attachments

MP4 with H.264, trimmed short and compressed hard. Most mail systems cut off between 10 and 25 MB. If the video cannot fit, the correct answer is a link rather than a mangled attachment.

Converting Safely: Remux vs Re-encode

This is the section that saves the most time and quality, because most people re-encode when they did not have to.

Remuxing: changing the box only

If the codec inside a file is already acceptable for the destination, and only the container is wrong, the streams can be copied directly into a new container without being decoded. This is remuxing. The video data is unchanged, bit for bit. There is no quality loss whatsoever, and the operation is limited by disk speed rather than processor speed, so a gigabyte file finishes in a few seconds.

Remuxing is possible far more often than people realize:

• MKV containing H.264 into MP4. Very common, because most MKV files hold H.264 or H.265.
• MOV containing H.264 into MP4. This covers essentially every video an iPhone records in its compatibility mode.
• MP4 into MKV, when you need to add subtitle or audio tracks that MP4 handles poorly.
• Adding faststart to an existing MP4 so it streams properly.

If a conversion completes in seconds, it was a remux and nothing was lost. If it takes minutes and your processor fans spin up, it re-encoded.

Re-encoding: rebuilding the picture

When the codec itself has to change, every frame must be decoded back to pixels and compressed again with the new codec. This always loses some quality, because the new encoder is making fresh decisions about what to discard, and it cannot recover detail the first encoder already threw away.

Re-encoding is genuinely required when:

• Converting VP9 or AV1 from WebM into MP4 for compatibility.
• Converting H.265 to H.264 because the destination cannot decode HEVC.
• Converting old AVI codecs such as DivX, Xvid, or MJPEG to anything modern.
• Changing resolution, frame rate, or bitrate.
• Burning subtitles into the picture.

Limiting the damage when you must re-encode

• Always start from the best source. Never convert a file that has already been converted. Go back to the original.
• Use a high quality setting. A CRF around 18 to 20 for H.264 is visually lossless for practical purposes and still produces a reasonable file.
• Do everything in one pass. If you need a format change and a resize and a trim, do them in a single operation rather than three sequential exports.
• Copy the audio when you can. If the audio codec is already fine, leave it untouched rather than re-encoding it alongside the video.
• Keep the original. Until you have confirmed the converted file works where it needs to, do not delete the source.

If the reason you are converting is size rather than compatibility, the settings that control that are a separate subject with its own reference tables, covered in How to Compress a Video Without Losing Quality.

Where the conversion happens

Browser based conversion tools now run the encoder locally through WebAssembly, so the file is read from your disk, processed on your own processor, and written back out without ever being uploaded. For most format conversions this is both faster than a server based tool, because there is no upload wait, and considerably safer for anything you would not want sitting on a stranger's server.

Diagnosing Playback Problems

When a video will not play, the symptom tells you which layer failed. Work through these in order.

The player refuses to open the file at all

Container problem. The player does not recognize the wrapper. Most common with MKV in browsers and consumer devices, and with WebM outside browsers. Remux to MP4 and try again.

Sound plays but the picture is black or missing

Video codec problem. The container opened fine and the audio decoded, but the video stream is something the device cannot handle. Usually H.265 or AV1 on hardware that only supports H.264. Re-encode the video to H.264.

Picture plays but there is no sound

Audio codec problem, and the usual culprits are AC-3, DTS, or a surround configuration the device cannot downmix. Re-encode only the audio to stereo AAC and leave the video stream copied untouched.

The video stutters or the device gets hot

The codec is being decoded in software because there is no hardware decoder for it. The file is playing, just inefficiently. Converting to H.264 usually restores smooth playback immediately.

Audio slowly drifts out of sync

Almost always a variable frame rate source, or an AVI file with variable bitrate audio. Re-encoding with an explicit constant frame rate fixes it. This is one of the strongest arguments for converting old AVI archives.

The video will not start until it fully downloads

The MP4 index is at the end of the file. Enable faststart, which relocates it without re-encoding anything.

An editor refuses to import the file

Either the container is unsupported, which is common for MKV and WebM, or the codec is a delivery format the editor does not want to work with. Convert to MP4 with H.264, or better, to MOV with an intermediate codec if you are doing serious editing work.

Frequently Asked Questions

The Short Version

Video formats look complicated because one word, format, is doing two jobs. Separate the container from the codec and the whole subject collapses into something manageable. The extension tells you the box. The codec tells you the compression. A file fails to play when a device rejects either one, and knowing which one failed tells you exactly what to fix.

For practical purposes: edit in MOV, archive in MKV, deliver in MP4, embed WebM on the web with an MP4 fallback, and convert AVI files out of existence. Check whether a conversion can be a remux before letting a tool re-encode, because a great many of them can, and a remux is free in every sense that matters. Everything else is refinement.