Picture element

Definition and purpose

<picture> provides a declarative way to deliver the most appropriate image for a user’s context. It supports two key use cases: art direction (switching to differently composed assets at breakpoints) and format negotiation (serving modern formats when supported, with a safe fallback). Rather than relying on JavaScript or server-side user-agent parsing, the browser makes the selection natively, reducing complexity and improving resilience.

From a performance and SEO perspective, <picture> helps avoid over-downloading large images on narrow viewports, improves Largest Contentful Paint by tailoring bytes to need, and preserves semantics because the accessible node remains the underlying <img>. It complements, rather than replaces, srcset and sizes: the <source> elements set conditions and candidate lists, while the enclosed <img> defines the baseline image and alternative text.

Scope and structure

A valid <picture> consists of one or more <source> elements followed by a single <img>. Each <source> can declare a type (e.g., image/avif, image/webp) and/or a media attribute with a media query (e.g., (min-width: 768px)). Sources may also include their own srcset and sizes to offer multiple resolutions per condition. The browser evaluates the sources in document order and selects the first one whose type and media match; if none match, it falls back to the <img>.

<picture> itself is not rendered; the <img> provides the intrinsic dimensions, alt text, decoding and loading hints, and emits the network request for the chosen resource. Only the <img> carries alt and other accessibility-related attributes. The structure is intentionally strict—no content between <source> elements, and exactly one <img>—so that selection remains deterministic and parseable by all compliant browsers.

What “art direction” means here

Art direction in this context refers to serving fundamentally different compositions of the same subject, not just different pixel densities. For example, a tightly cropped portrait might be suitable for mobile, while a wider, context-rich shot suits desktop. By assigning each crop to a <source> with an appropriate media query, the layout can present the most legible, impactful image without relying on CSS background images or client-side scripting to swap assets.

This is distinct from density switching, where srcset provides multiple resolution candidates of the same composition and the browser chooses based on the device pixel ratio and sizes. Art-directed sources may also expose their own srcset to handle high-DPI variants within each breakpoint. The combination gives fine-grained control: first pick the right composition for the viewport, then pick the right resolution for the display and layout.

Browser support and fallbacks

All evergreen browsers support <picture>, including Chrome, Edge, Firefox, and Safari on desktop and mobile. Type-based selection for AVIF and WebP is widely available, and media queries in <source> align with CSS media features. Legacy browsers that lack support will ignore <source> and render the enclosed <img>, making a well-chosen src on the <img> essential for graceful degradation.

Because selection happens before the network fetch, browsers avoid requesting non-matching candidates, unlike some CSS techniques that may prefetch. If the type attribute is unrecognised, the browser skips that source without error. To ensure robust fallbacks, order sources from most desirable to least, include a broadly supported compressed format (e.g., JPEG) on the <img>, and avoid relying on JavaScript shims unless supporting very old environments is a hard requirement.

Overview

<picture> sits within the broader responsive images model alongside srcset, sizes, client hints, and image CDNs. It delegates complex source-selection logic to the browser, which considers media conditions, format support, device pixel ratio, and the computed sizes of the image in the layout. This reduces the risk of overfetching and helps align the actual bytes downloaded with the rendered dimensions, supporting faster paint times and lower data usage across devices and networks.

In production, <picture> is commonly paired with modern codecs (AVIF, WebP), width-based responsive sets, and server-side transformation services that generate derivatives on demand. It remains compatible with core <img> features such as width and height attributes for layout stability, decoding hints, loading=lazy, fetchpriority, and referrerpolicy. Search engines index the rendered <img>, and analytics observe the final request, allowing normal measurement of cache hits, bytes transferred, and user experience metrics such as LCP and CLS.

Role in the accessibility tree

<picture> itself does not create an accessible node; assistive technologies interact with the underlying <img>. Alternative text must be provided on <img>, not on <picture> or <source>. If the image is decorative, an empty alt on the <img> is appropriate; when the image conveys meaning, concise, context-aware alt text ensures screen reader users receive the same information as sighted users.

For figures that require a caption, wrap <picture> and <img> in <figure> with an accompanying <figcaption>; this keeps the semantics intact and associates the caption with the image in the accessibility tree. Maintain width and height attributes on <img> to reserve space and minimise layout shifts, which benefits both users of assistive technology and keyboard users by preserving focus position during loading. The <source> elements are ignored by screen readers and carry no accessible name or description.

Implementation notes

Effective implementations pair art-direction sources with density-aware srcset entries and a precise sizes attribute that reflects the image’s CSS layout. Order <source> elements from most specific and desirable (e.g., AVIF for wide screens) to least, and end with a broadly supported JPEG on the <img>. Set width and height on the <img> to provide intrinsic aspect ratio; use loading=lazy for below-the-fold images; consider decoding=async and fetchpriority for critical hero images. The default <img src> should be a reasonable, cacheable fallback that degrades gracefully on older clients and in unexpected conditions such as CSP or proxy transformations.

• Use type on <source> for AVIF/WebP; pair with media for breakpoints.
• Provide width-based srcset (e.g., 400w, 800w, 1200w) and a truthful sizes value.
• Avoid mixing contradictory CSS that changes intrinsic sizes after load, which can confuse selection.
• Preload the chosen hero candidate carefully; preloading the fallback <img src> does not guarantee the same candidate will be used after source selection.

Comparisons

<picture> overlaps with several approaches to responsive imagery. It is more expressive than <img srcset> alone when you need art direction or format switching, but <img srcset> is simpler when only density or width-based selection is required. CSS background images can swap via media queries but lack semantic content and alt text. Client hints and CDNs can negotiate formats and sizes server-side, but they do not handle art direction without additional markup or logic.

• <picture> vs <img srcset>: <picture> supports media/type-based sources; <img> handles density/width candidates only.
• <picture> vs CSS media queries: CSS can hide/swap backgrounds but sacrifices semantics and indexing of the image content.
• <picture> vs client hints/CDNs: server negotiation reduces markup but cannot change composition per breakpoint without explicit author intent.
• Format switching: <picture> enables declarative AVIF/WebP with a JPEG fallback; UA sniffing is brittle and discouraged.

FAQs

Do I need <picture> if I only care about retina displays?

Not necessarily. If the composition is the same across breakpoints, <img> with a width-based srcset and an accurate sizes attribute usually suffices. Use <picture> when you need art direction or want to switch formats based on support.

Can I use loading=lazy and decoding=async with <picture>?

Yes. These attributes belong on the <img> inside the <picture> and apply to whichever candidate is selected. They work the same as with a standalone <img>.

How does <picture> affect SEO and indexing?

Search engines index the rendered <img>, not the <picture> wrapper or the skipped sources. Provide descriptive alt text, stable URLs for canonical variants, and ensure the default <img src> is a meaningful fallback. <picture> does not inherently hinder indexing.

Should sources be ordered by format or by breakpoint first?

Order by desirability and specificity from top to bottom. A common pattern lists modern formats (AVIF, then WebP) with media queries first, followed by a general-purpose JPEG fallback on the <img>. The browser picks the first source whose type and media match, so ordering directly controls selection.

Does <picture> work with preloading and resource hints?

It can, but care is needed. Preloading the <img src> does not guarantee it matches the eventual selected candidate if a <source> overrides it. If preloading a hero image, target the exact URL you expect the browser to choose for the current viewport and format support.