WebP, JPEG or PNG: which should you actually use?

The short version: use WebP for almost everything, SVG for anything drawn rather than photographed, and keep JPEG only as a fallback. PNG has a narrower role than most people give it.

But format choice is not where most sites lose their bandwidth. That comes later in this article, and it is worth skipping ahead for if you only read one section.

The formats, quickly

Why WebP is the default now

WebP is typically 25% to 35% smaller than JPEG at visually equivalent quality, and roughly 26% smaller than PNG for lossless images. It supports transparency, which JPEG does not, and animation, which PNG effectively does not.

The historical objection was browser support. That objection has expired, every current browser supports WebP, and has for years. If you are still serving JPEG as your primary format out of caution, you are paying a real bandwidth premium for a compatibility problem that no longer exists.

AVIF compresses better still, often another 20% below WebP. Its trade-offs are slower encoding and slightly less universal support. For a photo-heavy site where you encode once and serve many times, AVIF is worth the encode time. For everything else, WebP is the pragmatic choice.

Where PNG still wins

PNG is lossless, and that matters for a specific category of image: anything with sharp edges and flat colour. Screenshots containing text, UI mockups, logos, diagrams, pixel art.

JPEG's compression works by discarding high-frequency detail in 8×8 pixel blocks. That is imperceptible on a photograph of a face and catastrophic on a screenshot of code, you get visible ringing artefacts around every letter. The text turns fuzzy in a way that looks cheap and is genuinely harder to read.

But note that lossless WebP also handles this case, and produces smaller files than PNG. The real rule is not "use PNG for graphics" but "use lossless compression for graphics", and WebP does lossless better than PNG does.

SVG is not really in the same competition

SVG is a vector format, it stores shapes and coordinates rather than pixels. That makes it infinitely scalable and usually tiny for anything geometric. A logo that is 40KB as a PNG might be 2KB as an SVG, and it stays perfectly sharp on any display at any size.

It also has properties no raster format has: you can style it with CSS, animate individual paths, and make it respond to dark mode from inside the file itself. For logos, icons and diagrams, SVG is not a compromise, it is straightforwardly better.

It is useless for photographs, which is the only real limit.

The mistake that costs more than format choice

Here is the section worth skipping ahead for. Most oversized images on the web are oversized because of their dimensions, not their format.

File size scales with pixel count. Halving an image's width quarters its pixels and typically cuts the file to around a quarter of its original size. A 4000-pixel-wide photo displayed in an 800-pixel column is carrying twenty-five times more data than the screen can possibly use.

Switching that image from JPEG to WebP might save 30%. Resizing it to the width it is actually displayed at saves 96%. The two are not close, and the resize costs no quality whatsoever because the extra pixels were never visible.

1. Find the largest size the image is ever displayed at.
2. Double it, for high-density displays.
3. Resize to that. Everything above it is waste.
4. Then worry about format and quality settings.

What quality setting should I use?

JPEG and WebP quality settings are not percentages of anything meaningful. They index into quantisation tables, and the relationship to file size is steeply non-linear.

Dropping from quality 100 to 85 often halves the file with no perceptible difference. Dropping from 50 to 35 saves comparatively little and looks noticeably worse. The useful range is narrow: 75 to 85 for photographs is where nearly everyone lands after experimenting.

One rule that is absolute: never re-compress a lossy image repeatedly. Each pass discards more information permanently. Always re-encode from the original, never from a previously compressed copy. And converting a JPEG to PNG does not restore anything, you get a larger file containing exactly the same artefacts.

Serving more than one format

If you want the smallest possible files without abandoning older clients, the <picture> element lets the browser choose:

The browser walks the sources in order and takes the first format it understands, falling back to the plain <img> if it recognises none of them. AVIF first, then WebP, then JPEG.

This is genuinely worth doing for a photo-heavy site. For a small site with a handful of images, serving WebP alone is simpler and the difference is not worth the build complexity.

A decision tree

• Is it a logo, icon or diagram? → SVG.
• Is it a screenshot or has sharp text? → Lossless WebP, or PNG as fallback.
• Is it a photograph? → WebP at quality 80, or AVIF if you can encode it.
• Does it need transparency? → WebP or PNG. Never JPEG.
• Is it animated? → WebP, or ideally a real video file, which is smaller still.

And whatever you choose, check the dimensions first. That is where the bytes actually are.