Formats & Codecs

Containers, codecs, and serving multiple sources

Containers vs. codecs

Two terms are often confused when people discuss video files: container and codec. Understanding the distinction is key to making good format decisions.

The container

A container (also called a file format or wrapper) is the outer structure of a media file. It defines how data is stored on disk: where the video stream is, where the audio stream is, where any metadata or subtitle tracks live, and how they are all synchronised in time. Common container formats on the web are MP4 (.mp4), WebM (.webm), and Ogg (.ogg / .ogv).

The codec

A codec (from coder–decoder) is the algorithm used to compress and decompress the raw video or audio data that lives inside the container. A codec is not a file format — it is a mathematical procedure. The same container can legally hold different codecs: an MP4 file can contain H.264 video or H.265 video, for example.

Analogy: Think of the container as a box and the codecs as the packing method used for the contents inside. Two boxes of the same shape (MP4) can use completely different methods to compress what is stored in them (H.264 vs. H.265). The box alone does not tell you how the contents are packed.

This matters for the web because a browser must support both the container and the specific codec inside it before it can play the file. A browser that understands the MP4 container but lacks a decoder for the codec inside cannot play the file. The type attribute on <source> lets you declare both at once so the browser can skip incompatible files without downloading them.

Common web codecs

The web has converged on a small set of codecs. Here are the ones you will encounter most often, along with their typical containers and support story.

Video codecs

  • H.264 / AVC — The workhorse. Supported by every browser, operating system, and hardware decoder made in the last decade. File sizes are reasonable but not cutting-edge. Used inside MP4 containers. If you only encode one format, encode H.264+AAC in an MP4.
  • VP9 — An open, royalty-free codec from Google. Produces files roughly 30–50% smaller than H.264 at equivalent quality. Supported in Chrome, Firefox, and Edge; also supported in Safari 14+. Lives inside WebM containers.
  • AV1 — The next-generation open codec from the Alliance for Open Media. Best compression of the three — often 30% smaller than VP9 — but encoding is significantly slower and hardware decode support is still growing (present in most post-2021 chips). Supported in Chrome 70+, Firefox 67+, Safari 16+. Also lives inside WebM (or the newer MP4 container in some toolchains).

Audio codecs

  • AAC (Advanced Audio Coding) — The standard audio companion to H.264 in MP4 containers. Near-universal support. Better quality per kilobit than MP3.
  • MP3 — Universally understood; still a safe fallback for audio-only files, though AAC surpasses it at equivalent bitrates.
  • Opus — Open, royalty-free, and used inside WebM containers. Excellent for speech and music alike; very efficient at low bitrates. Supported in all modern browsers.
  • Vorbis — The older open codec used in Ogg containers. Largely superseded by Opus but still encountered in legacy content.

Container summary table

Container Typical video codec Typical audio codec Browser support / use case
MP4 (.mp4) H.264 / AVC AAC Universal — every browser, every platform. Your safe default and required fallback.
WebM (.webm) VP9 or AV1 Opus All modern browsers (Chrome, Firefox, Edge, Safari 14+). Smaller files — serve this first to modern clients.
Ogg (.ogv / .ogg) Theora Vorbis Legacy Firefox fallback; not needed for new projects. Theora quality is poor vs. VP9/H.264.

Serving multiple sources

Because no single format reaches 100% of browsers and devices, you should supply the same video encoded in at least two formats. The browser reads the <source> list in document order, inspects the type attribute, and uses the first entry it can decode without making a network request for any of the ones it skips.

List the more efficient format (WebM) first so modern browsers get the smaller file, and keep MP4 as the last entry to catch everything else.

<video controls poster="../assets/poster.jpg" width="480" height="320"> <!-- WebM first: smaller file for modern browsers --> <source src="../assets/sample-video.webm" type="video/webm"> <!-- MP4 fallback: universal support --> <source src="../assets/sample-video.mp4" type="video/mp4"> <p>Your browser cannot play this video. <a href="../assets/sample-video.mp4">Download the file</a>. </p> </video>

The codecs parameter

The type attribute can optionally carry a codecs parameter that names the exact codec profile inside the container. This gives the browser even more precise information before it decides to use a source, which matters when a browser supports a container but only some of its codec profiles.

<!-- Precise form with codecs parameter --> <source src="../assets/sample-video.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' >

The codec string avc1.42E01E identifies H.264 Baseline Profile, Level 3.0; mp4a.40.2 identifies AAC-LC audio. In practice, the short form (type="video/mp4") is sufficient for the vast majority of projects. The long form is most useful when serving AV1 or a specific H.264 profile to devices where hardware decoding support varies.

Choosing a format strategy

For video

A pragmatic two-format strategy covers nearly every user on the web today:

  1. Encode your video as WebM (VP9 + Opus) — this is the primary delivery format for modern browsers and produces significantly smaller files.
  2. Also encode as MP4 (H.264 + AAC) — this is the universal fallback that covers older Safari, older iOS, and any environment where WebM is not supported.

If you have the encoding budget and your audience skews toward modern hardware, replace VP9 with AV1 in the WebM track for further file size savings — AV1 typically cuts 30% off VP9 at equivalent quality. The MP4 fallback remains unchanged.

For audio

For audio-only files, MP3 is universal and always safe. For new projects targeting modern browsers, consider offering Opus in an Ogg or WebM container as the primary source — Opus is measurably smaller and higher quality at the same bitrate, especially for speech. List Opus first, MP3 second:

<audio controls> <source src="../assets/sample-audio.ogg" type="audio/ogg"> <source src="../assets/sample-audio.mp3" type="audio/mpeg"> </audio>

The same "supply multiple, let the browser pick" principle applies to images — for a deeper look at how <picture> and <source> work for image formats (WebP, AVIF, JPEG), see Images Tutorial 05: Choosing a Format.