Images and Media

Images and media make up a huge share of what actually loads on a real page. This lesson covers the elements for embedding them correctly — which mostly means correctly for people who can't see them, or whose connection hasn't finished loading them yet.

The <img> element

<img src="cat.jpg" alt="A tabby cat sleeping on a windowsill" />

src points at the image file — relative or absolute, same rules as href from the last lesson. <img> is a void element (no closing tag, no content between tags — the image is the content).

Why alt is never optional

alt isn't a nice-to-have caption. It does three distinct, real jobs:

1. Screen readers announce it in place of the image, since there's nothing visual to describe otherwise. Without alt, a screen reader user gets either silence or the raw filename read aloud — neither is useful.
2. It's shown as fallback text if the image fails to load — a broken link, a slow connection, a typo in the file name. Instead of a blank broken-image icon, the visitor sees what they were supposed to see.
3. Search engines read it to understand what an image contains, since they can't "see" the pixels either. This is a real, direct signal used in image search indexing.

Writing good alt text

<!-- Bad: describes nothing useful -->
<img src="chart.png" alt="image" />
<img src="chart.png" alt="chart.png" />
 
<!-- Good: describes what the image conveys -->
<img src="chart.png" alt="Bar chart showing signups tripling from January to March" />

Describe what the image communicates, not just "a picture of X" unless that literally is all there is to say. If the image is purely decorative — a background flourish that adds nothing informative — use an empty alt="" (not no alt attribute, an empty one). That tells screen readers to skip it silently instead of announcing something pointless or, worse, the filename.

<img src="decorative-swirl.svg" alt="" />

width and height — not just for sizing

<img src="cat.jpg" alt="A cat" width="800" height="600" />

It's tempting to think these attributes are pointless once you're going to size the image with CSS anyway — and CSS genuinely will win if there's a conflict. But they serve a separate, real purpose: the browser reads the width/height ratio before the image file has finished downloading, and uses it to reserve the correct amount of space in the page layout right away.

Without them, the browser doesn't know the image's dimensions until the file arrives, so it initially renders zero height where the image will go — then, once the image loads, everything below it suddenly jumps down. That visible jump is called layout shift, and it's a real, measurable harm to the experience of a page (it's part of what Core Web Vitals scores). Setting width and height (even if CSS later overrides the final rendered size) lets the browser reserve the right space immediately, so nothing shifts once the image arrives.

<img src="cat.jpg" alt="A cat" width="800" height="600" style="width: 100%; height: auto;" />

Here the attributes give the browser the ratio (800:600) to reserve space correctly, while the CSS controls the actual final size.

A note on srcset

Serving a smaller image to a phone and a larger one to a widescreen monitor is a real, common need — sending everyone the same huge file wastes bandwidth on small screens. The srcset attribute exists for exactly this, letting the browser pick the best-fitting image from a set of options. The full technique deserves its own explanation and gets one later, in the Responsive Images lesson — for now, just know the tool exists and what problem it solves.

<figure> and <figcaption>

When an image needs a visible caption, <figure> groups the image and its caption as one self-contained unit:

<figure>
  <img src="chart.png" alt="Bar chart showing signups tripling from January to March" />
  <figcaption>Monthly signups, Q1 2026.</figcaption>
</figure>

<figure> isn't only for images — it can wrap a code snippet, a quote, a diagram, anything with a caption describing it — but pairing it with an <img> and <figcaption> is the most common case.

<audio> and <video>

Both work the same way: a container element with a controls attribute to show the browser's built-in play/pause/volume UI, and one or more <source> children for the actual file(s).

<audio controls>
  <source src="podcast.mp3" type="audio/mpeg" />
  <source src="podcast.ogg" type="audio/ogg" />
  Your browser doesn't support the audio element.
</audio>
 
<video controls width="640">
  <source src="clip.mp4" type="video/mp4" />
  <source src="clip.webm" type="video/webm" />
  Your browser doesn't support the video element.
</video>

Multiple <source> elements let you offer the same media in different formats — not every browser supports every video/audio codec, so the browser picks the first <source> it can actually play and ignores the rest. The text after the <source> tags is a fallback shown only in the rare case that none of the formats are supported.

controls matters on its own: without it, <audio> and <video> render with no visible interface at all, and the visitor has no way to play, pause, or adjust volume.

Try it yourself

What to remember

• alt serves screen readers, broken-image fallback, and search engines — write it to describe what the image communicates, or leave it alt="" if it's purely decorative.
• width/height on <img> reserve layout space before the file loads, preventing layout shift — CSS can still control the final rendered size.
• srcset handles serving different image sizes to different devices; the full technique is covered in the Responsive Images lesson.
• <figure> + <figcaption> is the correct pairing for an image with a visible caption.
• <audio>/<video> need controls to show any playback UI, and <source> lets you offer multiple formats.