Using the HTML5 <picture> Element for Art Direction and Resolution Switching
Learn how the HTML5 <picture> element lets you serve different images based on viewport size or pixel density, improving performance and visual focus while providing a reliable fallback.
18 Feb 2026, 20:56 UTC

Problem: a single image hurts performance and design
When you serve the same JPEG or PNG to every device, small screens download unnecessary bytes while large screens may receive a low‑resolution version that looks blurry or poorly composed. This wastes bandwidth and can break the visual intent of a layout that relies on different cropping or focus at different widths.
Thesis: lets you match image sources to viewport size, pixel density, or art direction
The element acts as a container for one or more elements. Each can declare a media condition, a set of candidate files with srcset, and an optional MIME type. The browser picks the first whose media condition matches; if none match, it falls back to the nested . This gives you art direction (different crops) and resolution switching (different densities) without JavaScript.
Syntax basics
<picture>
<source media="(max-width: 600px)" srcset="small.jpg 1x, [contact removed] 2x" type="image/jpeg">
<source media="(min-width: 601px)" srcset="large.jpg 1x, [contact removed] 2x" type="image/jpeg">
<img src="fallback.jpg" alt="Description of the image">
</picture>
The <img> is required for accessibility and as a fallback for browsers that do not understand . Its src should be a sensible default that works everywhere.
Art direction example: portrait vs. landscape
Suppose you have a hero banner that shows a full scene on wide screens but a tightly cropped portrait on narrow screens to keep the subject’s face visible. You prepare two crops: hero-narrow.jpg (400 × 600) and hero-wide.jpg (1200 × 400). The markup looks like this:
<picture>
<source media="(max-width: 600px)"
srcset="hero-narrow.jpg 1x, [contact removed] 2x"
type="image/jpeg">
<source media="(min-width: 601px)"
srcset="hero-wide.jpg 1x, [contact removed] 2x"
type="image/jpeg">
<img src="hero-wide.jpg" alt="A person standing in a landscape">
</picture>
When the viewport is 600 px or less, the browser uses the narrow crop; otherwise it uses the wide crop. The srcset also lets the browser pick a 2× version on high‑DPI screens.
Worked example with resolution switching
In addition to art direction, you may want to serve different file sizes based on pixel density. The following snippet combines both ideas: a narrow layout gets a small file, a wide layout gets a larger file, and each layout offers 1× and 2× candidates.
<picture>
<!-- Narrow screens (<=600px) -->
<source media="(max-width: 600px)"
srcset="hero-400w.jpg 1x, [contact removed] 2x"
type="image/jpeg">
<!-- Wide screens (>600px) -->
<source media="(min-width: 601px)"
srcset="hero-800w.jpg 1x, [contact removed] 2x"
type="image/jpeg">
<!-- Fallback for older browsers -->
<img src="hero-800w.jpg" alt="A person standing in a landscape">
</picture>
Place this markup in an HTML file, open it in a modern browser, and open the developer tools.
How to verify the correct image is chosen
- Open the page in Chrome/Firefox/Edge.
- Open DevTools → Network tab, enable “Disable cache” to see fresh requests.
- Resize the browser window or toggle the device toolbar to simulate different widths.
- Observe which file appears in the network list; it should match the
mediacondition that is true. - To test the fallback, temporarily rename or remove the
<picture>wrapper (or use a user‑agent switcher for an old browser) and verify that the<img>src is requested.
Check accessibility by inspecting the rendered <img> element; its alt attribute should remain unchanged regardless of which source was selected.
Trade‑off: more markup and assets
Using means you must maintain multiple image files and additional HTML. Each breakpoint adds a element, increasing authoring effort. However, the fallback ensures that unsupported browsers still display an image, so you never break content for older users.
Actionable closing
Start with a solid fallback that works everywhere. Add blocks only where art direction or resolution switching provides a clear benefit—typically at major layout breakpoints. Test with DevTools as described, and consider automating image generation with a build tool (e.g., ImageMagick, Sharp, or an online service) to keep the asset pipeline manageable.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.