JPG vs AVIF

The short answer

For browser-delivered photographic content, AVIF wins decisively over JPG on file size — typically 50% smaller at equivalent visual quality. It also supports transparency and HDR, which JPG can't represent. The remaining case for JPG is universal compatibility outside the browser — email, marketplace uploads, social platforms, and any context where the recipient's tooling isn't guaranteed to be modern.

The most common pattern in 2026 is shipping AVIF with a JPG fallback via <picture>. Capable browsers (~94–95% of traffic) get AVIF; the long tail still gets the JPG.

For more on the formats themselves, see JPG Format and AVIF Format.

The generational gap

JPG was specified in 1992. AVIF was specified in 2019. That's 27 years of compression-codec progress.

JPG's design is built around the Discrete Cosine Transform applied to 8×8 pixel blocks, with each block compressed independently. The format was optimised for the hardware of the early 1990s — limited memory, limited CPU, no neural networks, no machine-learned compression. It's remarkable that JPG remains competitive at all given how much has changed.

AVIF is built on the AV1 video codec, which uses block sizes up to 128×128 pixels, dozens of intra-prediction modes, sophisticated transform options (DCT, ADST, identity), arithmetic coding, and loop filtering. The codec embodies decades of research into how images can be represented more compactly.

The result is a generational compression improvement. On a typical photographic image:

• JPG q=85 → some baseline file size.
• WebP q=80 → about 70% of the JPG size.
• AVIF q=50 → about 50% of the JPG size.

The AVIF win over JPG is roughly the same magnitude as the WebP win over JPG, on top of it.

Where AVIF wins

File size

The headline. Roughly 50% smaller files than JPG at equivalent visual quality on photographic content.

Rough relationships for typical content:

For image-heavy pages, the cumulative weight reduction is substantial. A page that ships 2 MB of JPGs typically ships 950 KB – 1.1 MB as AVIF.

Transparency

JPG cannot encode an alpha channel. AVIF supports full alpha. For content with transparency that would historically have required PNG (often at 5–10× the file size of JPG), AVIF is a dramatic improvement.

HDR and wide colour gamut

AVIF natively supports 10-bit and 12-bit per channel encoding with HDR transfer functions (HLG, PQ) and wide colour gamut spaces (BT.2020, Display P3). JPG is 8-bit and SDR only.

For content delivered to HDR-capable displays — modern smartphones, recent monitors, OLED TVs used as monitors — AVIF can carry the full dynamic range. JPG can't represent it at all.

Animation

AVIF supports image sequences (animation). JPG is single-frame only.

In practice, animated content is usually better served by short MP4/WebM video than by animated AVIF. But the capability exists if needed.

Where JPG still wins

Universal compatibility

Every browser, every email client, every social platform, every document tool, every operating system, every embedded device handles JPG. The format has been universal since the mid-1990s.

AVIF support, while broad in modern browsers (~94–95% of global traffic), is still uneven outside browsers:

• Email clients — mostly don't render AVIF. Use JPG.
• Social media uploads — most platforms accept AVIF but transcode to their preferred format. Sending AVIF gains nothing.
• Marketplace listings — many require JPG or transcode to it anyway.
• Document embeds — Word, PowerPoint, Google Docs handle JPG perfectly; AVIF support is patchy.
• Image-viewing tools on older OSes — JPG always works; AVIF needs reasonably recent versions of macOS, Windows, iOS, Android.

For files that will live outside the browser, JPG remains the universal default.

Encoding speed

JPG encoders are simple and fast. AVIF encoders, particularly at high quality and high effort settings, are orders of magnitude slower than JPG encoders.

A typical 1200×800 photo:

• JPG encode (libjpeg-turbo) — ~50ms.
• WebP encode (-m 6) — ~250ms.
• AVIF encode (avifenc --speed 4) — 5–10 seconds.
• AVIF encode (avifenc --speed 8) — 1–2 seconds.

For build pipelines that encode hundreds or thousands of images at build time, the difference is material. A build that takes 2 minutes with JPG-only encoding can take 15–30 minutes with AVIF encoding.

For one-time encoding of important assets (heroes, product photos for ecommerce), the time investment is fine. For high-volume encoding, the cost matters.

Decoding speed

AVIF decoding is also slower than JPG decoding, particularly on low-end mobile devices. The byte savings on transfer can be partially offset by longer decode times on the client.

Modern flagship phones decode AVIF imperceptibly fast. Mid-range and budget phones, particularly older Android devices, can show measurable decode-time penalties. For audiences skewed toward these devices, measure before committing.

Editor and tooling support

Photoshop added AVIF support in version 24 (October 2022). Affinity Photo, GIMP, Sketch, Figma all support AVIF in recent versions. The tooling is good and improving — but JPG support is universal across every image-handling tool ever shipped, and the long tail still matters for some workflows.

The practical pattern

For modern web delivery with broad compatibility:

<picture>
  <source
    type="image/avif"
    srcset="
      /img/photo-800.avif 800w,
      /img/photo-1200.avif 1200w,
      /img/photo-1800.avif 1800w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <img
    src="/img/photo-1200.jpg"
    srcset="/img/photo-800.jpg 800w, /img/photo-1200.jpg 1200w"
    sizes="(max-width: 768px) 100vw, 1200px"
    alt="..."
    width="1200"
    height="675"
    loading="lazy"
    decoding="async"
  />
</picture>

The browser uses AVIF when supported; falls back to JPG otherwise. No JavaScript required.

For sites that want maximum modern coverage, the three-source pattern adds WebP as an intermediate fallback:

<picture>
  <source type="image/avif" srcset="..." />
  <source type="image/webp" srcset="..." />
  <img src="..." alt="..." />
</picture>

AVIF-capable browsers get AVIF; WebP-capable browsers get WebP; everyone else gets JPG. Detail in WebP vs AVIF.

When to ship AVIF

Ship AVIF when:

• The site is performance-critical and image weight is a binding constraint.
• You have CDN-based image conversion (Cloudflare Polish, Cloudinary, Imgix, Vercel) — the encoding cost lives at the CDN, not at build time.
• The site has HDR content that JPG can't represent.
• Your audience trends toward modern devices where AVIF decode is imperceptibly fast.
• You're willing to ship <picture> with JPG fallback for the ~6% of traffic that doesn't support AVIF.

When to stick with JPG (with WebP fallback)

Skip AVIF when:

• The build pipeline encodes images at build time and AVIF would meaningfully slow it down.
• Your audience skews toward low-end mobile where decode cost matters.
• The site already ships WebP (the marginal AVIF win is smaller than the WebP win, and pipeline complexity adds up).
• The content lives outside the browser frequently (downloads, email, marketplace listings).

Migration considerations

If you're moving from a JPG-only delivery to AVIF-with-fallback:

1. Keep the JPG originals. The <picture> fallback needs them.
2. Encode AVIF at q≈50 (which corresponds visually to JPG q≈85). The quality scale isn't 1:1.
3. Use --speed 4 for production-quality output. Faster speeds produce larger files; slower speeds take longer.
4. Update HTML to use <picture> with the JPG fallback inside.
5. Audit Core Web Vitals in Search Console after a week. LCP usually improves materially. See Core Web Vitals & Images.
6. Verify image SEO didn't regress. Google indexes AVIF; the migration shouldn't hurt rankings. See Image SEO Best Practices.

File size benchmarks

Concrete numbers from typical content:

The AVIF advantage is most pronounced on smaller thumbnails (where AVIF's prediction overhead is amortised over fewer bytes) and on content with smooth gradients (where the larger block sizes find more redundancy).

Recommendation

For new image-heavy sites: ship AVIF as primary with JPG (or WebP+JPG) fallback. Accept the encoding cost; the payload reduction compounds across every page load.

For existing JPG-only sites: assess whether the migration cost (encoding pipeline, build time, additional <source> elements) justifies the win. For ecommerce and image-heavy publishing, almost always yes. For low-traffic informational sites, often the simpler WebP-only migration is enough.

For sites that already ship WebP: the marginal AVIF improvement is real but smaller. Weigh against pipeline complexity.

For content distributed outside the browser: stick with JPG.

Common questions

Is AVIF really 50% smaller than JPG?

For typical photographic content at equivalent visual quality, yes. The figure varies by content — some images compress closer to 60% smaller, others closer to 40%. The 50% figure is a reliable rule of thumb across mixed content.

Why does my AVIF look worse than my JPG at the same quality number?

AVIF and JPG quality scales aren't the same. AVIF q=50 is roughly equivalent to JPG q=85. AVIF q=85 would be archival quality, not standard web delivery. If your AVIF looks worse, you may have encoded at too low a quality for the scale.

Will AVIF replace JPG?

Over a 10–15 year horizon, plausibly. JPG has been universal for 30+ years and won't disappear quickly. AVIF is the cleanest long-term bet for web delivery, but JPG's universal compatibility means it will persist for cross-platform sharing.

What about JPEG XL?

JPEG XL has impressive technical properties (lossless recompression of existing JPGs, progressive decoding) but hasn't gained browser support. Chrome shipped support briefly, then removed it in 2022. AVIF is the realistic modern web option; JPEG XL is a hypothetical alternative.

Can my image CDN handle AVIF?

Most modern CDNs do. Cloudflare Polish, BunnyCDN Optimizer, Cloudinary, Imgix, Fastly Compute, Vercel Image Optimization all support automatic AVIF conversion based on the request Accept header. Check your provider's documentation.

Convert your images

• JPG to WebP — convert JPG library to WebP (a useful intermediate step before AVIF)
• WebP to JPG — convert back to JPG for distribution

Further reading

• JPG Format — technical detail on JPG
• AVIF Format — technical detail on AVIF
• WebP vs JPG — the intermediate migration step
• WebP vs AVIF — direct comparison between the two modern formats
• WebP Optimisation — broader performance walkthrough
• WebP Compression Settings — encoder parameter reference (analogous principles for AVIF)
• Core Web Vitals & Images — measuring real-world impact