The image format conversation often gets framed as a simple progression: JPEG is old, WebP is modern, AVIF is the future. The reality is messier. AVIF does produce smaller files than WebP at the same visual quality, but the gap is smaller than most comparisons suggest once you account for encoder settings. At the quality levels people actually use for web images — around quality 80 to 85 — AVIF is typically 15 to 25% smaller than WebP for photographs. That's real, but it's not the dramatic difference you'd expect from reading format comparison posts that test at extreme compression levels nobody deploys in production.
The codec lineage explains the gap. WebP's lossy encoder is based on VP8, a video codec Google released in 2010. AVIF is based on AV1, a codec developed by a coalition of major technology companies and finalized in 2018. AV1 brought a decade of research in video compression into the still-image space, which is where AVIF's compression advantage comes from. But encoding AVIF is significantly slower than encoding WebP, which is why some tools and pipelines still default to WebP even when they support both formats.
Why Safari took so long and what changed
AVIF's compatibility story was genuinely poor until fairly recently. Chrome added AVIF support in version 85 in August 2020. Firefox followed in version 93 in October 2021. Safari didn't add AVIF support until version 16 in September 2022, and iOS Safari lagged slightly behind that. Since iOS Safari is the dominant browser on iPhones and iPads — Apple's operating system restrictions mean every iOS browser uses the same WebKit engine regardless of the app name — the practical consequence was that AVIF images simply didn't work on iOS devices for most of 2020 and 2021. Any site that deployed AVIF without a JPEG fallback during that period was showing broken images to a significant chunk of mobile visitors.
That situation has largely resolved. Safari 16 is now well behind current iOS versions and the vast majority of active iOS devices support AVIF. The tooling gaps are the remaining real friction, which is what makes AVIF-to-WebP conversion still worth having. If you're working with a WordPress plugin that generates WebP variants automatically but errors on AVIF, or a CDN image transformation endpoint that accepts WebP but returns a 400 on AVIF, converting before upload is faster than debugging the pipeline. For cases where you need the widest possible compatibility including some older systems, converting all the way to JPEG is always the safe fallback.
What you lose when converting from AVIF to WebP
Converting from AVIF to WebP is a lossy operation even if you set the WebP quality slider to maximum. You're decoding a compressed format and re-encoding to a different compressed format. Each generation of lossy encoding introduces new artifacts on top of whatever was already there. For images going onto a website where you control the output format, you ideally want to convert from the original uncompressed or losslessly compressed source rather than from a lossy AVIF. If the AVIF is your only copy and the original is gone, converting at high quality (85 to 90) keeps the degradation minimal and usually invisible at normal viewing sizes. If you need the output to be lossless, converting to PNG instead gives you a pixel-perfect decode of the AVIF without any additional compression artifacts, at the cost of a larger file.