Serving WebP with the HTML picture Element

The <picture> element serves WebP to browsers that support it and a JPEG or PNG fallback to those that do not. It needs no JavaScript: the browser reads the type attribute on each <source> and renders the first format it can decode. This guide covers the syntax, source ordering, art direction, and the mistakes that break the fallback.

For when a fallback is still needed, see WebP Browser Support: Compatibility & Fallback Guide. For the format itself, see What is WebP?.

How do you serve WebP with a fallback in HTML?

Wrap a WebP <source> and a fallback <img> in a <picture> element. The browser selects the first <source> whose type it supports, and falls back to the <img> if none match. The <img> must always be present — it is the fallback and the element that actually renders.

<picture>
  <source type="image/webp" srcset="/img/photo.webp" />
  <img src="/img/photo.jpg" alt="Description" width="1200" height="675" />
</picture>

Browsers that support WebP use the <source>; older browsers ignore the unknown type and render the <img>.

Why does source order matter?

The browser picks the first <source> it can render, so sources must be listed most-preferred first. Place AVIF before WebP, and WebP before the JPEG fallback. Reversing the order makes the browser stop at a less efficient format it also supports.

<picture>
  <source type="image/avif" srcset="/img/photo.avif" />
  <source type="image/webp" srcset="/img/photo.webp" />
  <img src="/img/photo.jpg" alt="Description" width="1200" height="675" />
</picture>

This AVIF → WebP → JPEG chain is the modern web image stack. See WebP vs AVIF for when AVIF is worth adding.

What does the type attribute do?

The type attribute declares the MIME type of the <source>, letting the browser skip formats it cannot decode without downloading them. Use image/webp for WebP and image/avif for AVIF. A browser that does not recognise image/webp simply ignores that source.

This is format selection, not resolution selection. The type attribute is what makes the <picture> element a format-fallback mechanism. The MIME type detail is in WebP Media Type and MIME Type: image/webp Registration.

How do you combine picture with responsive images?

Add srcset and sizes to each <source> to serve different resolutions per format. The browser first selects the format by type, then selects the resolution within that format using srcset and sizes. This combines format fallback with responsive delivery.

<picture>
  <source
    type="image/webp"
    srcset="/img/photo-800.webp 800w, /img/photo-1600.webp 1600w"
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1600.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1600.jpg 1600w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="Description"
    width="1600"
    height="900"
  />
</picture>

The responsive mechanics are covered in srcset and WebP: Responsive Images with Format Fallback.

When should you use the media attribute?

Use the media attribute for art direction — serving a different crop or image at different viewport sizes. Each <source> can carry a media condition; the browser uses the first source whose media query and type both match. This differs from sizes, which only changes resolution, not the image itself.

<picture>
  <source media="(max-width: 600px)" type="image/webp" srcset="/img/portrait.webp" />
  <source type="image/webp" srcset="/img/landscape.webp" />
  <img src="/img/landscape.jpg" alt="Description" width="1200" height="675" />
</picture>

Use media to change composition; use sizes to change resolution.

Do you still need JavaScript feature detection?

JavaScript feature detection is no longer necessary for serving WebP. The <picture> element handles fallback declaratively in every browser that supports WebP, and degrades to the <img> in those that do not. The element itself has wider support than WebP.

JavaScript detection — decoding a 1-pixel test image to set a CSS class — was the pre-<picture> technique. It still works but adds a render-blocking script and a flash of unstyled content. Prefer <picture> for images and the Accept header for server-side negotiation, covered in WebP and Content Delivery Networks.

What mistakes break the picture fallback?

Three mistakes commonly break <picture>. Each defeats either the fallback or performance.

Omitting the <img> — without it, nothing renders. The <img> is mandatory, not optional.
Wrong source order — listing JPEG or WebP before AVIF makes the browser stop early at a larger format.
Missing width and height — without intrinsic dimensions the layout shifts as the image loads, hurting Core Web Vitals.

Always set alt, width, and height on the <img>, and add loading="lazy" to below-the-fold images and fetchpriority="high" to the LCP image.

Where to go from here

The <picture> element is the standard way to ship WebP safely. One declarative block serves the smallest format each browser supports, with a guaranteed fallback and no JavaScript.