image-formats
performance

WebP vs AVIF vs JPEG, and which image format to serve in 2026

Compare WebP, AVIF and JPEG on file size, encoding cost and browser support in 2026, then serve each one safely with the picture element or the Accept header.

By Focal team 21 September 2026 6 min read

Most teams choosing a format for photos pick from three candidates. JPEG works everywhere. WebP is smaller and works in almost every browser in use. AVIF is smaller again, costs more to encode, and has the newest support. This post compares the three on file size, encoding cost and browser support as of September 2026, shows the two standard ways to serve each browser the best format it can decode, and ends with a short decision guide.

What each format is

JPEG is a lossy format based on the discrete cosine transform. MDN describes it as the most popular format for lossy compression of still images. It does not support an alpha channel, so it cannot store transparency.

WebP has a lossy mode based on the VP8 video codec and a separate lossless mode. It supports transparency and animation. Google’s WebP documentation reports these results:

Lossy WebP files are 25 to 34% smaller than comparable JPEG files at an equivalent structural similarity (SSIM) index.
Lossless WebP files are 26% smaller than PNG files.
Lossless WebP stores transparency for 22% more bytes.

AVIF, the AV1 Image File Format, stores images compressed with the AV1 video codec from the Alliance for Open Media. It supports transparency, animation, high dynamic range and wide colour gamut. MDN’s image format guide says lossy AVIF files are around 50% smaller than JPEG files and generally compress better than WebP. The same guide notes that AVIF does not support progressive rendering, so the browser has to download the whole file before it can display it. MDN adds that this often has little effect in practice, because AVIF files are much smaller than the equivalent JPEG or PNG.

Browser support in September 2026

The table lists the first version with full support, from caniuse data.

Browser	WebP	AVIF
Chrome	32	85
Edge	18	121
Firefox	65	93
Safari on macOS	16.0	16.4
Safari on iOS	14.0	16.4

caniuse puts global support at about 96% of tracked browser usage for WebP and about 95% for AVIF. Two footnotes matter for Safari. Safari 14 to 15.6 on macOS decodes WebP only on macOS 11 Big Sur or later. Safari 16.1 to 16.3 on macOS decodes AVIF only on macOS 13 Ventura or later, and only still images. iOS Safari 16.0 to 16.3 also decodes still AVIF images only.

JPEG XL is the other format people ask about. caniuse lists partial support in Safari 17 and later. That support covers still images without progressive decoding. Chrome and Firefox release builds ship it disabled behind a flag. Chrome users cannot decode it by default, so it is not a practical default yet.

Encoding cost

Smaller files cost more processor time to produce. The Next.js image documentation states that AVIF generally takes 50% longer to encode than WebP and compresses 20% smaller. For that reason Next.js still recommends WebP for most use cases.

AVIF encoders also trade speed against compression. web.dev’s AVIF article explains that higher speed settings in the libaom encoder run faster but compress less well, and it recommends speed 6 as a balance.

Encoding time matters most when a service resizes images on request. The first visitor to ask for a new size waits for the encode. Every later visitor gets the cached result.

What sites serve today

The 2025 Web Almanac measured the format of the image that forms the Largest Contentful Paint (LCP) element on each page it tested. JPEG accounted for 57% of LCP images, PNG for 26%, WebP for 11% and AVIF for 0.7%. Most pages still send their most important image in a format that both newer formats beat on size.

Two ways to serve the right format

A browser that cannot decode a format shows a broken image. You need a way to send each browser a format it supports.

The picture element

The <picture> element lists sources in order of preference, each with a type. The browser takes the first <source> whose type it supports and falls back to the <img>.

<picture>
  <source type="image/avif" srcset="chair-800.avif">
  <source type="image/webp" srcset="chair-800.webp">
  <img src="chair-800.jpg" width="800" height="600" alt="Oak lounge chair">
</picture>

This approach needs no server logic. Each file has its own URL, so every cache in between stores each format separately without extra configuration. The cost is more markup and more files to produce.

Accept header negotiation

Browsers list the image formats they accept in the Accept request header. A server can read that header and return WebP or AVIF from the same URL. MDN documents the default values:

Chrome and Edge 121+:  image/avif,image/webp,image/apng,image/*,*/*;q=0.8
Firefox 128+:          image/avif,image/webp,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Safari (Big Sur+):     image/webp,image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5

MDN’s list shows Safari advertising image/webp but not image/avif. A server that negotiates AVIF from this header would send Safari WebP, even though current Safari decodes AVIF. The <picture> element does not have that gap, because it relies on the browser’s own decoder support.

A negotiating server has to send Vary: Accept with the response. Without it, a shared cache can store the WebP made for one browser and hand it to a browser that cannot decode it. The Next.js docs add that a proxy or content delivery network (CDN) in front of the server must forward the Accept header.

A decision guide

Use these defaults and change them when your measurements say otherwise:

For photos, serve WebP to browsers that accept it and JPEG to the rest.
For large hero and banner images, add an AVIF source through <picture> if the extra encoding time is acceptable. These are the images where a 20% saving is the most bytes.
For logos, screenshots and graphics with sharp edges or text, use lossless WebP or PNG. MDN recommends PNG when exact reproduction matters.
Keep a JPEG or PNG fallback in every setup. It costs one extra file and covers every browser that fails the checks above.

Formats in Focal

Focal applies part of this guide automatically. When a URL names no format, browsers that accept WebP get WebP and the rest get the source format. Focal caches each format separately. AVIF is never chosen automatically. You name it with format(avif), and then every browser receives AVIF from that URL, so put it in a <source type="image/avif"> and leave the <img> URL without a format. The Focal docs list the other filters.

<picture>
  <source type="image/avif"
    srcset="https://img.focaltool.com/your-key/unsafe/800x0/filters:format(avif)/products/chair.jpg">
  <img src="https://img.focaltool.com/your-key/unsafe/800x0/products/chair.jpg"
    width="800" height="600" alt="Oak lounge chair">
</picture>

Before switching a whole catalogue, encode twenty of your own product photos at the quality you use today and compare the byte totals for each format. The Google and MDN figures come from their own test images, and your photos can land above or below them.