WebP and AVIF are image formats with more efficient compression than JPEG and PNG: at a similar visual quality the file is usually smaller, and the gain depends on the type of picture — on photos with complex texture the difference is more noticeable than on a simple illustration with flat colors or on a screenshot with text.
The main difference between the formats is the codec and compatibility: WebP is based on the VP8 codec and has been supported by browsers for longer (in Safari, starting with version 14), AVIF is based on the AV1 codec, compresses photos harder, but is supported more recently (in Safari, starting with version 16.4) and encodes noticeably slower at maximum quality.
How to wire it up with picture
The most reliable way to serve a modern format without losing visitors on an old browser is the <picture> element with several source options and a plain <img> as the fallback.
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" alt="description" width="800" height="600">
</picture>The browser checks the options in order and picks the first one it can display, so AVIF is listed first, WebP second, and JPEG or PNG is left last as the option understood by absolutely everyone — including email clients and some social media bots that parse a plain <img> but cannot read <picture>.
How to serve by the Accept header on the server
Instead of picture markup, the right format can be served at the web server level: Nginx checks the request's Accept header and, if it contains image/webp or image/avif, rewrites the path to a file in that format — handy for old themes where changing the HTML is expensive.
- Keep ".webp" and ".avif" files with the same name next to the original — the conversion should happen ahead of time, not on the fly on every request.
- Add a
Vary: Acceptheader to the response — without it a CDN or a browser cache can serve one visitor a format meant for another. - Check the
Acceptheader, not the User-Agent — some bots and apps send a non-standard User-Agent but honestly list the formats they support in Accept. - Serve the original JPEG or PNG if the file in the new format was not found on disk, instead of returning an error — the conversion may not have finished yet for a fresh upload.
- Check after deploying that images open directly through a direct link to .webp or .avif — some configurations serve the right MIME type only through a rewrite rule and break on a direct file request.
The path rewrite rules go into the same config where response compression is set up — the order in which directives apply matters, and that is covered in more detail in the article about Gzip and Brotli in Nginx.
What to convert images with
For a one-time conversion of a batch of files, console encoders are more convenient than a graphics editor — they are faster on large catalogs and are easy to run on a schedule.
| Parameter | WebP (cwebp) | AVIF (avifenc) |
|---|---|---|
| Quality parameter | from 0 to 100, set with the -q flag | its own quality scale, usually set with the --min and --max flags |
| Encoding speed | faster | noticeably slower at maximum quality |
| Safari support | since version 14 | since version 16.4 |
| Compresses best | simple graphics and illustrations | photos with complex texture |
On a catalog of several thousand images, converting to both formats takes a noticeable amount of CPU time — on shared hosting plans it is better to run it in the background or in parts rather than all at once for the whole catalog; after converting, it is worth comparing the resulting page weight against the recommendations in the article about speeding up WordPress.
A separate case — WooCommerce
A WooCommerce product page usually has several images — the main photo and gallery thumbnails — and a catalog page shows dozens of products at once. Converting to WebP or AVIF gives more here than on a regular blog, simply because more images load on one page at the same time.
After a theme change or a bulk product import, part of the images can stay in the original format if the conversion plugin only processes new uploads — it is worth running a bulk catalog conversion from time to time rather than relying only on automatic processing of new files; specific settings for a store are covered in the article about WooCommerce optimization.
Frequently asked questions
Is it necessary to keep the original JPEG once the site already serves WebP and AVIF?
Yes, the original is needed as a fallback for browsers and bots without support for the new formats, and also as a source for re-conversion if a different compression quality is ever needed — deleting it right after conversion is risky.
Why does AVIF sometimes weigh more than WebP for the same picture?
At low and medium quality AVIF is usually more compact, but on very simple images with large solid-color areas or on small icons the difference can flip the other way — the AVIF codec is tuned for photos, and on atypical material its advantage is not guaranteed.
Is it fine to stick with just WebP and skip AVIF?
It is, if old Safari versions and some corporate browsers are not critical for the site's audience: WebP is supported more broadly and encodes faster, and the difference in file weight against AVIF on most ordinary site photos is noticeable but not drastic.