How the HTML Picture Element Works
The <picture> element is a container that wraps one or more <source> elements and a single <img> fallback. The browser evaluates each <source> from top to bottom, picks the first one it can support, and loads that image. If no <source> matches, it falls back to the <img> — guaranteeing an image always displays. This simple mechanism gives you fine-grained control over which image the browser loads based on format support, screen width, or pixel density.
Here's the minimal structure:
<picture>
<source srcset="image.webp" type="image/webp">
<source srcset="image.avif" type="image/avif">
<img src="image.jpg" alt="Description of the image">
</picture>The browser reads this top-to-bottom: it checks if it supports WebP; if yes, it loads the WebP version. If not, it checks AVIF. If neither is supported, it loads the JPG. This top-down priority model is the key to understanding <picture> — it's not about serving "the best" format abstractly; it's about serving the first compatible format in your priority chain.
Practical Applications of the Picture Element
While the format fallback use case is the most well-known, <picture> solves three distinct problems that sit at the heart of modern web performance. Each addresses a different dimension of image optimization.
Modern Format Fallback: WebP and AVIF with Automatic Degradation
The most common use of <picture> is serving next-gen formats (WebP, AVIF) to modern browsers while gracefully falling back to JPG or PNG for older ones. As of 2026, WebP has 97%+ browser support and AVIF is supported by Chrome, Firefox, and Safari 16+. A production-grade format fallback stack looks like this:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="Landscape photo" width="1200" height="800">
</picture>This pattern delivers the smallest possible file to each browser: AVIF for Chrome and Firefox users (30–50% smaller than JPG), WebP for Safari 14+ users (25–35% smaller), and JPG for the remaining sub-3% of legacy browsers. The performance gains compound quickly — a 500KB JPG becomes a ~300KB WebP and a ~200KB AVIF, potentially saving hundreds of kilobytes per page view. For developers looking to automate this, Image Toolbox's Web Optimizer generates all three format variants and the complete <picture> markup in one click — no manual encoding or code writing required.
Art Direction: Different Crops for Different Screens
Art direction with <picture> solves a problem that srcset alone can't touch: serving entirely different image compositions based on screen size. The media attribute on <source> elements lets you define breakpoints where the image changes. This is essential when a wide landscape crop looks great on desktop but becomes an indecipherable strip on mobile:
<picture>
<source media="(min-width: 768px)" srcset="hero-desktop.webp" type="image/webp">
<source media="(min-width: 768px)" srcset="hero-desktop.jpg">
<source srcset="hero-mobile.webp" type="image/webp">
<img src="hero-mobile.jpg" alt="Hero banner" width="800" height="600">
</picture>At viewport widths of 768px and above, the browser loads the desktop crop (wide, landscape); below that, it loads the mobile crop (tall, portrait, tightly framed). This is used extensively by e-commerce sites for product hero shots, news sites for article headers, and landing pages with text-over-image banners. The key insight: art direction is about composition, not resolution. The mobile image isn't just smaller — it's a different image entirely, with tighter framing and larger text to remain readable on small screens.
Resolution Switching for Retina and High-DPI Displays
For displays with high pixel density (Apple Retina, 4K monitors, modern phones), you can combine <picture> with descriptor syntax to serve crisp images without wasting bandwidth on standard displays:
<picture>
<source srcset="product@1x.webp 1x, product@2x.webp 2x, product@3x.webp 3x" type="image/webp">
<img src="product@1x.jpg" alt="Product photo" width="600" height="600">
</picture>Browsers automatically choose the appropriate resolution variant based on the device's pixel ratio: a 1x image for standard displays, 2x for Retina, and 3x for the latest flagship phones. This ensures every user sees a sharp image without the bandwidth cost of serving 3x images to everyone. Combined with lazy loading (loading="lazy") and async decoding (decoding="async"), this pattern eliminates the most common causes of poor Largest Contentful Paint (LCP) scores.
Picture vs img srcset: Making the Right Choice
Many developers confuse <picture> with <img srcset>, but they serve fundamentally different purposes. Understanding the distinction is critical for performance engineering.
| Feature | <picture> | <img srcset> |
|---|---|---|
| Primary use | Format switching, art direction | Resolution switching |
| Browser choice | Uses the first matching <source> | Browser picks best resolution |
| Format control | Full control via type attribute | No format control |
| Art direction | Yes, via media attribute | No, same image at different sizes |
| Best for | Format fallback, different crops | Same image, different densities |
The golden rule: use <img srcset> when you want the same image at different resolutions — the browser is smart enough to choose the right density. Use <picture> when the image itself needs to change — different format, different aspect ratio, or different composition. For the most robust setup, you can nest them: <picture> for format and art direction, with srcset on the <source> for resolution variants within each. This is the production pattern used by every major CDN and image optimization service.