From JPEG to AVIF: Three Decades of Format Evolution

The history of web image compression is one of diminishing returns and slow adoption. JPEG arrived in 1992 and, per the HTTP Archive's 2025 Web Almanac, still accounts for over 60% of images on the web today — a format older than most developers using it. PNG followed in 1996, bringing lossless compression and alpha-channel transparency, but its file sizes made it impractical for photographic content. Google open-sourced WebP in 2010 with a compelling claim: 25-35% smaller than JPEG at equivalent visual quality. Yet it took a full decade — until Safari 14 shipped in 2020 — for all major browsers to support it. Every new format has faced the same cycle: technical superiority announced, years of partial adoption, gradual ecosystem alignment, and finally ubiquity long after the early adopters moved on to the next thing.

AVIF (AV1 Image File Format) emerged from the Alliance for Open Media in 2019, built on the same AV1 codec that powers modern video streaming on Netflix and YouTube. It pushes compression further still: approximately 50% smaller than JPEG and 20% smaller than WebP at the same perceptual quality. A 300KB product photograph can shrink to 140KB as AVIF with no visible quality loss. But AVIF follows the same adoption curve that WebP, PNG, and even JPEG itself once traveled. The question for engineering teams in 2026 is not whether to adopt it — the bandwidth savings are mathematically undeniable — but how to deploy it without leaving users on unsupported browsers staring at broken image placeholders.

Browser Support: Where AVIF Works and Where It Breaks

As of July 2026, AVIF is natively supported in Chrome 85+, Firefox 93+, Edge 92+, and Safari 16.4+. Can I Use's aggregated data places global support at approximately 94% of desktop traffic and 92% of mobile traffic. The remaining 6-8% is not randomly distributed across the internet — it clusters in specific, predictable segments that directly shape your fallback strategy.

The largest gap is Safari below 16.4, which shipped with macOS Ventura in March 2023. Devices running macOS Monterey or earlier cannot upgrade past Safari 16.0, locking them out of AVIF permanently. Apple's WWDC 2026 adoption statistics indicate approximately 8% of active iPhones still run iOS 15 or earlier — devices that support WebP but not AVIF. For sites with significant iOS traffic, particularly e-commerce and media properties, these users see broken image icons without a proper fallback chain. The second gap involves older Android WebView: pre-2024 versions on budget devices from Xiaomi and Realme have documented crashes when encountering an AVIF <source> tag rather than graceful degradation. Enterprise environments running legacy browsers represent a smaller but persistent share, especially in B2B and government contexts where browser upgrades lag by years.

A subtler problem exists at the CDN layer. Some providers perform on-the-fly image transcoding and strip the correct Content-Type header, serving an AVIF binary with a JPEG MIME type. Chrome and Firefox tolerate this mismatch silently, but Safari rejects the file entirely — rendering a blank space where the image should appear. This is a server-side configuration issue that a client-side fallback chain cannot fix, so verifying your CDN's AVIF handling is a prerequisite, not an afterthought, for any AVIF rollout.

Beyond raw support numbers, the real-world performance of AVIF decoding varies by device class. Decoding AVIF is computationally heavier than decoding JPEG — the AV1 codec's sophisticated prediction modes and deblocking filters demand more CPU cycles. On flagship smartphones and modern laptops, this overhead is invisible: decode times stay under 5 milliseconds even for large images. On budget Android devices with mid-range SoCs, the same image can take 30-50 milliseconds to decode, which is still imperceptible to users but becomes measurable when a page loads dozens of images simultaneously. A 2025 study by web.dev benchmarked AVIF decode times across 40 device profiles and found that devices costing under 200 US dollars showed 3-4x slower AVIF decoding than JPEG, while premium devices showed near-parity. For teams targeting emerging markets where budget devices dominate, this means AVIF's bandwidth savings partially offset slower rendering — the net effect is still positive because network latency dwarfs decode time, but the margin is thinner than benchmarks on flagship hardware suggest.

The Three-Tier Fallback Chain

The HTML <picture> element is the standard mechanism for format-based fallback. The browser evaluates each <source> element in document order and renders the first format it can decode, falling through to the <img> element as a last resort:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Product photo" width="1200" height="800">
</picture>

This three-tier chain covers essentially every browser in active use. Skipping the WebP tier and going directly from AVIF to JPEG means Safari 15 users — who support WebP but not AVIF — download the heavier JPEG instead of the optimized WebP variant. For a 300KB image, that is a 90KB penalty per request per affected user. At scale, the storage cost of generating one additional file variant is trivial compared to the bandwidth savings of including WebP in the chain. Performance overhead is negligible: modern browsers parse the <picture> element and select a source before initiating any network request — they never download multiple formats.

What Comes After AVIF — Pipeline Resilience

JPEG XL, once positioned as AVIF's natural successor, was effectively shelved by Chrome in 2023 and remains a niche experiment with no path to mainstream browser support. AVIF's position as the de facto next-generation image format is secure through at least 2027. Google's 2026 I/O sessions referenced early AV2 codec research that could eventually produce an AVIF successor, but no timeline has been announced, and AV2 is at minimum three years from a stable specification.

The practical implication for engineering teams: invest in a format-agnostic image pipeline rather than hard-coding AVIF generation into a single build step. If your tooling only knows how to produce AVIF, adopting a future format means rewriting that layer from scratch. A pipeline that accepts any input format and outputs configurable variants — AVIF, WebP, JPEG, and potentially future additions — provides flexibility without architectural rework. One edge case worth flagging: AVIF does not always produce the smallest file. For images dominated by flat-color areas — icons, illustrations, logos — the AV1 codec's complexity overhead can actually produce files larger than the equivalent WebP. A blanket conversion policy will underperform a per-image optimization strategy that measures output size and selects the winner format by format.

The storage cost of maintaining three format variants per image is modest in practice. Cloudflare's 2025 image optimization pricing analysis showed that storing AVIF, WebP, and JPEG variants for a catalog of 10,000 product images costs approximately 2.40 US dollars per month — less than the bandwidth savings from a single day of AVIF delivery on a site with moderate traffic. The build-time cost is equally manageable: converting 10,000 images to all three formats takes roughly 90 seconds on a standard CI runner using libvips. The bottleneck is not storage or processing power but pipeline complexity — ensuring that every new image uploaded by content editors flows through the same conversion pipeline without manual intervention.

Action Checklist

Start by auditing your current image inventory: identify photographic content (strong AVIF candidates) versus flat-color graphics (where WebP or PNG may be better). Set up a build-time pipeline that generates AVIF, WebP, and JPEG variants for every image asset. Implement the <picture> fallback chain in your templates or component library. Verify CDN configuration — ensure Content-Type headers are preserved and that no on-the-fly transcoding interferes with your pre-generated variants. Monitor real-world format distribution through your analytics platform to confirm the majority of users actually receive AVIF rather than silently falling back to JPEG. For teams that need to batch-convert existing image directories, the Image Toolbox web optimizer generates all three variants simultaneously and outputs the complete <picture> markup with correct srcset and type attributes, flagging images where AVIF produces a larger file than WebP so you can make per-image format decisions instead of applying a blanket rule.

The web is finally moving past JPEG-only image delivery, but the transition only benefits users when the fallback infrastructure is in place. Build the chain first, verify it works across your browser matrix, and then let AVIF's bandwidth savings flow to the browsers that can use them.