WebP vs AVIF vs PNG vs JPEG: which image format should you use?
Use WebP for almost everything on the web — it is around 30% smaller than JPEG at matching quality and every current browser supports it. Use AVIF on large hero images, where it saves roughly 20–30% again over WebP. Keep PNG for anything that must be pixel-exact, and keep JPEG for photography going somewhere you do not control. Format arguments consume more engineering time than they are worth, because the answer is usually the same and the exceptions are easy to identify. Does the image need transparency? Does it need to be pixel-exact? Answer those two and the format picks itself.
The formats at a glance
Size figures are typical savings at visually matched quality on photographic content, measured against a baseline JPEG. Your mileage varies with the image — flat illustration compresses very differently from a noisy photo.
| Format | Compression | Alpha | Animation | Typical size | Support (2026) |
|---|---|---|---|---|---|
| WebP | Lossy + lossless | Yes | Yes | ~30% under JPEG | Universal |
| AVIF | Lossy + lossless | Yes | Yes | ~50% under JPEG | All current browsers |
| PNG | Lossless only | Yes | No | Baseline (large) | Universal |
| JPEG | Lossy only | No | No | Baseline | Universal |
| GIF | Lossless, 256 colours | 1-bit | Yes | Worse than all | Universal |
| SVG | Not applicable — vector | Yes | Yes | Often < 1 KB | Universal |
the short version
Is it a photograph or illustration for the web?
WebPIs it a very large hero and every kilobyte counts?
AVIF, with a WebP fallbackMust it be pixel-exact, or is it a screenshot or diagram?
PNGIs it going somewhere old that you do not control?
JPEGIs it an icon, logo or simple shape?
SVG — generate it as vector, do not convertHow much smaller, actually?
Most format arguments are conducted without numbers. These are the ones worth knowing, and they are consistent enough across studies to plan around.
~30%
WebP under JPEG
Google measured lossy WebP at 25–34% smaller than JPEG at equivalent quality. In practice a quality-80 WebP is about a third lighter than the JPEG you were shipping.
~26%
Lossless WebP under PNG
Same pixels, quarter off. If you are shipping PNG screenshots, this is free — no visual decision to make, nothing to compare side by side.
~50%
AVIF under JPEG
Roughly half the bytes for the same perceived quality, and about 20–30% under WebP. The advantage grows with image size, which is why it belongs on heroes.
The number nobody quotes: encode time
AVIF encodes far slower than WebP — often by an order of magnitude at comparable effort settings. On a build step that is an annoyance; on an upload path that users wait for, it is a product decision. This is the real reason AVIF is not simply the answer to everything, and it is why the sensible pattern is WebP everywhere plus AVIF on the few images where the saving is measured in hundreds of kilobytes rather than tens.
What each one is actually for
WebP
the default- Compression
- Both
- Alpha
- Yes
- Animation
- Yes
Good for: Photographs, illustration, cutouts, almost everything on a web page.
Watch out: Nothing much. It is the safe choice.
AVIF
smallest files- Compression
- Both
- Alpha
- Yes
- Animation
- Yes
Good for: Large heroes and full-bleed imagery where every kilobyte is felt.
Watch out: Slow to encode — often 10× a WebP. Worth a fallback for maximum reach.
PNG
lossless- Compression
- Lossless
- Alpha
- Yes
- Animation
- No
Good for: Screenshots, UI assets, diagrams, cutouts you will edit again.
Watch out: Large for photographs. Do not ship a PNG photo.
JPEG
maximum reach- Compression
- Lossy
- Alpha
- No
- Animation
- No
Good for: Photography going into systems you do not control.
Watch out: No transparency at all. Flattens alpha onto solid colour.
GIF
legacy- Compression
- Lossless, 256 colours
- Alpha
- 1-bit
- Animation
- Yes
Good for: Places that still accept nothing else.
Watch out: Huge, colour-limited, jagged edges. WebP does this better.
TIFF
archival- Compression
- Usually lossless
- Alpha
- Yes
- Animation
- No
Good for: Print hand-offs and archival masters.
Watch out: Never serve it to a browser.
SVG is not on the same list
The five formats above are all raster: a grid of coloured pixels, differing only in how cleverly they are compressed. SVG is a different kind of thing entirely — a description of shapes, drawn fresh at whatever size it is rendered.
That is why an SVG is infinitely scalable, recolourable from CSS and often measured in hundreds of bytes. It is also why you cannot convert a photograph into one: there are no shapes in a photograph to recover. Tracing produces thousands of junk polygons that are bigger than the original and impossible to edit.
If you need vector artwork, generate it as vector from a description rather than converting pixels you already have.
Generate real SVG · 5 creditsRaster
Stores what each pixel looks like. Enlarging means inventing pixels that were never recorded.
Vector
Stores what shapes exist. Enlarging means drawing the same shapes bigger — nothing is invented and nothing is lost.
Shipping two formats: the fallback markup
You do not have to choose one format for everyone. <picture> lets the browser take the first source it understands, so modern clients get AVIF and everything else falls back on its own.
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" alt="…" width="1600" height="900" />
</picture>Order matters.
The browser takes the first source it can decode, so the smallest format goes first and the safest last.
The <img> is not optional.
It is the fallback and it carries the alt text, width and height. Omit the dimensions and you have bought yourself a layout shift.
Do not do this for every image.
Three encodes of every asset is a real build and storage cost. Reserve it for heroes and above-the-fold imagery; ship plain WebP everywhere else.
Choosing by image type
The table answers “what is this format good at”. This answers the question you actually have, which is “what do I save this as”.
Photographs
WebP at quality 80, or AVIF for anything running full-bleed. Neither needs to be lossless — nobody has ever noticed.
Screenshots and UI
PNG, or lossless WebP if you want the same pixels ~26% smaller. Lossy compression turns crisp text into mush.
Logos and icons
SVG, generated as vector rather than traced from a PNG. Falls back to transparent PNG only where SVG is not accepted.
See the workflow →
Product cutouts
Transparent PNG while you are still editing, WebP with alpha once it ships. JPEG is disqualified — no alpha channel.
See the workflow →
Open Graph previews
JPEG or PNG at 1200×630. Some social scrapers still handle WebP and AVIF poorly, so this is the one place to stay conservative.
See the workflow →
Diagrams and charts
SVG if it is authored, PNG if it is rendered. Never JPEG — its artefacts cluster exactly on the hard edges a diagram is made of.
See the workflow →
Turning the decision into a call
Once you know the target, two endpoints get you there — and they answer different questions.
compress_image“It is too big”
Quality percentage plus a target of WebP, JPEG or PNG. The lever you pull when the file is the problem. 1 credit.
convert_format“It is the wrong container”
Straight between PNG, JPG, WebP, GIF, TIFF and AVIF, no quality dial. 1 credit.
Both are exposed as MCP tools as well as REST endpoints, so an agent that has just generated an image can convert and compress it before writing it into the repo — no separate build step and no human deciding the format one file at a time. See how that pipeline is wired.
Image format questions, answered
Which is better, WebP or AVIF?
AVIF makes smaller files — commonly 20–30% smaller than WebP at matched quality, and the gap widens on large, detailed photographs. WebP is better at everything else: it encodes in a fraction of the time, it is supported everywhere without qualification, and it is far more predictable at small sizes. Use WebP as the default and reach for AVIF on the handful of images big enough that 20–30% is a real number of kilobytes.
Is WebP better quality than PNG?
Not better — different. Lossless WebP is pixel-identical to PNG and Google measured it at roughly 26% smaller, so for a screenshot or a diagram it is a straight win. Lossy WebP throws information away, which PNG never does, but at high quality settings the difference is invisible on photographs while the file is a fraction of the size. PNG only wins when the image must survive repeated re-editing.
Is AVIF higher quality than JPEG?
At the same file size, yes, clearly. AVIF typically reaches JPEG quality at around half the bytes, and it keeps gradients and flat areas clean where JPEG produces blocking and banding. It also supports transparency and wider colour, neither of which JPEG has. The trade-offs are encode time and the need for a fallback on older browsers.
What should I use for most images on a website?
WebP. It handles photographs and flat illustration well, carries an alpha channel, supports animation, and every current browser has supported it for years. It is the default for a reason and the right answer unless you have a specific reason to deviate.
What about JPEG XL?
Technically excellent and not yet a web format. Safari added support, Chrome removed it, and until that changes shipping JPEG XL to browsers means shipping a fallback for most of your traffic. It is worth watching, not worth deploying. AVIF is the format that actually reaches people today.
When should I still use PNG?
When the image must be pixel-exact or has hard edges and flat colour: screenshots, UI assets, diagrams, and cutouts you will edit again later. PNG is lossless, which is both why it looks perfect and why it is large.
Is JPEG obsolete?
Not obsolete, just narrower. It remains the safest format for photography going into systems you do not control — legacy CMSs, partner feeds, print workflows, and Open Graph previews where some scrapers still lag. Its one hard limitation is that it has no alpha channel at all.
Why can I not convert a photo to SVG?
SVG stores shapes, not pixels. A photograph has no shapes to recover, so tracing one produces thousands of meaningless polygons that are larger than the original and impossible to edit. If you need vector artwork, generate it as vector from a description.