AVIF vs JPG: Modern Compression vs Universal Support

	AVIF	JPG
Year released	2019	1992
Compression	both	lossy
Transparency	Yes	No
Animation	Yes	No
Browser support	95%	100%
MIME type	image/avif	image/jpeg
Extension	.avif	.jpg

Category	Winner	Note
File size	AVIF	AVIF is roughly 50% smaller than JPG at equivalent visual quality for photographic content.
Transparency	AVIF	AVIF supports full alpha; JPG has no transparency at all.
HDR and wide colour gamut	AVIF	AVIF natively supports 10-bit and 12-bit HDR; JPG is 8-bit only.
Browser support	JPG	JPG is universal; AVIF sits at ~94–95% — covered by a <picture> fallback.
Encoding speed	JPG	JPG encodes orders of magnitude faster than AVIF, especially at high quality.
Editor and tooling support	JPG	JPG works everywhere; AVIF support outside browsers is still patchy.

The choice between AVIF and JPG is not which format is "better" — it is which job the file has to do. AVIF wins when a browser renders the image. JPG wins when the file leaves the browser. The table above ranks each category; the sections below explain the reasoning the table cannot, then give a per-use-case decision and the exact markup to serve both at once.

Convert between the two in your browser, no upload: JPG to AVIF and AVIF to JPG.

Why the byte gap exists

AVIF beats JPG because it inherits a video codec, not an image standard from 1992. JPG splits every image into independent 8×8 pixel blocks and applies one transform — the Discrete Cosine Transform. AVIF is the still-image profile of AV1, which adds three tools JPG never had:

Variable block sizes up to 128×128 — large flat regions encode as one unit, not hundreds of 8×8 tiles.
Intra-prediction — each block is predicted from its neighbours before any residual is stored.
Better entropy coding — AV1 uses arithmetic coding, which packs symbols tighter than JPG's Huffman tables.

The practical result, confirmed by 2025–2026 benchmarks: AVIF is about 50% smaller than JPG at matched perceptual quality. An AVIF at quality 75 visually matches a JPG at quality 85–90 while shedding 40–50% of the bytes. The gap is widest on smooth gradients, where JPG's small blocks produce visible banding that AVIF's 10-bit pipeline avoids.

The quality-scale trap

AVIF and JPG quality numbers are not the same scale, and confusing them is the most common AVIF mistake. AVIF quality 50 is roughly JPG quality 85 — standard web delivery. Encoding AVIF at "85" to "match" your JPG produces a near-archival file that wastes the entire size advantage.

The mapping for photographic web content:

JPG 85 → AVIF 50–55 (visually equal, ~50% smaller).
JPG 92 → AVIF 63 (high quality, ~45% smaller).
AVIF 80+ → overkill for the web; reserve for masters.

Tune this once per content type, not per image. The AVIF Compression Settings guide covers the quality and --speed parameters in full.

What JPG simply cannot store

JPG is locked to 8 bits per channel, opaque, single-frame, and SDR. AVIF removes all four limits, which matters for specific content rather than every photo:

Transparency — AVIF carries a full alpha channel; JPG has none. Logos and cut-outs that needed PNG at 5–10× the size become small AVIFs.
10-bit and 12-bit colour — more tonal steps mean sunsets and skies render without the banding JPG bakes in at 8-bit.
HDR and wide gamut — AVIF supports PQ/HLG transfer and BT.2020 / Display P3. A modern phone or OLED panel shows the extra range; JPG cannot represent it at all.
Animation — AVIF stores image sequences, though short MP4/WebM usually beats it for motion.

These are not marginal. For a portfolio shooting in P3 or a UI with transparent badges, JPG is not a smaller option — it is the wrong format. Compare AVIF's lossless and alpha behaviour in AVIF vs PNG.

The one thing JPG still does better

JPG decodes everywhere, instantly, with zero tooling — and that universality is its entire remaining case. Every browser since the 1990s, every email client, every marketplace, and every OS reads JPG. AVIF reaches about 94% of global users as of 2026, per caniuse: Chrome/Edge since v85 (2020), Firefox since v93 (2021), Safari since 16 / iOS 16 (2022).

That ~94% figure is browser-only. Outside the browser, AVIF support is far thinner, and this is where JPG keeps winning:

Email — most clients still do not render AVIF; embed JPG.
Marketplaces and document tools — many require or silently transcode to JPG, so sending AVIF gains nothing.
Encoding cost — libjpeg-turbo encodes a 1200×800 photo in ~50ms; avifenc --speed 4 takes 5–10 seconds. For build pipelines touching thousands of images, that turns a 2-minute build into 15–30 minutes.

JPG's job is portability and speed of production. The AVIF Browser Support guide details exactly which environments still need the fallback.

Ship both with one element

Serve AVIF first and let the browser fall back to JPG automatically — no JavaScript, no user-agent sniffing. The <picture> element picks the first <source> the browser understands, then drops to the <img>:

<picture>
  <source
    type="image/avif"
    srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
    sizes="(max-width: 768px) 100vw, 1600px"
  />
  <source
    type="image/webp"
    srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w"
    sizes="(max-width: 768px) 100vw, 1600px"
  />
  <img
    src="/img/hero-1600.jpg"
    srcset="/img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w"
    sizes="(max-width: 768px) 100vw, 1600px"
    alt="Sunset over the harbour"
    width="1600"
    height="900"
    loading="lazy"
    decoding="async"
  />
</picture>

The optional WebP <source> catches the narrow band of browsers that read WebP but not AVIF. Keep the JPG masters — the fallback needs them, and they are your re-encode source if the codec ever changes. Frameworks automate this: Next.js negotiates AVIF when images.formats lists ["image/avif", "image/webp"]. See AVIF vs WebP for the middle layer's value.

Pick by use case

Match the format to where the image lives, not to a blanket rule:

Hero and LCP images — AVIF, always. The byte savings move Core Web Vitals directly; encode once at high effort.
Thumbnails and galleries — AVIF. The savings compound across dozens of files per page, and AVIF's edge is widest at small sizes.
Photography portfolios — AVIF for delivery (10-bit, P3), JPG masters retained for client downloads and prints.
Product photos — AVIF via a CDN that encodes on the fly (Cloudflare, Cloudinary, Imgix, Vercel), so build time stays flat.
Email and attachments — JPG. AVIF will not render in most inboxes.
One-off uploads to platforms you do not control — JPG, since they transcode anyway.

When in doubt, AVIF for rendering on your own pages, JPG for everything that travels. The AVIF Optimization guide ties this into a full delivery pipeline.

FAQ

Is AVIF actually 50% smaller than JPG, or is that marketing?

It is real for photographic content at matched perceptual quality, and independent 2026 tests confirm it. Expect 40–60% depending on the image — gradient-heavy photos save most, already-noisy or grainy shots save least. The 50% figure is a safe planning average, not a guarantee per file.

Should I delete my JPGs after converting to AVIF?

No. Keep the JPG masters for two reasons: the <picture> fallback serves them to the ~6% of traffic without AVIF, and they remain your highest-fidelity source for any future re-encode. Treat AVIF as a delivery format generated from JPG, not a replacement for it. Convert losslessly back any time with AVIF to JPG.

Why does my AVIF look worse than my JPG?

You almost certainly encoded at too low a number for AVIF's scale. AVIF 50 ≈ JPG 85, so an AVIF saved at "30" to mimic an aggressive JPG will look soft. Raise AVIF quality to 50–60 for web delivery; the file stays far smaller than the JPG even then. See lossy vs lossless for how each scale behaves.