AVIF, WebP, and when JPEG is still the right call

AVIF and WebP both compress images significantly smaller than JPEG at comparable visual quality, and both are now broadly supported across modern browsers. That doesn't mean every image on every site should switch immediately, and the exceptions are worth understanding rather than defaulting blindly to the newest format available.

We get asked some version of "which format should we use" on nearly every performance audit, usually framed as if there's a single universally correct answer waiting to be revealed. There isn't. The right answer depends on what kind of image it is, how it's generated, and what's actually consuming the bandwidth savings, and treating format choice as a one-time decision applied uniformly across an entire image library tends to under-optimize some images and over-engineer others.

AVIF typically produces the smallest files of the three for photographic content, sometimes 30 to 50 percent smaller than an equivalent WebP at similar quality. The caveat is encoding time: AVIF takes meaningfully longer to encode than WebP, which matters if you're generating images on demand rather than pre-processing a fixed asset library.

That encoding cost is easy to overlook until it shows up as a real infrastructure decision. A site generating user-uploaded images on the fly, a marketplace listing photos, a social feature, needs to weigh AVIF's file size win against the server time and cost of encoding every upload in that format at request time, versus pre-encoding a smaller, fixed set of marketing assets where the one-time encoding cost barely registers.

WebP support is now essentially universal across current browsers, encoding is fast, and file size savings over JPEG are still substantial, typically 25 to 35 percent. For most client sites, WebP with a JPEG fallback for any remaining edge cases is the pragmatic default we reach for, balancing savings against implementation complexity.

For images with fine photographic detail and grain where compression artifacts matter, or when working with tools and pipelines that don't cleanly support the newer formats yet, JPEG at a well-tuned quality setting remains a reasonable choice. It's not that JPEG is obsolete, it's that it's no longer the default best choice for most web use cases.

We also see JPEG remain the right call in legacy integrations, an older email marketing platform, a print-to-web pipeline someone built years ago and doesn't want to touch, where introducing a newer format would mean rebuilding a working, if unglamorous, process for a modest file size gain that doesn't justify the risk. Not every optimization is worth the disruption it would take to implement, and we say so when that's genuinely the case.

The single biggest image performance win for most sites we audit isn't format, it's serving an appropriately sized image for the actual display size instead of a full-resolution original scaled down by CSS. A correctly-sized JPEG often beats a full-resolution AVIF in real-world load time, because dimension mismatch usually wastes more bytes than format choice saves.

We've watched clients spend real budget on a format migration before fixing sizing, and come away disappointed with the result, not because the format choice was wrong but because it was solving the smaller half of the problem.

Bulk-converting an entire existing image library to AVIF without also fixing sizing and lazy-loading is a partial win at best. We audit the full image pipeline together, format, dimensions, compression quality, loading strategy, because these variables interact, and optimizing only one of them tends to leave real performance on the table.

We've seen clients arrive having already paid for a format-only migration from a previous vendor, expecting a meaningful speed improvement, and come away disappointed because the underlying sizing and loading problems were never touched. Explaining upfront that format is one lever among several, not the whole solution, sets a more accurate expectation for what a given piece of optimization work will actually deliver.

Logos, icons, and simple illustrations belong in SVG regardless of the raster format conversation entirely, since SVG scales losslessly to any size at a fraction of the file weight of even a well-compressed raster equivalent. We still find client sites shipping a PNG logo where an SVG would be both smaller and sharper on high-density displays.

The confusion here usually comes from treating "image optimization" as a single category rather than recognizing that photographic content and vector content have almost nothing in common as optimization problems. A logo doesn't benefit from AVIF's compression advantages at all, since it was never a good candidate for raster compression in the first place. We flag this distinction early in any audit specifically because it's such an easy, low-cost win once someone actually notices it.

Format and sizing matter most for what loads immediately; for images further down a long page, when they load matters just as much as how large they are. We set native lazy loading on every image outside the initial viewport by default, which means the format savings on those images compound with the fact that many visitors never scroll far enough to trigger the download at all.

We serve AVIF with a WebP fallback and a JPEG final fallback, generated automatically at build time with responsive srcset sizing, using Next.js's built-in image optimization or an equivalent pipeline. That covers the format question and the sizing question together, which is where the real performance gain actually comes from.

This setup is deliberately boring and automatic rather than something a content editor has to think about on every upload. A marketing team dropping a full-resolution photo into a CMS field shouldn't need to know what AVIF is; the pipeline should handle format selection, resizing, and fallback generation invisibly, and the only thing that should require a human decision is the rare edge case the automated pipeline doesn't handle well, which we flag specifically rather than leaving as a silent gap.