AVIF vs WebP vs JPEG — matched-quality size, encoder speed, and browser support in 2026

The short version

• JPEG (1992) — lossy, no alpha, universal support. The lowest common denominator. Still 40% of all web images as of 2026.
• WebP (2010) — Google's VP8-based still image format. Lossy AND lossless modes, supports alpha. ~25–35% smaller than JPEG at matched quality. Supported everywhere modern since 2020.
• AVIF (2019) — based on AV1 video intra-frames. Best compression of the three — ~50% smaller than JPEG, ~20% smaller than WebP at matched SSIM. Slow encode, decent decode. Universal since Safari 16.4 (March 2023).

If you can only ship one: use JPEG for photos going to email, legacy CMSs, or unknown recipients; use WebP for modern websites where you want a single file format that covers 97% of visitors; use AVIF when bandwidth matters more than encode time (product catalogs, hero images, CDN-served photography). If you can ship three: use a <picture> element with AVIF first, WebP second, JPEG fallback. We cover that pattern below.

Matched-quality file size — the honest bench

Every "AVIF is 50% smaller!" claim floating around is measuring something slightly different. The only fair comparison is: encode the same source image to each format, tune each encoder until the result hits a target SSIM (structural similarity, a perceptual quality metric; SSIM 0.98 is "indistinguishable from source to a trained eye"), then compare file sizes. Here's the result on a set of typical web images (2000×1333 photo, 1200×800 product shot, 1600×900 UI screenshot with gradient):

The pattern holds across content types, with nuances: for photos, AVIF's lead widens (it handles film grain and noise better than either alternative); for UI screenshots and flat-color graphics, lossless WebP often beats AVIF because AVIF's lossless mode is weaker than lossless WebP's VP8L coding. For line art, line art, PNG is still competitive; neither AVIF nor WebP beats PNG by much on palette-style images.

Encoder speed — AVIF's biggest tax

Compression performance is only half the story. The other half is how long it takes to produce that compressed file. This is where AVIF is dramatically, sometimes painfully, worse than the alternatives. On our reference 2000×1333 photo:

• JPEG — libjpeg-turbo encodes in ~40 ms on a modern CPU. Instantaneous for any practical purpose.
• WebP — libwebp at default settings encodes in ~200 ms. Still fast enough for real-time pipelines.
• AVIF — libavif with SVT-AV1 preset 6 takes ~2–4 seconds per image. At preset 0 (maximum quality), it climbs to 30+ seconds. rav1e is similar. aomenc is 2–5× slower than SVT-AV1.

For a static site build or a CDN on-the-fly pipeline, a 2–4 second AVIF encode per image is fine — it happens once, caches forever. For a live upload flow where users wait for the encode to complete, AVIF is rough. This is why WebP remains the default on most modern CMSs: it's a reasonable compromise between compression and encode time.

Decoder speed — AVIF is slower here too

Encode speed is a developer-experience problem. Decode speed is a user-experience problem — it decides how fast images paint on your visitor's screen. AVIF's AV1 decoder is more complex than JPEG's DCT-based decoder, and while modern browsers ship with optimized implementations, the cost is real:

• JPEG — ~5 ms to decode a 2000×1333 image on a mid-range phone CPU.
• WebP — ~10–15 ms, roughly 2× JPEG.
• AVIF — ~20–40 ms depending on CPU, roughly 4× JPEG.

On modern devices you will not notice. On a mid-range Android phone with 30 images on a page, you might — especially if images are above the fold. This is one reason large sites (YouTube thumbnails, for example) often serve WebP rather than AVIF even though they have the encoder budget for AVIF: the downstream decode cost matters when you're shipping to hundreds of millions of low-end devices.

Browser support matrix — 2026

This used to be the argument-winner for JPEG. It still is, barely, but the gap has narrowed to insignificance for most use cases:

The practical read: WebP is safe for any web audience in 2026. AVIF is safe for any web audience that isn't running iOS 15 or older — roughly 6% of visitors globally, skewing older and lower-income. Email clients (especially Outlook desktop) still want JPEG; don't put WebP or AVIF in an email unless you know your audience.

When each format wins

Use JPEG when:

• The destination is email, a legacy CMS, or an unknown recipient.
• The image is a photograph and will never be edited again (JPEG's generation-loss is real but low at Q85).
• File-size budget is loose and you want zero compatibility drama.
• The source is already a JPEG and a round-trip to another format would add loss for no benefit.

Use WebP when:

• The destination is a modern website and you want one file format for the whole audience.
• You need transparency AND smaller file size than PNG.
• You're building a product where encode time matters (user upload flow, real-time preview).
• You want a format that's ~30% smaller than JPEG without the encode cost of AVIF.

Use AVIF when:

• Bandwidth matters more than encode time (CDN-served photography, product catalogs, hero images).
• You can pre-encode during build time (static site, Next.js image pipeline, Cloudflare Images).
• Your audience is ≥95% on browsers that ship AVIF (check your analytics; most sites are there in 2026).
• You're OK shipping a <picture> fallback for the 5–6% on legacy browsers.

The <picture> pattern — ship all three

If you're building for the web and care about both bandwidth AND compatibility, the correct answer isn't to pick one format. It's to ship all three and let the browser pick:

<picture>
  <source srcSet="/hero.avif" type="image/avif" />
  <source srcSet="/hero.webp" type="image/webp" />
  <img src="/hero.jpg" alt="..." width="1600" height="900" />
</picture>

Chrome, Firefox, and Safari 16.4+ pick the AVIF. Older Safari and Outlook-on-the-web pick the WebP. Email clients and ancient browsers pick the JPEG. You pay three encodes once at build time and serve ~50% less bytes to most visitors than JPEG-only. Next.js, Astro, and most modern site frameworks automate this pipeline — you upload one JPEG and the framework ships three formats. If you're not on such a framework, our conversion tools (JPG to AVIF, JPG to WebP) produce the assets.

What about PNG and HEIC?

This post is scoped to AVIF/WebP/JPEG because those are the three formats competing for the same web-delivery job. Related:

• PNG vs JPG decision tree — PNG is the right answer for screenshots, UI, logos, and anything with sharp color edges, where all three of our formats here are overkill or lossy.
• Convert WebP to JPG — if you have WebP files from a CMS and need JPG for a legacy destination.
• Compress JPEG honestly — if sticking with JPEG, the quality curve and chroma subsampling matter more than the format debate.

How our tool compares (honestly)

AVIF/WebP/JPEG conversion is commodity functionality. What differs is defaults, transparency handling, encode-quality tuning, and whether the UI tells you what it's doing.

Common questions

Is AVIF really 50% smaller than JPEG?

At matched perceptual quality (SSIM 0.98 on photographs), yes, typically 45–55% smaller. That number shrinks on low-frequency content (flat skies, clean gradients) and grows on high-frequency content (textured surfaces, film grain). The universal "50%" headline glosses over which quality level you're matching — compare at Q100 and JPEG can win on file size because AVIF doesn't have a true "lossless photo" mode.

Why don't more sites use AVIF then?

Three reasons: (1) encode time at scale — if you have 10 million images, a 3s AVIF encode is 10,000 CPU-hours, and you also need to keep the JPEG/WebP fallbacks, so storage triples; (2) the last 5% of visitors on legacy browsers still need a fallback, which most CMS pipelines don't automate gracefully; (3) Safari support only became practical in 2023, so the pipeline investment was deferred by years of uncertainty.

What about JPEG XL?

JPEG XL is the format that should win this comparison — it handles lossless, lossy, photos, and UI graphics better than all three above. But Chrome dropped support in 2022, Safari added partial support in 17, and AVIF won the CDN pipeline race. JPEG XL is great, shipping in image workflows (Photoshop, Affinity) and native apps, but not a practical web delivery choice in 2026 without a fallback chain.

Does AVIF support transparency?

Yes — 8-bit and 10-bit alpha, coded more efficiently than PNG or WebP alpha. If you have a transparent logo and can afford the encode cost, AVIF is the smallest result. For compatibility, keep a PNG or WebP alpha fallback.

Does AVIF support animation?

Yes — it's AV1 under the hood, the same video codec YouTube and Netflix use. Animated AVIF can replace both animated GIF and animated WebP, and the file sizes are dramatically smaller. Browser support for animated AVIF is a step behind still AVIF; check your audience.

Can I convert between these formats losslessly?

Not truly. Each format has a different color encoding and quantization, so a round-trip always introduces some loss. WebP and AVIF both have "lossless" modes, but they're lossless only from the pixel buffer you feed them — decoding a JPEG (which already has loss) and re-encoding as lossless AVIF preserves the JPEG's flaws, not the original photo. For minimum loss, keep your master as PNG/TIFF and encode down to lossy formats from there.

Do files get uploaded to your server?

No. All three encoders run client-side as WASM modules (libjpeg-turbo, libwebp, libavif + SVT-AV1). Your files never leave the browser tab.

Ready?

For most 2026 web pipelines, the right answer is "ship all three via <picture>." Start with JPG to WebP and JPG to AVIF to generate the modern encodings; keep your JPEG as the fallback. If the destination requires JPEG specifically (email, legacy CMS), our WebP to JPG and AVIF to JPG tools go the other way. All free, all in-browser, all no-signup.