Video File Types: MP4, WebM, MKV, MOV, and Codecs

Video file types such as MP4, WebM, MKV, and MOV describe containers: how video, audio, subtitles, and metadata are packaged. They do not, by themselves, tell you whether a browser can play the file. The codecs inside the container matter too. If you need one starting point for ordinary web playback, use an MP4 containing H.264 video and AAC audio, then test it on the browsers and devices you support. MDN recommends this combination for broad browser compatibility, but it is not a promise that every MP4 will play everywhere.

This is a starting guide, not a claim that one container always wins. A platform's upload specification or an editor's delivery requirements take precedence over a general recommendation.

Container versus codec: the two decisions inside a file

The container is the outer file structure. It holds one or more streams and associated information: video, audio, subtitles, timing, and metadata. The codec determines how an individual stream is encoded and decoded. For example, .mp4 identifies a likely MP4 container; H.264 and AAC identify the video and audio codecs that may be inside it. An MP4 could instead contain another video codec, so its extension alone is not enough to predict playback.

Think of compatibility as an intersection: the destination must accept the container, each codec, and the particular stream properties being used. A browser may support H.264 in MP4 yet reject a different codec in an MP4. An upload service can also accept the extension but fail later during processing. MDN's container guide distinguishes file types from the codecs they carry and documents the relevant media types, including video/mp4 and video/webm.

Compression is a separate trade-off. Changing the codec can alter file size, visual quality, encoding time, and decoding requirements. Changing only the container normally does not make the encoded picture smaller or better. If a file must be resized or its codec changed, it needs a transcode, not a rename.

What MP4, WebM, MKV, and MOV are good for

MP4 is a sensible first delivery format for web video because an MP4 with H.264 video and AAC audio is broadly supported by major browsers. The pairing is more important than the .mp4 suffix. Check the actual video profile, pixel format, audio, and target devices before calling an export compatible. MP4 can carry other codecs, including AV1, but support for a specific file still depends on the decoder and environment. MDN's codec guide covers these combinations and their compatibility considerations.

WebM is a web-oriented container based on a subset of Matroska. VP8 or VP9 video with Vorbis or Opus audio are combinations described by the WebM Project's container guidelines; MDN also lists AV1 in WebM. WebM can be useful as an additional browser-delivery version, but do not assume a file will play solely because its extension is .webm. Test the actual codec pair in your supported clients. If you publish two versions, an HTML <video> element can offer separate sources; MDN shows how browsers select a supported source.

MKV, the Matroska container, is useful when you need multiple audio or subtitle tracks, chapters, attachments, or richer track metadata. Matroska's format documentation describes those elements. That flexibility makes it a good working or retention format in some pipelines, but MKV is not automatically an archival format. The codec, availability of decoders, integrity checks, backups, and retention of the original all matter. It is not a default choice for an HTML video intended to play in a browser without additional processing.

MOV is the QuickTime container and is common in camera and editing workflows. It is related to, but not interchangeable with, MP4. A MOV can contain different video and audio streams; selecting it does not guarantee a better editing codec or higher image quality. Use it when the receiving editor, camera pipeline, or handoff specification calls for it. MDN documents QuickTime and MP4 as distinct containers.

Older files may arrive as AVI, MPEG, or other containers. You do not need to convert every old file simply because the extension is old. First determine whether your tools can read its streams and whether a new delivery format is actually required.

Inspect a file before converting it

ffprobe reports what the file contains. This read-only command prints JSON with container details and every stream, including codec names, dimensions, and audio tracks:

ffprobe -v error -show_format -show_streams -of json input.mov

Look for format_name under format, then inspect each stream's codec_type and codec_name. A video stream also reports dimensions; audio, subtitle, and attachment streams may be present too. The official ffprobe reference documents -show_format, -show_streams, and JSON output. Metadata in media files can contain personal or location information, so review it before publishing probe output or the original file.

Do not use a filename or a browser error alone to decide what to change. If a video will not play, check whether the destination rejects the container, one of its codecs, or a stream property. If an upload fails, compare the file's observed properties with that service's current requirements. An upload failure does not prove the video bytes are damaged.

Remux when the encoded streams already fit

A remux moves encoded streams into a different container without decoding and encoding them again. It is generally faster than transcoding and avoids another lossy encoding pass. This example selects the first video stream and, if present, the first audio stream from an MKV and writes them to MP4:

ffmpeg -i input.mkv -map 0:v:0 -map '0:a:0?' -c copy output.mp4

The optional ? means the command can still run when there is no audio stream. The explicit maps also mean that extra audio, subtitle, and attachment tracks are not carried over. Choose and map additional tracks deliberately if they are required. Most importantly, stream copy works only if the output container can carry the selected encoded streams. If FFmpeg rejects a stream or the result still does not play on the target, use a suitable transcode or a different destination container; changing the filename extension will not fix it. The FFmpeg stream-copy documentation explains both the no-reencode behavior and its limits.

For a normal MP4 delivered as a progressively downloaded file, +faststart moves its movie index toward the beginning. It changes packaging, not video quality:

ffmpeg -i input.mp4 -map 0:v:0 -map '0:a:0?' -c copy -movflags +faststart output.mp4

This is useful for a conventional, non-fragmented MP4 served over HTTP. It is not a general speed boost for every player or every streaming protocol, and FFmpeg notes that faststart does not work in some situations, including fragmented output. See the MP4 muxer documentation.

Transcode when the codec must change

A transcode decodes and re-encodes a stream. Use it when the target cannot decode the existing video or audio, or when you need to change resolution, frame rate, or another property that stream copy cannot change. The following example produces an MP4 with H.264 video and AAC audio, selecting only the first video and optional first audio stream:

ffmpeg -i input.mov -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 -crf 23 -preset medium -pix_fmt yuv420p \
  -c:a aac -movflags +faststart output.mp4

This command requires an FFmpeg build with the libx264 encoder. -crf 23 is an example quality setting, not a universal target; inspect the result and adjust for your source and delivery needs. The command omits extra tracks by design. Do not discard a source file until you have checked the output's picture, sound, duration, and any required subtitles. FFmpeg's transcoding and stream-mapping reference explains why re-encoding can cost time and, for lossy codecs, quality.

After either operation, run ffprobe again on the output and play it in the actual destination. A successful FFmpeg exit confirms that a file was written; it does not certify that your browser, editor, or upload service accepts it.

A simple format policy for uploads and delivery

Keep the received original, record what ffprobe found, and produce a separate delivery copy when necessary. An extension check can be an early filter, but inspect the file itself before deciding which conversion path to use. Preserve the source so a new export can be made if a destination changes its requirements.

For a website, begin with the MP4/H.264/AAC combination, then add WebM only if testing or delivery goals justify a second version. For an editor or platform upload, follow that destination's published specification, including audio, captions, and color requirements. For retention, do not treat .mkv or any other extension as a backup plan: keep the original, document its streams, and verify stored copies can still be read.

The most useful habit is to name the container and the video and audio codecs whenever you describe a file. “MP4 with H.264 and AAC” is actionable; “video file” or even “MP4” leaves the important compatibility question unanswered.