Container vs Codec: MP4, MOV, MKV and H.264 Decoded
By Mark Fulton · 2026-09-18 · 11 min read
The file extension names the box, not the contents. MP4, MOV, MKV and WebM are containers: wrappers that hold a video track, an audio track, subtitles, timestamps and an index, all interleaved so a player can read them together. H.264, H.265, VP9 and AV1 are codecs: the compression applied to the picture inside that wrapper. MP4 is a container. H.264 is a codec. That is why "MP4 vs MKV" and "H.264 vs H.265" are not two versions of the same question, and why two files that both end in .mp4 can behave completely differently on the same TV. Two things follow from that one distinction. Changing the box can be instant and lossless, because the compressed data is copied across untouched. Changing the contents cannot, because every frame has to be decoded and compressed again. Almost every "why won't this play" problem is a contents problem wearing a box's name.
Once that clicks, a long list of confusing symptoms collapses into one question: is the thing that is broken the wrapper, or the codec inside it?
What is a container and what is a codec?
A container is a file format whose job is organisation, not compression. MDN's reference on media container formats defines one as "a file format that encapsulates one or more media streams (such as audio or video) along with metadata, enabling them to be stored and played back together". It stores the track list, the timestamps that keep audio in sync with picture, chapter marks, subtitle tracks, rotation flags, and an index that tells a player where to jump when you drag the scrubber.
It does not compress anything. The Matroska project is blunt about this on its own what is Matroska page, describing the format as "an envelope for which there can be many audio, video and subtitles streams" and stating flatly that "it is NOT a video or audio compression format (video codec)".
The codec is the part that does the compressing. Raw video is enormous, so an encoder throws away what your eye is least likely to miss and writes what is left as a compressed bitstream. A decoder on the other end turns that bitstream back into frames. When something refuses to play your file, it is nearly always because it has no decoder for the codec inside, and not because it dislikes the four letters after the dot.
Family relationships explain some of the weirdness here. MDN notes that the MP4 file format "is derived from the ISO base media file format, which is directly derived from the QuickTime file format developed by Apple". MOV and MP4 are close cousins at the structural level, which is exactly why converting between them is so often quick, and why a .mov from an iPhone frequently just works when you rename the workflow around it.
The term decoder
Seven words cause most of the confusion. Here is the one sentence that makes each one click, and the symptom it explains.
| Term | The sentence that makes it click | The symptom it explains |
|---|---|---|
| Container | The box and its packing list: MP4, MOV, MKV, WebM, AVI. | An upload form rejects your file before it has looked inside it. |
| Codec | The compression used on the picture or sound: H.264, H.265, VP9, AV1, AAC, Opus. | The file opens, the timeline runs, and you get audio with a black frame. |
| Stream (track) | One continuous thing inside the box: this video track, that audio track, those subtitles. | A file plays with the wrong language, or an editor imports picture but no sound. |
| Rewrap (remux) | Lifting the already compressed tracks out of one box and setting them down in another, untouched. | A conversion that finishes in about a second and loses nothing. |
| Transcode (re-encode) | Decoding every frame and compressing it again, usually with a different codec. | A conversion that takes real time, heats your laptop, and costs a generation of quality. |
| Bitrate | How many bits per second the encoder is allowed to spend on the picture. | Blocky motion on a file that looked fine while still, and file size you can predict. |
| Profile and level | Which optional features the encoder used, and how demanding the result is to decode. | H.264 in an MP4 that still fails on one old device while playing everywhere else. |
The last row is the one almost nobody explains, and it is the reason "just use H.264 MP4" occasionally still fails. More on that next.
Why does the same extension behave differently?
Because MP4 is a permissive box. MDN's container reference lists AVC (H.264), AV1 and VP9 as video codecs an MP4 can carry, and AAC, FLAC, MP3 and Opus on the audio side. Nothing about the .mp4 extension tells you which of those you are holding. Two files with the same icon, the same extension and the same duration can contain entirely different bitstreams, and the device at the other end only cares about the bitstream.
So the failure modes sort themselves neatly:
Sound but no picture. The device decoded the audio codec and could not decode the video codec. This is the classic AV1 or H.265 file on hardware built for H.264.
Picture but no sound. The reverse. An Opus soundtrack legally sits inside an MP4, but a set-top box that only ever expected AAC will play the video silently.
The file will not open at all. Usually the container, not the codec. Something in the chain refuses MKV or WebM on sight, before parsing a single frame.
It plays on your laptop and not on your TV. Same codec, different decoder capabilities. This is where profiles and levels live. MDN's web video codec guide, last modified 7 September 2026 and checked on 18 September 2026, describes AVC as "highly flexible, with a number of profiles with varying capabilities", and lists profiles from Constrained Baseline through Main, High, High 10 and the 4:2:2 and 4:4:4 variants, with supported bit rates and frame sizes varying by level. A cheap media player may implement High profile up to a certain level and nothing beyond it. Hand it a 10-bit High 10 file and it will fail, even though "H.264 in an MP4" is a true description of what you sent.
For the codec layer itself, the same MDN guide gives AVC the broadest support statement of any video codec on the page: "All versions of Chrome, Edge, Firefox, Opera, and Safari", with the caveat that Firefox leans on the operating system's own AVC decoder for patent reasons. That breadth is the entire practical argument for H.264, and H.264 vs H.265 works through where the newer codec earns its place and where it quietly costs you a viewer.
What is rewrapping and why is it instant?
Rewrapping, also called remuxing, means opening the source file, pulling the compressed packets out, and writing them into a different container without touching a single frame. The FFmpeg documentation describes its stream copy mode precisely: "Streamcopy is useful for changing the elementary stream count, container format, or modifying container-level metadata. Since there is no decoding or encoding, it is very fast and there is no quality loss."
That is the whole trick. No decoding, no encoding, so the work is roughly the speed of copying the file. A transcode, by contrast, decodes every frame and compresses it again, which takes real processing time and costs you a generation of quality no matter how good the settings are. If you want the arithmetic behind what that re-encode actually produces, video compression by the numbers lays out how bitrate and duration set the file size.
The limit on rewrapping is what the destination box is allowed to carry. Not every codec is legal in every container, and when it is not, the copy simply fails instead of producing something broken. I tested that pairing in both directions while writing WebM vs MP4: VP9 video with Opus audio stream copied into an MP4 successfully, while VP8 with Vorbis was refused outright because MP4 has no tag for that codec. The MOV case is the friendlier one, since MOV and MP4 share their structural ancestry, and converting MOV to MP4 covers how to tell a rewrap candidate from a file that genuinely needs re-encoding.
Here is the part worth saying plainly, because it cuts against selling you something. VidClip does not have a rewrap button. Its converter re-encodes, producing H.264 video at CRF 21 with AAC audio and the index moved to the front of the file. That is a deliberate choice rather than a missing feature: rewrapping only fixes box-level problems, and the box is rarely what broke. Copying a VP9 track into an MP4 wrapper gives you a file that claims to be an MP4 while still holding a codec your TV cannot decode, which turns an obvious failure into a confusing one. The stream copy paths that do exist on the site are the Pro lossless trim and the Pro mute, both of which copy the video track untouched rather than re-encoding it.
Which container should you keep files in?
MP4 for anything that leaves your machine. Editors, phones, TVs, chat apps, upload forms and mail clients all read it without a conversation. This is the default and you need a specific reason to deviate.
MOV if it is a camera or editing master on the Apple side. ProRes and similar intermediates live in MOV, and re-boxing them gains you nothing while risking metadata. Keep the master, export MP4 copies.
MKV if you are archiving. Matroska is the most capable box on this list, holding as many video, audio and subtitle tracks as you want in one file, and the project publishes its bitstream specification openly. The trade is reach: MKV is not a web container, browsers do not treat it the way they treat MP4, and plenty of upload forms and devices refuse it on sight.
WebM only for a web page you control. It is excellent at that one job and awkward everywhere else.
AVI for nothing new. It exists because old files exist.
The general rule: keep whatever is closest to the original recording as your master, and make MP4 copies for everything you send. Every conversion after the first is a further generation away from what the camera saw.
How do you find out what's inside your file?
You cannot tell from the extension, so check. Four ways, cheapest first:
- VLC. Open the file, then Tools, then Codec Information (Ctrl+J on Windows, Cmd+I on macOS). It names the container and each track's codec, resolution and frame rate.
- QuickTime Player on macOS. Window, then Show Movie Inspector, for a quick summary of format and dimensions.
- File properties. Right click, Properties, Details on Windows, or Get Info on macOS, gives you a partial answer: dimensions and duration reliably, codec sometimes.
- ffprobe, if you have FFmpeg installed and want the whole truth in one line:
ffprobe -v error -show_entries stream=index,codec_type,codec_name,profile,width,height -of default=noprint_wrappers=1 yourfile.mp4
That prints one block per track, and the codec_name and profile fields are exactly the two values that decide whether a given device will play the file.
One more diagnostic worth knowing: drag the file into a browser tab. Browsers ship decoders for H.264, VP8 and VP9, and current versions handle AV1 as well, so if it plays there and fails in your editor, the file is intact and you have a decoder problem, not a corruption problem.
When you have identified an exotic codec and you want it to stop being a problem, you can convert the file into a universal H.264 MP4 here. It runs FFmpeg compiled to WebAssembly inside the page, so the file is read from your disk into browser memory and processed on your own CPU, with no upload and no queue. It re-encodes rather than rewrapping, for the reason given above, and the output is the H.264 plus AAC combination that decodes on the widest range of hardware there is. The free tier accepts files up to 200 MB and places a small mark in the corner of video exports. Pro removes both, and adds exact-target-size compression, instant lossless trim and mute, contact sheets and the settings advisor, at $4 a month billed $24 every six months, or $79 once for life.
Frequently asked questions
Is MP4 a codec or a container?
A container. MP4 describes how tracks, timestamps and metadata are arranged in the file, not how the picture is compressed. The codec inside a typical MP4 is H.264, but MDN's container reference lists AV1 and VP9 as legal MP4 video codecs too, alongside AAC, FLAC, MP3 and Opus for audio. That is why "MP4" tells a device almost nothing about whether it can play your file.
Why won't my MP4 play on my TV?
Because the TV has no decoder for the codec inside it, or for the specific profile that codec used. The usual culprits are H.265 or AV1 video on a set built for H.264, an audio track in a codec the TV never expected, or a 10-bit or 4:2:2 H.264 file that exceeds what the TV's decoder implements. Check the file with VLC or ffprobe first, then re-encode to H.264 with AAC audio if the codec is the problem. Renaming the file or changing its container will not help, because the TV never looked at the extension.
Is MKV better than MP4?
Better at different things. Matroska is the more capable container, holding an effectively unlimited number of video, audio and subtitle tracks in one open, publicly specified file, which makes it the stronger archive format. MP4 is the more useful container, because it is what browsers, phones, editors and upload forms are built around. Neither affects picture quality, since quality is decided by the codec and the bitrate inside. Archive in MKV if you like; send MP4.
Can you change container without re-encoding?
Often, yes. That is a rewrap, and FFmpeg's documentation describes stream copy as very fast with no quality loss, precisely because nothing is decoded or encoded. The constraint is legality: the destination container has to accept the codec you are moving. VP9 can sit in an MP4, VP8 cannot, and a copy that is not allowed fails rather than producing a broken file. Worth remembering, though, that a successful rewrap only changes the label. If the reason your file would not play is the codec, the rewrap has moved the problem rather than fixed it, and a real re-encode is what you actually needed.