Use AVIF for photography and large hero images, with WebP as the fallback. AVIF compresses harder, WebP is supported almost everywhere, and modern browsers will pick whichever one they can read. For most business sites, WebP alone is still a perfectly defensible choice in 2026.
This question comes up on nearly every build we scope. Someone has read that AVIF is the new best thing, and they want to know whether their site is already behind. The honest answer is that both formats are good, the gap between them is smaller than the marketing suggests, and the bigger wins are usually somewhere else entirely.
Below is how we actually decide, and where we think the format debate gets over weighted.
WebP is an image format Google released to replace JPEG and PNG with something smaller. AVIF is newer and built on the AV1 video codec from the Alliance for Open Media. Both handle lossy and lossless compression, transparency, and animation. AVIF simply squeezes harder at the same visual quality.
The reason AVIF compresses better is that it borrows from video encoding, where enormous effort has gone into predicting what part of a frame can be thrown away without anyone noticing. That machinery, pointed at a single still image, outperforms an older still image codec. The cost is encoding time, which can be noticeably slower.
WebP is the older and calmer choice. It has been around long enough that every toolchain, CDN, and CMS handles it without special configuration. AVIF is well supported now but still occasionally trips up older build pipelines and image libraries.
Google states that lossy WebP images are 25% to 34% smaller than comparable JPEG images at an equivalent SSIM quality index, and that lossless WebP images are 26% smaller than PNGs. AVIF typically goes further again, though the exact saving depends heavily on the image and the encoder settings.
Those WebP numbers come from Google's own WebP documentation, and they hold up well in practice. Google also notes that lossy WebP with transparency can be around three times smaller than the equivalent PNG, which is the single biggest easy win we see on sites still shipping transparent PNG logos and product cutouts.
AVIF savings are harder to state as one number honestly. The gain over WebP is real but varies with photographic detail, and aggressive AVIF settings can smear fine texture in a way people do notice. We test rather than trust a percentage, and we would encourage you to do the same on your own images.
Effectively yes, but not quite universally. According to Can I Use, AVIF has around 94.67% global browser support, against 96.18% for WebP. Chrome supports AVIF from version 85, Firefox from 93, and Safari from 16.4, with Safari 16.1 to 16.3 offering only partial support.
That gap of about one and a half points is small, but it is not zero, and it lands on real people rather than an abstraction. The safe pattern is not to choose one format and hope. It is to offer both and let the browser take what it understands, which costs you nothing at runtime.
Internet Explorer supports neither, which no longer matters for almost anyone. Opera Mini is the more relevant gap, since it is still common on low bandwidth connections in some markets. If that describes your audience, keep a JPEG fallback in the chain.
Because tooling lags support. The 2024 Web Almanac from HTTP Archive found AVIF on just 1.0% of mobile images, against 12.0% for WebP, 28.4% for PNG, and 32.4% for JPEG. Browsers were ready well before the average CMS, plugin, and build pipeline caught up.
The direction of travel is clear even if the absolute number is small. That same Web Almanac report noted that JPEG fell from 40% of all images in 2022 to 32% in 2024, and that AVIF usage had grown to almost four times what it was two years earlier. Slow adoption from a tiny base still compounds.
We read this as a reason to be relaxed rather than urgent. If 99% of the web is not serving AVIF, you are not losing a race by shipping WebP. You are matching the field while spending your effort on things with a larger payoff.
Use both when your tooling makes it cheap, and WebP alone when it does not. The HTML picture element lets you list AVIF first, WebP second, and JPEG last, and the browser takes the first one it can decode. There is no penalty for offering options.
Our rule of thumb is to reach for AVIF where the payoff is largest, which means big photographic images above the fold. A hero image is where the extra compression buys you real milliseconds. A 40 pixel avatar is not worth a second encoding step or a more complicated build.
Where we would not bother is on sites with a small number of light images and a team that has to maintain the pipeline by hand. Complexity that nobody maintains decays. A clean WebP setup that survives three years of edits beats a clever dual format setup that breaks the first time somebody uploads through the CMS.
Let something else do it. Most modern hosts and CDNs, including Cloudflare, can convert and serve the best format based on the requesting browser, so you upload once and the delivery layer negotiates. This removes the format decision from your content workflow entirely.
If you are generating images at build time instead, libraries like Sharp handle AVIF and WebP output from a single source file, and Squoosh is useful for eyeballing quality settings before you commit to them. The goal is that nobody on the content team ever has to think about a file extension.
The failure mode we see most is a half finished pipeline. Somebody converts the images that existed on launch day, then two years of blog uploads arrive as full size JPEGs straight from a phone. Automation at the delivery layer is the only version of this that survives contact with a real content team.
Yes, mostly through Largest Contentful Paint. On a typical marketing page the LCP element is a hero image, so shrinking that one file directly shortens the time until the page looks loaded. Format choice is one of the few changes that moves LCP without touching layout or code.
It is worth keeping the scale in perspective. The 2024 Web Almanac reported a median image weight of just 12 KB, while the median largest image on a mobile page was 135 KB. Almost all your opportunity sits in that one large image, not in the long tail of small ones.
That is why we treat hero images as their own engineering problem rather than part of a bulk optimization pass. If you want the full picture of how that metric behaves, our guide to Largest Contentful Paint explains what actually counts as the LCP element and why it often is not what people expect.
Both formats handle all three, so this rarely decides the question. AVIF is strongest on photography with smooth gradients. WebP is the more predictable choice for transparency and simple graphics. For animation, both beat GIF so heavily that the real advice is to stop using GIF.
GIF is the genuinely urgent problem on most sites. The 2024 Web Almanac still found GIF on 16.8% of mobile images, which is more than WebP and well over ten times more than AVIF. An animated GIF is often an order of magnitude larger than the same clip as a video file or a modern animated format.
For flat graphics, icons, and logos, the honest answer is that neither format is the right tool. SVG is smaller, sharper at every screen density, and stylable with CSS. Converting a logo from PNG to AVIF is solving the wrong problem.
Pick AVIF first with a WebP fallback if your pipeline supports both without manual work. Pick WebP alone if it does not. Then stop thinking about format and go check whether you are serving correctly sized, lazily loaded images, because that is where most sites are actually losing weight.
This is our slightly contrarian view on the whole debate. We have looked at a lot of slow sites, and the format is rarely the headline problem. A 3000 pixel wide image squeezed into a 600 pixel slot wastes more bytes than any codec choice will ever recover, and no amount of AVIF fixes it.
The two habits that pay more than format selection are sizing images to their display slot and deferring anything below the fold. Our guides to image optimization for web performance and lazy loading images both go deeper on those, and either will move your numbers further than switching codecs.
If you want a second pair of eyes on why your pages feel heavy, we are happy to take a look. We build for a PageSpeed average of 98 across our projects, and image handling is usually the first thing we change. Reach out through phoenix.studio and let's talk it through.
Tell us where you want to go. We'll tell you how we'd get you there.