Container vs Codec — Explained in Plain English

While building the in-browser audio/video converter at tools.beer, we kept running into the same confusion: someone drags in a .mp4 and asks "why do I hear nothing after I rename it to .mp3?", or "why won't this mp4 play on my computer?".

Almost every one of those questions comes from mixing up two things: the container and the codec. Let's clear it up with the simplest possible mental model.

1. The analogy: a shipping box vs how you pack it

Think of a media file like shipping a parcel:

• The container is the box. It just holds things together, carries the label, and makes the parcel easy to move.
• The codec is how the contents are packed and compressed. The same box can hold cargo packed in very different ways.

A file is the same: a .mp4 is the "box", and inside it usually sits one video stream and one audio stream, each compressed with some codec.

2. What the container actually does

Common containers are MP4, MKV, MOV, and WebM. They are all "wrappers":

• They decide how video, audio, and subtitle streams are stored and indexed.
• They decide whether a file can carry multiple audio tracks and subtitle languages.
• They do not decide how the picture or sound is compressed.

So two .mp4 files can look identical from the outside but contain completely different codecs inside — for example H.264 + AAC, or H.265 + Opus.

3. What the codec actually does

A codec is the real "compression algorithm", and it works in two directions:

• The encoder shrinks huge raw audio/video data (for example, turning raw camera data into H.264).
• The decoder expands it back so a player can show or play it.

Common video codecs: H.264, H.265/HEVC, AV1, VP9. Common audio codecs: AAC, MP3, FLAC (lossless), Opus.

Whether a file plays comes down to whether the player has the matching decoder — not the file extension.

4. Why confusing them costs you: a real bug we hit

The most instructive bug we hit at tools.beer shows exactly why the container matters.

When converting mp4→mp3, if you extract the audio into a bare .aac file, there is no container. A bare AAC stream carries no duration metadata, and some players misread the sample rate, so the audio plays at half speed with double the length (this is a well-known FFmpeg issue, trac #5448). Our fix was to remux the AAC into an M4A container (.m4a), which supplies the missing metadata.

Short version: without the right container, even a great codec fails.

5. Situations you have definitely seen

• Renaming does nothing: rename .mp4 to .avi and the H.264 inside is still H.264 — it still won't play if the player lacks the decoder.
• Plays on phone, not on PC: usually an unsupported codec like H.265, not the container.
• Conversion is slow and looks worse: you triggered a re-encode (codec change), not just a container swap. When to re-encode and when you can just swap the box is covered in re-encode vs stream copy.

6. Which container to pick (one-line advice)

• Maximum compatibility → MP4 (nearly universal support).
• Multiple audio tracks and subtitles → MKV.
• Web embedding → WebM / MP4.

For a deeper comparison, see how to choose common audio/video formats.

Summary

• The container is the box; the codec is how the contents are packed.
• Quality and size are decided by the codec; the container only wraps.
• Renaming a file never changes the codec, so it can't fix playback.
• Without a proper container, even a good codec can break.

To learn the whole picture, start from the complete guide to audio/video conversion: from container to codec. To try it right now, you can convert MP4 to MP3 in your browser.

Further reading

• The complete guide to audio/video conversion: from container to codec
• How to choose common formats? MP4 / MKV / WebM / MOV
• Lossless vs lossy: what is the real difference?
• Re-encode vs stream copy: why conversion sometimes gets slow or blurry

References (authoritative sources)

Written by the tools.beer team, based on real lessons from building an in-browser FFmpeg converter. Last updated 2026-08-20.