Choosing image formats: WebP vs AVIF vs PNG vs JPEG

Every image format is a set of trade-offs between compression, quality, transparency support and browser compatibility. Picking the wrong one is one of the most common, and most fixable, sources of page weight.

The short version

• **Photos and screenshots on the modern web** → AVIF, with WebP as the fallback.
• **Need broad legacy support with decent compression** → JPEG for photos, WebP where supported.
• **Need lossless quality or crisp transparency (icons, logos, UI chrome)** → PNG, or better, SVG if it's vector content.
• **Line art, illustrations, icons** → SVG first; PNG only if it must be a raster.

JPEG: the safe default

JPEG uses lossy DCT-based compression tuned for photographic content — smooth gradients and complex color transitions. It has no transparency channel, and it does not compress flat colors or sharp edges (text, icons) well, producing visible blocking artifacts. Its main strength today is universal support, decades old, decodable everywhere.

PNG: lossless, with a size cost

PNG uses lossless DEFLATE compression, so it never loses quality — a screenshot of text stays perfectly sharp. It supports full alpha transparency, which JPEG cannot do at all. The cost is size: a photographic PNG can be 5-10x larger than an equivalent JPEG for a similar visual result, because lossless compression can't discard the imperceptible detail that lossy formats throw away. Use PNG for logos, icons, diagrams and anything with flat colors or transparency, not for photos.

WebP: a genuine, well-supported upgrade

WebP supports both lossy and lossless modes, plus alpha transparency and animation (replacing GIF). In lossy mode it typically beats JPEG by 25-35% at equivalent visual quality; in lossless mode it beats PNG too, though by a smaller margin. Support is effectively universal in current browsers, which is why it has become the default recommendation for photographic web content today.

AVIF: better compression, narrower support

AVIF is based on the AV1 video codec's intra-frame compression and generally produces the smallest files of the four for a given quality level — often 20% smaller than WebP for the same photo. It supports transparency and HDR. The trade-offs: encoding is slower (matters for build pipelines, not for viewers), and while support is good in current major browsers, it is newer than WebP, so a fallback still matters for older browser versions.

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

The `<picture>` element lets the browser pick the first format it supports, so you can ship AVIF and WebP without breaking anything for older clients — the browser silently falls through to the `<img>` fallback if neither `<source>` type is supported.

SVG: not a photo format, but often the right answer

For anything that is geometry rather than pixels — logos, icons, simple illustrations, diagrams — SVG usually beats all four raster formats on both size and quality, since it scales losslessly to any resolution and is typically a few kilobytes of text. It is the wrong choice for photographs; a photo re-traced as vector paths is neither smaller nor sharper.

A practical workflow

1. Decide whether the content is a photo (raster) or geometry (vector, use SVG). 2. For photos, generate AVIF and WebP versions and serve them via `<picture>`, with a JPEG fallback. 3. Resize to the actual display size before compressing — no format choice compensates for shipping a 4000px image into an 800px slot. 4. Compress and convert locally rather than uploading originals to a third-party service, especially for anything containing sensitive content.

You can resize and convert images directly in the browser with the [image compressor](/tools/images/image-compressor) and [image resizer](/tools/images/image-resizer) — both run entirely client-side, so nothing leaves your machine.