JPG vs WebP: 25% smaller files at the same quality

WebP is a Google-developed image format introduced in 2010 and added to every major browser by 2020. At equivalent visual quality it produces files 25-35% smaller than JPG. For most web destinations there’s no remaining reason to default to JPG; the only meaningful blocker — browser support — is essentially solved as of 2026.

The headline numbers

When WebP wins

• Web destination, modern browser audience. Default to WebP. The 3% of browsers without support can fall back to JPG via the <picture> element (see below).
• Photographs with transparency.JPG can’t do alpha at all. WebP can — and at smaller sizes than PNG would.
• Mobile-first, bandwidth-conscious audiences. 25-35% smaller files mean noticeably faster page loads on metered connections.

When JPG still wins

• Email attachments. Some email clients (Outlook ancient, certain webmail variants) still mishandle WebP. JPG is universal.
• Print pipelines. Most pre-press software accepts JPG natively; WebP support is uneven.
• Embedding into legacy CMSes or document templates that you can’t test or upgrade.
• Camera output. Most cameras still write JPG by default. Convert to WebP at the publishing step, not at the capture step.

The picture-element fallback pattern

For maximum reach with WebP’s smaller files, use HTML’s<picture> element with format fallbacks. The browser picks the first <source> it supports; the <img>serves as the catch-all fallback for browsers that don’t know<picture> at all.

<picture>
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="…" />
</picture>

Modern Chrome / Safari / Firefox / Edge get WebP; the small remaining fraction get JPG. The build step needs to produce both versions but otherwise the markup is just one extra line.

Should I bother with AVIF too?

AVIF (2019) is the successor: 20-30% smaller than WebP at equivalent quality. Browser support is at ~93% in 2026 — good enough for the same fallback pattern, with three tiers:

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

AVIF’s catch is encode speed — typical encoders are 10-100× slower than WebP. For build pipelines that produce each image once (web publishing), it’s worth the wait. For on-the-fly encoding (uploads, user-generated content), WebP is the practical choice.

The pragmatic recommendation

Default to WebP for web destinations. Keep JPG fallback via<picture> for the long tail of old browsers. Add AVIF as a third tier when you have a build pipeline that can produce it cheaply. Convert your existing JPG library with our JPG to WebP converter — runs in your browser, no upload, takes seconds per file.