JPG vs WebP

Both are lossy formats for photographs, and they work the same way in outline: discard detail the eye is unlikely to miss, describe what is left compactly. JPEG was standardised in 1992 and WebP in 2010, and the eighteen years between them are most of the difference.

WebP’s compression comes from video coding — it is a still frame of the VP8 codec — and it brings techniques JPEG predates: better prediction from surrounding blocks, a smarter transform, and an entropy coder that squeezes more out of what remains. At comparable visual quality the file is typically twenty-five to thirty-five per cent smaller.

On a page with one photograph, nothing you would notice. On an e-commerce category page with forty product images, a third off the largest thing on the page is the difference between a site that feels immediate and one that does not — and it is measured directly by the metric search engines use for page experience.

It also compounds on mobile connections, where the bytes arrive slowly and the visitor is most likely to leave. If images are the bulk of a page’s weight, and on most pages they are, converting them is the single highest-return performance change available.

Transparency, with a real alpha channel — so a product photograph cut out from its background can be a WebP where it previously had to be a PNG at several times the size. That is a bigger practical win than the compression on many sites.

And a lossless mode, which JPEG has no useful equivalent of. So one format covers photographs, cut-outs and interface graphics, where a site previously needed JPG for one and PNG for the others. Fewer formats in a build pipeline is worth something on its own.

Everywhere that is not a browser. Every camera writes JPEG, every phone gallery opens it, every printing service takes it, every upload form accepts it, every email client shows it, and every piece of software written in the last thirty years reads it. Nothing else in imaging is that universal.

So the rule is about destination, not quality. A photograph going onto a web page: WebP. A photograph being emailed, printed, uploaded to somebody else’s system, or handed to a person: JPG. Sending a WebP to a client and being asked what the file is is a conversation nobody needs.

This is the mistake worth naming. Converting an existing JPG to WebP re-encodes an image that has already been compressed lossily. The artefacts from the first pass are treated as detail and preserved faithfully, and new ones are added on top.

The saving is real and the quality is a generation down from what it should be. Where possible, generate the WebP from the original — the camera file, the master, the export from the design tool. Where that is impossible, converting is still usually worth doing at a high quality setting, and it should be a considered decision rather than an automatic one.

A picture element takes several sources and the browser picks the first it understands. Put the WebP first and the JPG second and every visitor gets the best file their browser can read, with no detection and nothing to maintain.

Most content management systems and image services now do this automatically — they store one original and deliver whichever format the requesting browser advertises. If your platform offers that, it is the whole job, and hand-converting an image library is unnecessary work.

AVIF is smaller again on photographs, often by another twenty to thirty per cent against WebP, and it handles gradients and skies with less banding. It is also considerably slower to encode, which matters when a site generates images on upload.

Both are read by every current browser, so the sensible arrangement is AVIF first, WebP second, JPG as the fallback. If that is more pipeline than the site justifies, WebP with a JPG fallback captures the great majority of the benefit for a fraction of the effort.