Which image format should you use

Compression settings get all the attention, and they are the second decision. The first is which format the picture should be in at all, and getting that wrong costs more than any quality slider can recover. A screenshot saved as JPEG is already damaged before you compress it; a photograph saved as PNG is several times larger than it needs to be and no amount of tuning will fix it.

The decision in one question

Almost every case resolves by asking what the image is made of, not what it is for.

• Continuous tone — photographs, anything with gradients and soft edges. Lossy compression works well here because the eye tolerates the errors it introduces.
• Flat colour and hard edges — screenshots, diagrams, charts, text, line art, logos. Lossy compression fails visibly here, smearing halos around every sharp boundary.
• Geometry rather than pixels — icons, logos, simple illustrations that need to scale. These should not be raster images at all.

The formats, and what each is actually for

JPEG

Lossy, universally supported, no transparency. Still the correct default for photographs when you need something that works everywhere with no fallback. It discards high-frequency detail, which is why it handles skin and sky beautifully and text badly. Every save re-compresses, so repeated editing degrades it — keep an original and export from that rather than re-saving the export.

PNG

Lossless, with real alpha transparency. The right answer for screenshots, UI mockups, diagrams and anything containing text. The distinction that matters is palette depth: a PNG limited to 256 colours is dramatically smaller than a full-colour one and, for a flat-coloured diagram, visually identical. For a photograph PNG is simply the wrong tool — expect three to five times the size of an equivalent JPEG for no visible gain.

WebP

Does both jobs — lossy for photographs, lossless for flat graphics — and supports transparency in both modes. Typically 25–35% smaller than JPEG at comparable quality, and smaller than PNG for the same lossless content. Browser support is now effectively universal. For most sites this is the sensible default, with JPEG or PNG kept only as a fallback for old software outside the browser.

AVIF

The best compression of the four, particularly noticeable at low bitrates and on large photographic images, and it handles wide colour and high dynamic range that JPEG cannot represent. The costs are real: encoding is substantially slower, and support across non-browser tooling — email clients, older operating systems, whatever your client opens attachments in — is patchier than WebP. Excellent for a website you control, risky for a file you are sending someone.

SVG

Not a compressed picture at all but a description of shapes, so it is resolution-independent and usually tiny. For logos, icons and simple illustrations it is the correct answer and nothing else comes close. It is the wrong answer for photographs, and an SVG produced by auto-tracing a photograph will be larger and worse than the original.

Formats to stop using

GIF survives out of habit. For animation it is worse than video on every axis — 256 colours, no real alpha, and file sizes many times larger than an equivalent clip. Use a muted, looping video, or animated WebP where a video element is impractical. For a static image GIF has no remaining case at all.

BMP and TIFF are not web formats and should not appear in a page. TIFF remains legitimate for print and archival masters; it just has no business being served to a browser.

Serving more than one

You do not have to choose a single format for a site. The `<picture>` element lets the browser take the first source it understands, so you can offer AVIF, then WebP, then a JPEG or PNG fallback, and every visitor gets the best format their software supports without any scripting.

The reason to do this rather than just serving one format is that the fallback costs you nothing at runtime — only build time and storage. The reason not to is that three encodes of every image is real complexity, and if your traffic is overwhelmingly modern browsers, WebP alone captures most of the benefit for a third of the work.

Whichever you pick, resize before you compress — a 4000-pixel photograph displayed 800 pixels wide is wasting most of its bytes regardless of format. That and the quality settings are covered in how to reduce image size without losing quality.

Icons and favicons are their own problem

A favicon is rendered at 16 pixels in a browser tab and at 180 or more on a phone home screen, from the same source. An SVG scales across that range perfectly but is not accepted everywhere a favicon is requested, so the durable answer is still a small set: an SVG for browsers that take one, a couple of PNGs for the larger placements, and an ICO for the oldest path. An image auto-scaled down to 16 pixels from a detailed logo turns to mud — at that size the mark usually needs simplifying rather than shrinking.