WebP vs AVIF vs JPEG vs PNG: which image format should you use?

Most advice about image formats is either a decade out of date or written by someone selling a CDN. The practical situation in 2026 is simpler than the debate suggests, and it comes down to one question: are you storing a photograph or a graphic?

Everything else follows from that, with a couple of genuine exceptions worth knowing.

The short version

Photographs — anything with continuous tone, gradients, natural detail: use WebP. Fall back to JPEG when something requires it.

Graphics — screenshots, logos, diagrams, line art, anything with flat colour and hard edges: use PNG, or WebP in lossless mode.

Anything needing transparency: PNG, WebP or AVIF. Not JPEG, which has no alpha channel at all.

When file size matters more than anything else, and you control the delivery: AVIF.

If you stop reading here you will get it right almost every time. The rest is why, and the cases where it is worth thinking harder.

What each format actually is

JPEG (1992) is the format photography settled on. It is lossy by design — it discards information the eye is least likely to miss — which is why it makes photographs small. It cannot store transparency, and it degrades a little each time it is re-saved. Its enormous advantage is that literally everything reads it.

PNG (1996) is lossless. Every pixel is preserved exactly, which makes it right for anything where precision matters: screenshots, logos, diagrams, UI assets. It supports full alpha transparency. It is a poor choice for photographs, where "preserve every pixel exactly" means "produce an enormous file".

WebP (2010) does both jobs. It has a lossy mode that competes with JPEG and a lossless mode that competes with PNG, and it supports transparency in both — which JPEG cannot do at all and which is genuinely useful. Support is universal across current browsers.

AVIF (2019) is derived from the AV1 video codec and compresses harder than anything else in common use. It supports transparency, wide colour and high dynamic range. Its costs are encoding speed and patchier tooling support outside browsers.

The size differences, concretely

Numbers vary enormously with content, so treat these as typical rather than guaranteed. For a photograph at visually equivalent quality:

For a screenshot or a flat-colour graphic, the ranking inverts almost completely:

That second table is the one that surprises people. Saving a screenshot as JPEG can produce a file that is both bigger than the PNG and visibly degraded, because JPEG's compression assumes smooth gradients and screenshots are the opposite of that.

Why JPEG is bad at screenshots

It is worth understanding the mechanism, because it explains most format mistakes.

JPEG compression exploits two facts about human vision: we notice brightness far more than colour, and we notice large shapes far more than fine detail. So it stores colour information at reduced resolution and progressively discards the finest detail within small blocks of the image.

For a photograph of a landscape this works beautifully — there is texture everywhere, and losing some of it is invisible. For a screenshot, it is exactly wrong. Text is fine detail with hard edges and sharp colour boundaries, which is precisely what the algorithm throws away first. The result is the coloured fringing you see around letters in a badly-saved screenshot, and it does not go away at higher quality settings, it just becomes subtler.

PNG has the opposite characteristics. It compresses by finding repetition, and flat areas of identical colour compress extraordinarily well. A screenshot is mostly flat colour. A photograph has almost no exact repetition, which is why PNG makes photographs enormous.

When to still use JPEG

WebP is better than JPEG on almost every technical measure, but JPEG remains the correct answer in several situations.

When something else has to read it. Older software, some print workflows, certain enterprise systems, and plenty of upload forms accept JPEG and nothing else. This is the single most common reason to choose it.

When the recipient is unknown. Sending a photo to someone whose device and software you do not know? JPEG works everywhere, with no exceptions worth worrying about.

When it is already a JPEG and you have no reason to touch it. Converting an existing JPEG to WebP re-encodes it, which means a second round of lossy compression on top of the first. The size saving is real but so is the quality cost. If the file is fine as it is, leave it.

When to still use PNG

Anything with text or sharp edges. Screenshots, diagrams, charts, UI mockups.

Anything requiring exact pixel fidelity. Assets that will be processed further, or images where a single wrong pixel matters.

When transparency is needed and compatibility is unknown. WebP transparency is universally supported in browsers, but PNG is supported everywhere including software written twenty years ago.

Icons and small assets where the file is tiny either way and the compatibility is free.

The AVIF question

AVIF genuinely produces the smallest files. Whether it is the right choice depends on your situation.

Arguments for: substantially smaller than WebP, often half of JPEG. Excellent at low bitrates where JPEG falls apart badly. Supports transparency, wide colour and HDR.

Arguments against: encoding is slow — noticeably so for large images, and enough to matter if you are processing thousands. Support outside browsers is still incomplete: plenty of desktop software, image editors and upload forms do not accept it. Notably, browsers that can display AVIF cannot always encode it, which is why some tools offer it for input but not output.

The practical rule: use AVIF when you control delivery — your own website, where you can serve it with a fallback — and stick to WebP when the file might end up anywhere else.

The decision rule

Ask two questions.

Is it a photograph? If yes: WebP for the web, JPEG if compatibility is uncertain, AVIF if you control delivery and want the smallest possible file. If no — it is a screenshot, logo, diagram or anything with flat colour and hard edges — PNG, or lossless WebP if you want it smaller.

Does it need transparency? If yes, JPEG is out. Everything else supports it.

That is the whole decision for the overwhelming majority of images.

Two things that matter more than format

Before optimising format, check these, because both usually save more.

Resize first. A 4000-pixel-wide photograph displayed in an 800-pixel column is wasting roughly 96% of its pixels, and no format choice recovers that. Resizing to the size actually displayed is by far the largest single saving available, and it costs no visible quality at all. Only then is format worth thinking about.

Do not re-compress repeatedly. Every lossy save discards more detail, and the damage accumulates — artefacts from the first pass get treated as real detail by the second. Always work from the highest-quality original you have rather than from a file you already compressed.

Get those two right and the format decision is a refinement rather than a rescue.

A note on quality settings

"Quality 80" does not mean the same thing across formats. The number is a codec-specific parameter, not a standard measure, so WebP at 80 and JPEG at 80 produce different results — usually with WebP looking better at the same nominal setting.

Judge by looking, not by the number. For photographs, somewhere around 75–85 is typically indistinguishable from the original at normal viewing size. Images with large smooth areas — skies, studio backdrops, gradients — need higher settings than busy detailed ones, because banding shows up in smooth areas long before it shows anywhere else.

The image converter here handles all four formats and disables any your browser cannot genuinely encode, rather than silently substituting one. The compressor can also target a specific file size, which is the practical need when an upload form imposes a limit.