HTML5 Audio and Video: Supported Formats, Source Elements, Controls, and Fallback Content

The <audio> and <video> elements embed sound and moving pictures directly in a page with no plugin and no third-party player. You point the element at a media file — either with a src attribute or with one or more <source> children — add controls so the visitor gets a play button, and the browser plays the first file it knows how to decode.

Two ways to point at a file

The short form puts the URL on the element itself: <video src="tour.mp4" controls></video>. The flexible form leaves src off the element and lists candidates as <source> children instead, so you can offer the same clip in more than one format:

<video controls width="640" height="360" poster="cover.jpg">
  <source src="tour.webm" type="video/webm">
  <source src="tour.mp4" type="video/mp4">
</video>

The browser walks that list in document order and stops at the first source it can play, so the order you write is your order of preference. The type value is a MIME type — optionally with a codecs parameter, like type="video/mp4; codecs=avc1.42E01E" — and it lets the browser rule out a format without requesting the file at all. Leave type off and the browser has to fetch the resource and inspect it before it can decide.

One rule worth memorizing: the two forms do not combine. If the <video> or <audio> element carries its own src, the browser loads that URL and never consults the <source> children. HTML's content model reflects this — <source> children are only permitted inside a media element that has no src attribute, so writing both is a conformance error even though browsers render the page without complaint.

Formats you can count on

• MP4 — video/mp4. H.264 video with AAC audio; the safest single choice for broad support.
• WebM — video/webm. Open format, VP8 or VP9 video with Vorbis or Opus audio.
• Ogg — video/ogg. Older open format and the least widely supported of the three.
• MP3 — audio/mpeg. Not audio/mp3: an MP3 file is a stream of MPEG-1 Audio Layer III frames, so MP3 is the exception to the extension-matches-type pattern.
• WAV — audio/wav (audio/wave is the preferred registered spelling). Uncompressed, so files are large.
• Ogg audio — audio/ogg. Vorbis or Opus.

Controls and friends

controls tells the browser to draw its default play, seek, and volume interface. It is a boolean attribute: writing it at all turns it on, so controls="false" still shows controls, and the only way to hide the player is to omit or remove the attribute. The same rule governs autoplay, loop, muted, and playsinline.

Other useful attributes are preload, which takes none, metadata, or auto (an empty value means auto) and is only a hint the browser may ignore; poster, a placeholder image for video; and width and height, which exist on <video> only and take absolute CSS pixel numbers, never percentages. An <audio> element without controls renders nothing visible at all.

Fallback content is for old browsers

Text or markup between the opening and closing tags is fallback content, shown only by browsers that do not understand the element at all. It is not an error message for a failed download or an unsupported codec — the specification tells supporting user agents not to show it. When loading fails, the media element fires an error event, and displaying a message in response is your job in script. Captions go in <track> elements, which use WebVTT files and must come after any <source> children.

Ready to check yourself? Work the questions below, then keep going with the D276 Web Development Foundations study guide.

A worked example

Here is a video block that covers the realistic cases — two formats, a poster, captions, and fallback markup for a browser from another era:

<video controls preload="metadata" width="640" height="360"
       poster="lecture-cover.jpg">
  <source src="lecture.webm" type="video/webm">
  <source src="lecture.mp4" type="video/mp4">
  <track kind="captions" src="lecture-en.vtt" srclang="en"
         label="English" default>
  <p>Your browser can't play embedded video.
     <a href="lecture.mp4">Download the MP4</a>.</p>
</video>

Read that top to bottom the way the browser does: sources first (pick one), then tracks (load captions for the chosen video), then fallback content (ignore it, since I understand <video>). That order is not stylistic — the content model requires <source> children before <track> children.

Mistakes people actually make

• Treating fallback content as an error message. This is the single most common misreading. Fallback appears only when the element itself is unrecognized. A broken URL or an unsupported codec produces an empty player, not your friendly paragraph.
• Expecting autoplay to work. Browsers block autoplay of media with an audible track. Adding muted alongside autoplay is normally what lets playback start, which is why background hero videos are silent — though the exact policy varies by browser and by how much the user has interacted with the site.
• Writing audio/mp3. The registered type is audio/mpeg. Every other common format echoes its extension, so this one gets typed wrong constantly.
• Keeping src on the element after adding <source> children. The children become dead markup and the document stops conforming. Delete the src when you convert to the multi-source pattern.
• Forgetting controls on <audio>. The element occupies no visible space, so the page looks like nothing was added at all.
• Using percentages in width. Those attributes take absolute CSS pixel numbers; do responsive sizing in a stylesheet with max-width: 100%.

Reasoning about the tricky cases

When a question describes markup and asks what the user sees, resolve it in three steps. First ask which resource wins: an element-level src beats <source> children outright, and among children the first playable one wins. Then ask what is rendered: <video> always occupies a box, while <audio> shows something only with controls. Finally ask what the fallback is doing: in any modern browser, nothing.

Boolean attributes deserve one more pass, because they show up in disguised forms. controls, autoplay, loop, muted, and a <track> element's default are on when written and off when absent — the assigned value is never consulted, so removing the attribute is the only way to turn the feature off. By contrast, preload is an enumerated attribute whose value carries meaning: none, metadata, and auto give the browser different hints about how much to fetch up front, and the browser is free to ignore the hint.

When you want to confirm a detail, go to a primary source rather than a tutorial — the MDN reference for <video> is the fastest place to settle an attribute argument, and the WHATWG HTML standard's media chapter settles behavior questions. Then run more D276 practice questions to see whether the rule sticks.