PNG, JPEG or WebP: Which One, and Why

The choice is not really between three formats. It is between two ways of storing an image, and a third format that does both better. Once you can tell which of the two an image needs, the decision makes itself.

Lossy and lossless, which is the whole distinction

PNG is lossless. Every pixel comes back exactly as it went in, and the compression works by finding repetition — long runs of the same colour, patterns that recur. That is why a screenshot of a user interface compresses beautifully as PNG and a photograph of a beach does not.

JPEG is lossy. It throws away detail the eye is bad at noticing, particularly fine colour variation, and keeps the structure. That is a catastrophe for sharp edges and a triumph for gradual tonal change, which is precisely the difference between a logo and a landscape.

Photographs and gradients want lossy. Text, lines, flat colour and transparency want lossless. The format follows from the content, not from a preference.

Where WebP fits

WebP does both. It has a lossy mode that generally beats JPEG at the same visual quality and a lossless mode that generally beats PNG, and unlike JPEG it supports transparency. Browser support has been universal for years, which removes the only reason not to use it.

So the short answer for anything going on a web page is WebP, and the interesting part is the exceptions.

When to keep JPEG

Compatibility outside the browser. Email clients, older desktop software, some print workflows and plenty of embedded devices still expect JPEG. If the file is going somewhere you do not control, JPEG is the format that will open.

Also: do not re-encode a JPEG as WebP for a marginal saving. Every lossy re-encode discards a little more of what remains, and the artefacts of the first pass become detail the second pass faithfully preserves. Convert from the original if you have it, and leave it alone if you do not.

When to keep PNG

• Screenshots containing text, where lossy compression puts a visible halo around every letter.
• Logos, icons and line art with hard edges and flat fills.
• Anything that will be edited again later, since each lossy save compounds.
• Images where exact pixel values matter — diagrams, colour references, anything being compared.

The trap in the other direction is converting a photograph to PNG "for quality". A photograph has almost no repetition for a lossless algorithm to exploit, so the file often grows several times over while looking identical. It is a large price for a difference nobody can see.

What about AVIF?

AVIF compresses better again, particularly at low quality settings, and support is now broad. The practical obstacle is encoding: a browser can decode AVIF but cannot write it, so any tool running in a browser can offer to open one and not to produce one. Producing AVIF means a build step or a service that does it server-side.

Serving more than one format

You do not have to choose a single format for everyone. The picture element lets a browser pick the first source it understands, so a page can offer AVIF, fall back to WebP, and fall back again to JPEG for anything ancient.

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="" width="1200" height="800">
</picture>

The cost is that every image now exists three times and something has to generate all three. For a site with a handful of images that is more machinery than it earns; for an image-heavy catalogue it pays for itself immediately.