Image formats in 2026: AVIF, WebP, and when to bother

AVIF and WebP both offer meaningfully smaller file sizes than JPEG or PNG at comparable visual quality, often 30 to 50 percent smaller. Browser support for both is now strong enough that the compatibility argument against adopting them has mostly disappeared. Whether the migration is worth doing on a given site is still a real question, though, and the answer depends on how image-heavy the site actually is.

We get asked about this migration more often than almost any other performance topic, usually framed as a simple yes-or-no question, and the honest answer is that it's rarely worth treating as an isolated project. It's most valuable when it's rolled into a broader image pipeline overhaul, one that also addresses responsive sizing, lazy loading, and compression quality settings at the same time, rather than as a standalone format swap bolted onto an otherwise unchanged pipeline.

AVIF typically produces smaller files than WebP at the same visual quality, but takes meaningfully longer to encode, which matters for sites generating images dynamically at request time rather than pre-optimizing a fixed set of assets. For a mostly static image library, that encoding time difference barely matters. For a platform generating custom images on demand, it can.

We've measured encode times on a representative product catalog and found AVIF taking three to five times longer than WebP for a comparable batch, which is a real cost for a site regenerating thousands of variants on a deploy pipeline with a tight build-time budget. In that situation, WebP alone, or a mixed strategy defaulting to WebP with AVIF reserved for a smaller set of hero images, is often the more practical choice than pushing for AVIF everywhere on principle.

The `<picture>` element with multiple `<source>` formats lets the browser pick the best format it supports, falling back to JPEG for the rare older browser. Modern image CDNs and Next.js's built-in image optimization handle this automatically, which removes most of the manual effort that used to make this migration feel like a bigger project than it actually is now.

This is the part of the migration that's gotten dramatically easier over the past few years, to the point where a site already running through a capable image CDN or framework-level optimizer often gets modern format support essentially for free, with no manual re-encoding pipeline to build or maintain. Checking whether the existing stack already supports this before scoping a custom solution is worth doing first, since it's a surprisingly common case where the work is already mostly done.

A text-heavy site with a handful of images gets a marginal win from this migration compared to fixing render-blocking scripts or web font loading, which usually have a bigger effect on Core Web Vitals for that kind of site. We prioritize image format migration specifically for image-heavy sites, like eCommerce catalogs and photography-driven brand sites, where the cumulative savings across dozens or hundreds of images actually shows up in the metrics.

We run a quick calculation before recommending this work to any client: total image weight as a share of overall page weight. Below roughly twenty percent, other performance work almost always delivers a better return on the same hours. Above that, and especially on catalog or gallery pages where images dominate the page weight entirely, format migration moves to the top of the priority list because the math simply favors it.

A poorly chosen quality setting on a modern format can produce a file barely smaller than a well-optimized JPEG, while an aggressive quality setting on the same modern format can introduce visible artifacts on certain image types, photography with fine texture or gradients being the most common casualty. We test quality settings per image category rather than applying one blanket setting across an entire catalog, since a setting that looks fine on a product photo can degrade noticeably on a lifestyle image with more subtle tonal variation.

This category-by-category testing takes real time upfront, usually a day or two of comparison work across a representative sample from each image type in the catalog, but it prevents the far more expensive mistake of shipping a blanket quality setting, discovering weeks later that one entire product category looks noticeably degraded, and having to re-process thousands of images after the fact. Getting the setting right once, per category, at the start of the migration is a much smaller job than fixing it retroactively across a live catalog.

For a typical mid-sized eCommerce catalog, our default recommendation is WebP as the primary format, with a modern image CDN handling on-the-fly resizing and format negotiation rather than a custom-built pipeline maintained in-house. AVIF gets reserved for hero and marketing imagery specifically, where the extra compression is worth the slower encode time because those images are processed once and served many times rather than generated dynamically at volume.

This split gives most catalogs the bulk of the available savings without taking on the encoding overhead of AVIF everywhere, and it's a configuration we can usually stand up within a day or two once the underlying CDN or optimization service is already in place. Clients who've gone through this migration with us consistently report a meaningful, measurable drop in page weight on their highest-traffic catalog and category pages within the first reporting cycle after launch.

A site with years of accumulated JPEG and PNG assets doesn't need a big-bang re-encoding project to benefit from modern formats. We typically set up format conversion at the CDN edge, generating a WebP or AVIF variant on first request and caching it going forward, rather than batch-converting an entire historical library upfront. This means the migration happens gradually and automatically as pages actually get traffic, with zero risk of a botched bulk conversion corrupting older assets nobody has looked at directly in years.

The one exception is a library small enough to convert in a single afternoon, where batch conversion upfront is simpler than setting up on-demand conversion for a handful of images. Most catalogs of any real size, though, benefit more from the edge-conversion approach, since it avoids a large one-time processing job and instead spreads the work out naturally over the images that are actually being viewed.