How to serve images in modern formats

By Matt Kerr·Published 10 October 2026

Convert your photos to WebP, or AVIF, and serve them in a way that still works for the rare browser that cannot read them. Either point the <img> at the .webp file, or wrap it in a <picture> that offers the modern file first and keeps the JPEG as the fallback. Most CMS platforms and CDNs will do the conversion for you on upload.

Why bother

MDN's image format guide, which I read on 10 October 2026, says WebP offers much better compression than PNG or JPEG, and that AVIF offers slightly better compression than WebP but is not quite as well supported. It lists WebP and AVIF as supported in Chrome, Edge, Firefox, Opera and Safari. Its advice for AVIF is to include fallbacks in a format with better support, using the <picture> element. The guide is Image file type and format guide.

A smaller file is less to download before the picture appears. On a page whose largest element is a photo, that is time you can win back for the visitor. It is also one of the cheaper speed changes, because it touches the files and not your layout.

Two ways to serve them

Swap the file. If you do not need a fallback, point the image at the WebP directly. Every current browser reads it.

<img src="/img/bench.webp" alt="The bench of a repaired typewriter" width="800" height="600">

Offer it first, keep the JPEG behind it. A <picture> lists sources in order. The browser takes the first one it understands and falls back to the <img> if it understands none. This is the way to add AVIF ahead of WebP, and the way to keep one more format for an old browser.

<picture><source srcset="/img/bench.webp" type="image/webp"><img src="/img/bench.jpg" alt="The bench of a repaired typewriter" width="800" height="600"></picture>

Keep the width and height on the <img> in both cases. They reserve the space whichever file loads. That is covered in how to fix layout shift.

How to convert

Convert from your original files where you have them. A JPEG that is re-encoded to WebP loses a little more quality each time it is saved lossy, and you cannot get it back.

cwebp -q 80 photo.jpg -o photo.webp
avifenc photo.jpg photo.avif

Those are the command-line tools from the WebP and AVIF projects. A CMS plugin or an image CDN will do the same on upload, and either is easier for a site with hundreds of pictures. Look at a few results at full size before you convert the lot. PNG files with transparency convert too, because WebP and AVIF both support transparency.

What Docket reports

Docket counts every <img> whose address ends in .jpg, .jpeg or .png, and reports the pages that have four or more. It reads the address from src, or from data-src or the first entry of srcset when there is no src. An image counts as modern, and is left out, in two cases: it sits in a <picture> that has a <source> typed as WebP or AVIF (or untyped and naming only such files), or its own srcset names only such files. A <picture> of JPEG sources is still JPEG. JPEG XL is not counted as modern, because MDN says its browser support is not yet universal.

Until 10 October 2026, Docket counted the fallback JPEG inside a <picture> as well. That was a bug: the snippet in its own finding did not clear its own finding. It does now.

A real before and after

I wrote a small fixture site for this page: 4 pages of a typewriter repair workshop, four photos on each. I audited it with Docket on 10 October 2026 in three versions of the same pages. The pages are ours; nothing here is measured on anyone else's site.

The first version used plain <img> tags pointing at JPEG and PNG files. Docket reported this, in its own words:

16 images use JPEG/PNG instead of a modern format
Across 4 pages. WebP and AVIF are typically 25–50% smaller at the same visual quality, and every current browser supports WebP.

Its fix was: Convert images to WebP (or AVIF with a WebP fallback). Most CMS platforms and CDNs can do this automatically on upload. I then made two versions. In one, every photo was wrapped in a <picture> with a WebP source and the JPEG kept as the fallback, as above. In the other, every <img> pointed at the WebP file. Docket reported nothing on either.

What Docket cannot tell you

• It reads names, not files. It never opens an image, so it does not know how big one is or whether a .webp file really is WebP.
• It cannot see what a CDN does. Some image CDNs choose the format from the browser's request and keep the .jpg address. Your visitors get modern files and Docket sees JPEG, so it may report images you have already handled.
• It does not look at CSS background images. Only <img> elements are counted.

Where to start

Start with the pages that matter most and the largest picture on each, usually the one at the top. If the finding names a lot of images across a big site, they almost always come from one gallery or product template, and the cheapest fix is a conversion step on upload. The rest of the image work, alt text, dimensions and lazy-loading, is in how to fix image SEO problems, and the other thing that holds back a first screen is in how to fix render-blocking resources. What Docket adds is the same count across every page, ranked with the rest; see how that compares with other audit tools.

Common questions

Should I use WebP or AVIF?

MDN says AVIF compresses slightly better but is not quite as well supported, and advises a fallback. WebP is read by every current browser. Offering AVIF first and WebP second in a picture element gets both.

How do I keep a fallback for old browsers?

Wrap the image in a picture element, list the modern sources first, and keep the original img inside it as the fallback.

Will Docket still report an image inside a picture element?

Not if the picture has a source typed as WebP or AVIF, or untyped and naming only such files. A picture of JPEG sources is still reported.

Does Docket check the size of my images?

No. It reads the address in the markup and never opens the file.