Multimedia: the audio and video elements

Before HTML5, embedding video or audio required a third-party browser plugin (Flash, most commonly) — genuinely fragile, insecure, and eventually deprecated entirely. <video> and <audio> are native HTML elements that solved this properly. This part covers using them for real content, with the details that are easy to skip.

A real video: Bright Leaf Coffee's roasting process

<video controls width="800" height="450" poster="/images/roasting-poster.jpg">
  <source src="/videos/roasting-process.mp4" type="video/mp4" />
  <source src="/videos/roasting-process.webm" type="video/webm" />
  <track
    kind="captions"
    src="/captions/roasting-process-en.vtt"
    srclang="en"
    label="English"
    default
  />
  <p>
    Your browser doesn't support embedded video.
    <a href="/videos/roasting-process.mp4">Download the video</a> instead.
  </p>
</video>

• controls shows the browser's real, built-in play/pause/volume/fullscreen controls — omitting it removes all visible interaction, which is only appropriate for a genuinely decorative, silent background video
• poster is the still image shown before playback starts — real, useful for both perceived load speed and giving a visitor something meaningful to see before choosing to press play
• Multiple <source> elements let the browser pick whichever real format it actually supports — not every browser supports every video codec, and providing more than one is what keeps the video playable everywhere rather than silently failing in one browser while working in another
• <track kind="captions"> provides real, genuine captions from a .vtt file — not optional for a video with real spoken content; it's the direct video equivalent of alt text on an image, and default makes it active without a visitor needing to dig through a settings menu to enable it
• The fallback <p> only ever displays if the browser genuinely can't render <video> at all — real, functioning content instead of a silent failure

A real audio example

<audio controls>
  <source src="/audio/founder-interview.mp3" type="audio/mpeg" />
  <source src="/audio/founder-interview.ogg" type="audio/ogg" />
  Your browser doesn't support embedded audio.
  <a href="/audio/founder-interview.mp3">Download the audio</a> instead.
</audio>

The same real principles apply — multiple source formats, a genuine fallback for unsupported browsers, and (for spoken audio content) a real transcript linked nearby, since <audio> has no direct captions equivalent the way <video> does with <track>.

autoplay and muted: use with real restraint

<!-- a real, deliberately muted decorative background video -->
<video autoplay muted loop playsinline>
  <source src="/videos/coffee-pour-loop.mp4" type="video/mp4" />
</video>

Browsers block autoplaying video with sound by default — a real, deliberate anti-annoyance policy, not a bug. autoplay only reliably works when paired with muted, and should be reserved for genuinely decorative, ambient content like a silent looping product shot — never for content with real information a visitor actually needs to hear, since forcing sound on an unsuspecting visitor is a real, well-documented usability complaint. playsinline prevents the video from automatically expanding to fullscreen on mobile, appropriate for this kind of small decorative loop.

Real file size is a real performance concern

Video is, by a wide margin, the heaviest media type a page can include — an uncompressed or overly high-bitrate roasting-process video can single-handedly dominate a page's total load weight, directly undermining the Core Web Vitals concerns raised back in part 6. Real production video should be compressed appropriately for web delivery before it's ever linked from <source>, a genuine pre-upload step, not something the <video> tag itself handles.

Next: embedding third-party content — <iframe>, YouTube embeds, and the real security considerations that come with letting another site's content run inside your own page.