WebP vs AVIF vs JPEG: Which Image Format to Ship in 2026

Format arguments online tend to be benchmark theatre: someone encodes the same parrot photo four ways, posts a table of kilobytes, and declares a winner. Real sites make this decision under constraints benchmarks ignore — an existing library of URLs that already rank, a build pipeline with a time budget, a CMS that only accepts certain uploads, and a team that will not maintain a bespoke encoder chain.

As of July 2026, the practical answer is unglamorous. Serve AVIF where the bytes matter, WebP as the broad default, and stop apologising for JPEG on the pages where it makes no measurable difference. What follows is how to tell those cases apart.

What each format is actually good at

JPEG is thirty years old and still the most interoperable image format on earth. Every device, every CMS, every email client and every social scraper handles it. It is weakest on flat colour and hard edges, where its 8×8 block transform produces the ringing everyone recognises, and it has no alpha channel.

WebP was Google's answer to that, and it is now unremarkable in the best sense: universal browser support, roughly 25 to 30 percent smaller than JPEG at comparable quality, alpha channel included, lossless mode available. Its weakness is low-quality settings, where it smears fine texture into blotches rather than ringing.

AVIF derives from the AV1 video codec and is the current quality-per-byte leader on photographic content. It handles gradients and skies notably better than either predecessor, supports wide colour gamut and HDR, and does alpha properly. Its costs are encode time — frequently ten times slower than WebP, and worse at high effort settings — and a long tail of tools that still cannot open the files.

Here is the shape of the trade-off in the terms that matter when you are choosing:

Consideration	JPEG	WebP	AVIF
Relative file size, photo at comparable quality	baseline	~25-30% smaller	~40-50% smaller
Browser support, shipping versions (July 2026)	universal	universal	all majors
Alpha / transparency	no	yes	yes
Encode cost	negligible	low	high
Quality at aggressive compression	ringing artefacts	blotching	degrades most gracefully
Tooling and CMS handling	everywhere	broad	improving, still gaps
Best fit	compatibility-critical, social sharing	general web default	image-heavy pages, hero images

The decision, in the order you should ask it

Are images the largest thing on the page? If your Largest Contentful Paint element is a photograph and your page weight is dominated by images, AVIF is the highest-leverage change available. A hero image dropping from 240 KB to 130 KB is a real improvement to a real metric.

Is anything downstream going to consume the file? Social scrapers, email templates, third-party marketplaces and legacy partner systems are the reliable sources of "why is the image broken" tickets. Those consumers get JPEG. Open Graph images in particular are not the place to experiment.

Are you encoding thousands of files in a build step? Encode time stops being academic. AVIF at high effort on a large library can turn a two-minute build into twenty. Either lower the effort setting, encode asynchronously outside the critical path, or use WebP and spend the saved time elsewhere.

Does the image have hard edges or text? Screenshots, diagrams and UI captures want lossless or near-lossless treatment. AVIF and WebP both do lossless; a heavily compressed lossy encode of a screenshot looks bad in every format.

For most sites the answer collapses to: WebP everywhere as the default, AVIF for the handful of large above-the-fold images, JPEG for anything a third party will fetch.

Serve them properly, or the choice is wasted

Choosing a format is half the job. The delivery pattern is the other half, and getting it wrong is how teams end up shipping both formats to every visitor.

The <picture> element with type attributes lets the browser pick the first format it understands:

<picture>
  <source srcset="/img/workshop.avif" type="image/avif">
  <source srcset="/img/workshop.webp" type="image/webp">
  <img src="/img/workshop.jpg" alt="Technician programming a key fob at a workbench"
       width="1200" height="675" loading="lazy" decoding="async">
</picture>

Three details in that snippet matter more than the format choice. width and height prevent layout shift. loading="lazy" belongs on below-the-fold images and must not be on your LCP image. And the alt attribute is still the thing screen readers and crawlers use — see our guide to writing alt text for what belongs in it.

If you are on a modern framework, its image component almost certainly does the negotiation for you. Next.js, Astro and Nuxt all generate modern formats and correct srcset sets from a single source file. Hand-rolling <picture> markup when your framework already handles it is a maintenance liability, not a best practice.

For the server-side alternative, content negotiation on the Accept header lets one URL serve three formats. This is what most image CDNs do, and it has a real advantage: your URLs never change, so image-search equity survives the migration.

The migration trap nobody warns you about

The most common self-inflicted wound in this area is a well-intentioned bulk conversion. Someone runs a script that turns 4,000 JPEGs into WebP, updates the HTML, and ships. Two weeks later, image impressions in Search Console are down and nobody can explain why.

What happened is that every image URL changed. Google had indexed /images/downtown-storefront.jpg; it now returns 404, and /images/downtown-storefront.webp is a brand-new URL with no history. Image indexing is slow to begin with — Google's own guidance is candid that it can take considerable time — so the recovery is measured in months.

Two ways to avoid it. Either keep the original URLs and change only what the server sends, using content negotiation or a CDN. Or, if filenames must change, 301-redirect the old paths and resubmit an updated image sitemap so the new URLs get discovered on your schedule rather than Google's.

Either way, do not change filenames and format in the same pass unless the filenames were genuinely bad. If they were — IMG_4471.jpg and friends — that is a separate project with its own payoff, covered in our post on SEO-friendly image filenames.

Quality settings, briefly and without dogma

Most format arguments are really quality-setting arguments. A WebP at quality 90 and an AVIF at quality 50 are not comparable, and quality numbers do not mean the same thing across encoders.

Sane starting points for photographic content: JPEG 80, WebP 82, AVIF 50 to 60. Those are not universal truths — they are where to begin before you look at your own images. The test that matters is visual: encode three versions, view them at the size they will actually be displayed, and pick the smallest one you cannot distinguish from the original. Doing this once on a representative image tells you more than any benchmark table.

One caveat on AVIF: its quality scale is not aligned with JPEG's, and low numbers look better than the equivalent JPEG number would suggest. If you set AVIF to 80 expecting JPEG-80 filesizes, you will get files larger than your WebP and conclude, wrongly, that AVIF does not work.

Run the test on your own images, once

Every published benchmark uses someone else's photographs. Twenty minutes on yours settles the question permanently, and the result will be specific to the kind of content you actually publish.

Pick five images that represent your real range — a hero photograph, a product shot on white, a screenshot with text, a graphic with flat colour, and something with a large area of gradient like a sky or a studio backdrop. Those five cover the cases where the formats diverge most.

Encode each at three settings per format, resize to the largest dimension you actually display first, and record the file sizes. Then view them at display size, on the device that matters most to your traffic, and note the first setting at which you can see degradation. Two findings almost always emerge: the gradient image shows the widest gap in AVIF's favour, and the screenshot shows that lossy compression is the wrong tool regardless of format.

What makes this worth doing is that it converts a permanent argument into a configuration value. You end up with one number per format for your pipeline and you never revisit it.

Don't forget the non-photographic cases

Two formats get left out of these comparisons and both matter.

SVG beats every raster option for logos, icons, diagrams and anything built from shapes. It scales to any size from one small file, stays crisp on high-density screens, and can be styled with CSS. If you are shipping a PNG of your logo at three sizes, SVG replaces all three. Do run it through a minifier, and be aware that SVG can contain scripts — sanitise anything user-uploaded.

Animated content is the other gap. Animated GIF is enormous for what it delivers; both WebP and AVIF support animation at a fraction of the size, and for anything longer than a couple of seconds a muted, looping, autoplaying video file is smaller still and gives the browser better controls over decoding.

Where format sits in the wider picture

Format is one line item in image SEO, and honestly not the first one to fix. Google Search Central's own image documentation leads with things that have nothing to do with encoding: descriptive filenames, real alt text, images placed near the relevant text, and pages that are crawlable at all. The full checklist sorts these by leverage.

The reason format still deserves attention is that it is one of the few items you solve once. Configure your pipeline correctly and every future image inherits it. Compare that with alt text and filenames, which need a human decision per file, forever — which is precisely the work that gets skipped at volume.

That per-file gap is where SEOpix sits: it writes the descriptive filename, alt text and EXIF block at generation time, so the metadata exists before the file reaches your pipeline and your encoder handles a properly named, properly described image rather than output_final_v2.png.

Start with the delivery pipeline, because it scales. Then fix the per-file metadata, because nothing else will. Ten images a month are free if you want to see what generation-time metadata looks like, and the pricing tiers cover the volumes where doing it by hand stops being realistic.