Serving WebP and AVIF images with safe fallbacks

Converting your photos to modern formats is the easy part. The tricky part is making sure a customer on an old iPad, a corporate laptop with an outdated browser, or a link-preview bot still receives an image they can display. A broken product photo costs more than a slightly heavier one. There are four reliable ways to serve WebP and AVIF images with fallbacks, and each suits a different kind of site. This guide walks through how they work, what to watch for and how to confirm the right file is reaching each browser.

The principle: offer choices, let the browser or server decide

Every fallback method follows the same idea. You keep multiple versions of each image, usually AVIF, WebP and JPEG (or PNG), and something decides which one each visitor gets. That decision can happen in the browser, on your server, at a CDN, or inside your CMS. What you must avoid is simply renaming files or serving only AVIF to everyone.

Method 1: the picture element in HTML

The HTML picture element lets you list several sources in order of preference. Inside it you place one or more source elements, each with a type attribute such as image/avif or image/webp and a srcset pointing to that file, followed by a normal img element pointing to the JPEG.

The browser reads the sources from top to bottom and picks the first type it supports. If it understands none, or does not understand the picture element at all, it uses the img. Crucially, the img element still carries the alt text, width, height, loading and class attributes; the source elements only swap which file is fetched.

Advantages

• Works on any hosting, with no server configuration
• Completely predictable: you can read the HTML and know what happens
• Combines with srcset and sizes for responsive images per format

Things to watch

• Put AVIF before WebP; order decides preference.
• Styling applies to the img, not the picture wrapper, so check your CSS still targets the right element.
• Markup gets long when each format also has several widths. Templates or components should generate it rather than people typing it.
• If you preload the hero image, the preload must match the format the browser will actually choose, or it downloads two files.

Method 2: server content negotiation

With content negotiation, the HTML keeps a single URL such as product-blue.jpg, and the server decides what to send. Browsers include an Accept request header listing formats they handle. When it mentions image/avif or image/webp and a matching converted file exists, the server responds with that file instead, setting the correct Content-Type.

On Nginx this is usually done with a map on the Accept header and a try_files rule that looks for a .avif or .webp copy next to the original. On Apache, mod_rewrite conditions can check the Accept header and whether the alternative file exists.

The caching trap

Because one URL can now return different files, every response must include a Vary: Accept header. Without it, a proxy or CDN may cache the AVIF version and hand it to a browser that cannot show it, producing broken images for some visitors. Some CDNs handle Vary headers in limited ways, so confirm with your provider’s documentation before relying on this method behind a CDN.

Other considerations

• HTML stays clean and existing image URLs keep working.
• A visitor who downloads the ".jpg" may receive a WebP file with a misleading extension.
• You need access to server configuration, which basic shared hosting may not give.

Method 3: conversion at the CDN or image service

Several CDNs and image services can convert images on the fly. You upload one high-quality original; the edge network detects browser support, creates an AVIF or WebP version, caches it and serves it. Cloudflare, for example, offers image optimisation features, typically on paid plans, and dedicated image CDNs work in a similar way, often adding resizing through URL parameters.

• Pros: no conversion load on your server, no duplicate files to manage, format decisions kept up to date by the provider.
• Cons: ongoing cost, dependency on a third party for every image, and settings that need checking so quality is not reduced too aggressively.

Before switching, check how the service handles transparency, animated images and very large originals, and whether you can exclude specific paths such as downloadable brochures.

Method 4: CMS plugins and platform features

On WordPress, image optimisation plugins can generate WebP and AVIF copies when you upload and then serve them in one of two ways: by rewriting page HTML into picture elements, or by adding server rules for content negotiation. Some hosted store builders convert images automatically without any settings at all.

When evaluating a plugin, ask:

1. Does it convert on my server, or send images to an external API with usage limits?
2. Which delivery method does it use, and does it set Vary: Accept if it rewrites on the server?
3. Does it work with my page cache plugin and CDN?
4. Does it process images that already exist, not just new uploads?
5. What happens to the converted files if I deactivate it?

Which method suits your site

• Custom-built site with developer access: the picture element generated by templates, for full control.
• Existing site with many hard-coded image URLs: content negotiation, if you control the server and handle Vary correctly.
• Large catalogue or media-heavy portal: a CDN or image service to avoid server strain.
• WordPress or WooCommerce with limited technical help: a reputable plugin, tested on staging first.

Testing that fallbacks really work

Do not assume; verify.

1. Open Chrome DevTools, go to the Network tab, filter by Img and reload. The Type column should show avif or webp.
2. Click an image request and check the response Content-Type and Vary headers.
3. Test in Safari and Firefox as well as Chrome.
4. Use DevTools’ Rendering panel options to disable AVIF and WebP support, then reload and confirm JPEGs appear.
5. Share a product URL in WhatsApp and check the link preview still shows an image.

If your store runs on a custom platform, our software development team can build format handling into the image pipeline itself. For hosting that lets you change server rules, see our Linux hosting plans.

Frequently asked questions

Do I still need JPEG copies if nearly all browsers support WebP?

Keeping a fallback costs little storage and protects the small share of visitors on old devices, plus email clients, bots and apps that may not handle newer formats. It is a sensible safety net.

Can I use WebP for Open Graph social sharing images?

Support varies between platforms and changes over time. A JPEG or PNG for the og:image tag remains the safest choice for reliable link previews.

Why are my WebP images not showing in Safari?

Current Safari supports WebP, so check the device’s operating system version first. Also confirm the server sends the correct Content-Type header, as a wrong type can stop images displaying.

Does using the picture element affect SEO?

No negative effect is expected. Search engines read the img element inside picture, including its alt text, so keep that descriptive and accurate.