WebP vs JPG vs AVIF: which one should you actually use

Every few years a "better" image format shows up promising smaller files at the same quality, and every few years the honest answer to "should I switch" is "it depends what you're switching for." JPG, WebP and AVIF currently cover the three realistic choices for a photo you're about to put somewhere. Here's what actually separates them.

The short version

	JPG	WebP	AVIF
Typical size vs. JPG at matched quality	baseline	25–35% smaller	40–50% smaller
Transparency	no	yes	yes
Animation	no	yes	yes
Encode speed	fast	fast	slow
Browser support (2026)	universal	universal	all major browsers
Editing / native app support	universal	good, some gaps	patchy

JPG: the format everything can open

JPG has been a fixed standard since 1992, which is precisely its advantage — every browser, every operating system, every image editor, every print shop and every piece of software written in the last three decades can open it without a second thought. Its compression is genuinely dated compared to WebP or AVIF, so files run larger for the same visual quality, but "will this open" is never a question you have to ask about a JPG.

Use it when the image is going somewhere you don't control — an email attachment, a document meant to be reopened in unknown software years from now, a print vendor's upload form. Compatibility, not size, is the reason to reach for it. If what you've actually got is a WebP file and something insists on a JPG, converting is a one-step job rather than a reason to switch formats everywhere.

WebP: the practical default for the web

WebP is Google's format, and by now it's supported natively in every current browser, which removes the main historical objection to using it. At the same visual quality it typically lands 25–35% smaller than JPG, which translates directly into faster page loads — the whole reason it exists is that Google was optimising for exactly that metric.

It also supports transparency (replacing PNG for that use case) and simple animation (replacing GIF), so it's a genuine multi-purpose format rather than a JPG replacement that only handles photos. The gap that remains is native app and OS-level support outside the browser — some older image viewers, some design tools, and some print workflows still don't handle it, which is the one place JPG still wins outright.

Use WebP as the default for anything served on a website: product photos, blog images, thumbnails. If a design tool or client insists on JPG, that's still a reasonable ask — just don't assume it's ask for a technical reason.

AVIF: the smallest, at a cost

AVIF is built on the AV1 video codec and currently produces the smallest files of the three — commonly 40–50% smaller than JPG at matched quality, sometimes more on photographic content. All major browsers can now display it.

The catch is everywhere else in the pipeline. Encoding AVIF is meaningfully slower than JPG or WebP, which matters if you're generating images at scale rather than converting a handful by hand. Native support outside the browser — image editors, operating system thumbnails, older phones — remains inconsistent in a way WebP has mostly moved past. And because AV1 encoding options are still being refined across tools, quality can vary more between two "AVIF at 80%" files from different encoders than the same claim would for JPG or WebP.

Use AVIF where file size is the dominant cost and you control both ends of the pipeline — a hero image on a performance-sensitive landing page, an image CDN that serves AVIF only to browsers that report support for it. It's not yet the safe universal default WebP has become.

Why re-compressing a lossy file compounds the damage

All three of these formats — JPG, WebP and AVIF's lossy mode — throw away information to save space. That's the entire mechanism: the encoder decides which detail your eye is least likely to miss and discards it. The first pass does this against the original, uncompressed pixel data, so it can be selective and the loss is genuinely hard to see.

The second pass is a different situation. If you take an already-compressed JPG and compress it again, the encoder is now working from an image that's already missing information and already carries compression artefacts — blocky edges, colour banding — introduced by the first pass. It can't distinguish "detail the original scene had" from "noise the last encoder left behind," so some of what gets discarded this time is artefact, not padding. Do this enough times and the artefacts compound visibly, which is the recognisable "photo that's been through five group chats" look.

The fix is simple in practice: always compress from the original source file, never from an already-compressed copy. If you need both a resized version and a smaller file size, resize first, then compress once — not compress, then compress again after resizing, and not resize an already-heavily-compressed file.

Quick answers

Is WebP always better than JPG? For file size and browser display, yes. For guaranteed compatibility with software you don't control, no — JPG still wins there.

Should I switch everything to AVIF? Only if you control the whole pipeline and file size is the priority. For general use, WebP is currently the safer default.

Does converting between these formats lose quality? Converting from a lossy format to another lossy format always costs some quality, because you're decoding an already-imperfect image and re-encoding it. Keep an original master file in a lossless or high-quality format and generate web-ready copies from that, rather than converting a copy of a copy.

Which format should I use for a logo or icon with flat colour and transparency? PNG or WebP — both handle transparency and flat colour without JPG's compression artefacts around sharp edges.