skip to content

For the same photograph, what do AVIF and WebP actually buy you over JPEG, and what are the tradeoffs that stop you from simply encoding everything as AVIF?

level: middleimportance: must knowfreq 72%

answer

  1. newer codecs, same photo, fewer bytes
  2. encode time is the hidden cost
  3. AVIF wins hardest at low bitrate
  4. lossy WebP is always 4:2:0
  5. tiny flat images can get bigger

basics

~20 s

Both compress photographs far better than JPEG — WebP typically around a quarter to a third smaller, AVIF usually smaller again — and both support alpha. AVIF costs much more CPU to encode, can smear fine detail, and can inflate tiny flat images.

solid answer

~50 s

WebP and AVIF are still-image codecs derived from video coding — WebP from VP8, AVIF from AV1 — so they carry decades of compression work that JPEG predates. On a typical photograph, well-tuned WebP lands roughly 25–35% below a comparable JPEG, and AVIF commonly beats WebP again by a wide margin, with its biggest wins at low bitrates where JPEG falls apart into blocking. Both add alpha transparency and animation, which JPEG has neither of, and AVIF additionally handles 10-bit and wide-gamut colour. The costs are real: AVIF encoding is far more CPU-hungry, it can smooth away fine texture and text if you push quality down, its fixed overhead can make a tiny flat icon *larger* than the PNG, and it decodes more expensively than JPEG on weak devices. Support is broad now — Chrome, Firefox and Safari 16.4+ — but you still need a fallback path.

code

javascript · 9 lines
javascript
const sharp = require('sharp');

(async () => {
  const src = sharp('hero.jpg').resize(1600);

  await src.clone().avif({ quality: 55, effort: 4 }).toFile('hero.avif');
  await src.clone().webp({ quality: 78 }).toFile('hero.webp');
  await src.clone().jpeg({ quality: 80, mozjpeg: true }).toFile('hero.jpg');
})();

go deeper

for a junior

Know that WebP and AVIF are newer photo formats that beat JPEG on size, that both support transparency, and that older browsers still need a fallback image.

for a middle

Explain why they win — video-derived prediction and entropy coding — and name concrete tradeoffs: AVIF's encode cost, its smoothing at low quality, and lossy WebP's fixed 4:2:0 chroma.

for a senior

Demonstrate judgment about where conversion pays: verifying savings on your own asset classes, excluding tiny and text-heavy images, and weighing extra decode cost on low-end devices against the bytes saved.

for a principal

Own the format policy and its lifecycle — which tiers exist, how encode CPU and storage are budgeted, and on what evidence you would eventually retire a legacy fallback.

## Where these formats come from JPEG dates from 1992. WebP is built on the intra-frame coding of the VP8 video codec; AVIF wraps the intra-frame coding of AV1 in the HEIF container. Each newer codec brings better prediction, larger and more flexible block partitioning, and smarter entropy coding than the one before, so at the same perceived quality it needs fewer bits. That is the entire pitch: same picture, fewer bytes, no markup change on the page beyond how the file is chosen. ## What you actually gain Expect ranges, not guarantees — savings depend heavily on the image and on how carefully you tune the encoder: - **WebP vs JPEG:** commonly 25–35% smaller at comparable perceived quality for lossy photographic content. Lossless WebP also usually beats PNG on flat artwork. - **AVIF vs WebP:** frequently another substantial cut, and the gap widens as you push quality down. At aggressive settings AVIF still produces a soft but coherent image where JPEG shows blocking and ringing. - **Capabilities:** both support an alpha channel and animation. AVIF additionally supports 10- and 12-bit depth and wide-gamut/HDR colour, which matters for photography-led sites. On an image-heavy page these are among the cheapest wins available, because nothing about the layout, the JavaScript or the design changes. ## What AVIF costs **Encode CPU.** AVIF encoding is far slower than JPEG or WebP, and the encoder exposes a speed/effort dial that trades encode time for file size at the same quality. That is fine for build-time or cached derivatives and painful for anything synchronous. ```bash cwebp -q 78 hero.png -o hero.webp avifenc --min 24 --max 32 --speed 6 hero.png hero.avif ``` The slower the AVIF speed setting, the more search the encoder does and the smaller the file — decoding is unaffected by that choice. **Detail smearing.** AVIF's strength at low bitrates comes partly from aggressively smoothing what it judges to be unimportant. Push it too far and fine texture — skin pores, fabric weave, foliage, small text inside a screenshot — turns waxy. It fails softly rather than blockily, which is nicer but also easier to ship without noticing. **Small-image overhead.** Container and header cost plus a codec tuned for photographic content means a 2 KB flat icon can come out *larger* as AVIF than as PNG or SVG. Below a few kilobytes, stop converting. **Decode cost.** AVIF is more expensive to decode than JPEG. On a low-end phone that is a real, if usually modest, cost paid against the bytes you saved. ## What WebP costs WebP's main technical wart is that **lossy WebP is always 4:2:0 chroma subsampled** — colour is stored at half resolution in each dimension. On saturated edges, especially reds against dark backgrounds, and on coloured text, that produces visible fringing. Lossless WebP stores RGB and does not have this problem; AVIF can encode 4:4:4 when you ask for it. WebP is also simply an older codec, so where AVIF is available it usually wins on size. ## Where JPEG still holds on JPEG is universally decodable, decodes very cheaply, encodes almost instantly, and with a modern encoder such as mozjpeg it is meaningfully better than a naive one. It remains the sane fallback and the sane choice when encode time or maximum compatibility dominates. "Modern format everywhere" is a goal, not a religion. ## Support and fallback WebP is available in every evergreen browser. AVIF shipped in Chrome 85, Firefox 93 and Safari 16.4, so as of 2026 it covers the large majority of real traffic — but "large majority" is not "all", and a still-meaningful slice of long-tail devices and in-app browsers need something else. Any AVIF deployment therefore needs a fallback path, whether that is chosen in markup or negotiated by the server. Shipping AVIF with no fallback is how you produce broken images for the users least likely to report them. ## How to decide, in practice 1. **Photographs:** AVIF first, WebP as the middle tier, JPEG as the floor. Verify the savings on your own images rather than trusting a benchmark from someone else's. 2. **Flat artwork and screenshots:** lossless WebP or PNG; check whether AVIF actually wins before adding it. 3. **Tiny assets and icons:** SVG or a sprite; modern lossy formats have nothing to offer at that size. 4. **Anything with text in the picture:** be conservative with quality, and consider disabling chroma subsampling. 5. **Measure the end result, not the byte count alone.** A smaller file that decodes slower on a cheap phone is not automatically a win; confirm against real-user data.

  • Why can an AVIF version of a small flat icon end up larger than the PNG?
    Because the fixed cost dominates. AVIF carries container and header overhead, and its coding tools are tuned for photographic content where prediction pays off. A 2 KB icon of flat colour has almost nothing for the codec to exploit, so the overhead is most of the file. Below a few kilobytes, PNG or SVG usually wins — always compare rather than converting blindly.
  • What does the effort or speed setting in an AVIF encoder change?
    How much search the encoder performs before committing to an encoding. Higher effort means slower encoding and a smaller file at the same quality; lower effort is fast and fatter. It does not affect decoding at all, so for build-time or cached derivatives it is usually worth spending the CPU once to save bytes on every request.
  • Why does lossy WebP struggle with saturated red edges?
    Lossy WebP always uses 4:2:0 chroma subsampling, storing colour at half resolution in both dimensions. Brightness edges survive, but a red-on-dark boundary loses colour precision and shows fringing or bleed. If the artwork depends on saturated edges or coloured text, use lossless WebP, or AVIF with full-resolution 4:4:4 chroma.

saying these in an interview costs you the question

  • AVIF is always smaller, so use it everywhere
  • WebP is lossy only, so it cannot do transparency
  • AVIF is just WebP with a different name
  • Nothing supports AVIF yet, it is experimental
  • Fewer bytes always means a proportionally faster page

context

resolving links…