JPEG, PNG or WebP? Picking a format without overthinking it
8 Oct 2026 · Images · 7 min read
Nearly every image job on the web comes down to three formats. Here's the whole decision:
- It's a photo (or anything with smooth gradients and lots of detail)? Use JPEG. Lossy compression was designed for exactly this, and at quality 75–85 nobody can tell the difference.
- It needs transparency, or it's a logo/icon/screenshot with flat colours and sharp edges? Use PNG. Lossless, crisp edges, transparency included.
- You want the best of both and your audience uses modern browsers? Use WebP. It does lossy like JPEG and lossless-with-transparency like PNG, usually in fewer bytes than either.
That's genuinely most of it. Now the two traps.
Trap 1: Re-compressing a JPEG makes it bigger
A JPEG has already thrown away the detail it was going to throw away. Running it through the compressor again at high quality mostly spends bytes describing the artefacts the first pass left behind — so the file can come out larger than it went in. Always compress from the least-compressed source you have, and compress once, at the end.
Trap 2: JPEG eats transparency
JPEG has no alpha channel, full stop. Convert a transparent PNG to JPEG and the transparent areas get flattened onto a background colour (usually white). If the image needs its transparency, JPEG was the wrong target — pick PNG or WebP instead.
A practical workflow
For a photo headed to a web page: resize it to the display width first, then compress at the finished size. A quality setting means what you think it means only when the pixel dimensions are already final — compressing a 4000-pixel photo to "look small" and then resizing throws away the size win you just paid for in quality.
How each format actually stores the picture
The differences between formats aren't arbitrary — each one bets on a different trick for shrinking pixels, and the trick decides what it does well and what it mangles.
JPEG bets that your eyes are bad at fine detail. It divides the image into 8×8 blocks, converts each block into a set of wave patterns (a discrete cosine transform, if you want the term), and then discards the high-frequency waves — the subtle texture your vision barely registers. What's left gets stored compactly. This is why JPEG is brilliant for photos, which are full of smooth gradients, and terrible for sharp text edges, where discarding "fine detail" visibly smudges the letters and leaves blocky artefacts.
PNG makes the opposite bet: it stores every pixel exactly, then squeezes the data with a general-purpose compressor (DEFLATE, the same family as zip files). Flat areas of solid colour compress beautifully; noisy photographs barely compress at all. Nothing is ever lost — open, save, repeat a hundred times and the pixels are identical — which is why PNG is the format for logos, diagrams, screenshots, and anything with transparency.
GIF is the oldest of the bunch and survives on two features: it stores at most 256 colours (chosen per image from a palette), and it can animate. The colour limit makes it a poor choice for photographs — smooth skies turn into visible bands — but perfect for simple graphics, memes, and the looping animations the web never quite gave up on.
WebP is Google's attempt at one format for both jobs. Its lossy mode borrows techniques from video compression (predicting each block from its neighbours instead of storing it outright), typically producing files 25–35% smaller than an equivalent JPEG. Its lossless mode with transparency does the same job as PNG in fewer bytes. For most web images in 2026, it's simply the best technical choice — the only question is whether your audience's browsers support it, and these days virtually all of them do.
AVIF goes one generation further, built on the AV1 video codec. It can beat WebP's file sizes by another noticeable margin, especially for photographs, and it handles HDR and wide colour gamuts that the older formats can't express. The catch: encoding is slow, decoding costs more CPU on older devices, and tooling support is still catching up. It's the future; WebP is the present.
The formats at a glance
| Format | Best for | Transparency | Animation | Sharp edges | Typical size vs JPEG |
|---|---|---|---|---|---|
| JPEG | Photographs, gradients | No | No | Poor (artefacts) | Baseline |
| PNG | Logos, screenshots, diagrams | Yes (full alpha) | No | Perfect (lossless) | 2–5× for photos |
| GIF | Simple animation | Yes (1-bit) | Yes | Good (within 256 colours) | Often larger |
| WebP | Nearly everything on the web | Yes (full alpha) | Yes | Good to excellent | ~25–35% smaller |
| AVIF | Photos where size matters most | Yes | Yes | Excellent | ~40–50% smaller |
Quality settings, decoded
That quality slider — usually 0 to 100 — is a dial for how aggressively the lossy formats throw detail away. Higher isn't linearly better: the jump from 60 to 80 buys a lot of visible quality for a modest size increase, while the jump from 90 to 100 roughly doubles the file for differences you'd need a magnifier to spot.
To make it concrete, take a typical 1600×1200 photograph (about 2 megapixels) and save it as JPEG at three settings:
- Quality 95: roughly 600–700 KB. Visually near-perfect, but you're paying full price for bytes nobody can see.
- Quality 80: roughly 220–280 KB. The web sweet spot — indistinguishable from the original at normal viewing sizes, at a third of the weight.
- Quality 60: roughly 120–160 KB. Noticeably smaller, but look closely at smooth gradients and you'll find banding; edges around high-contrast areas start to shimmer.
The same photo in lossless PNG would be 2–3 MB, and in WebP at quality 80 it'd land around 150–190 KB. The lesson: for web photos, quality 75–85 on a modern format is where the size–quality curve flattens, and pushing past it costs more than it gains. (Your exact numbers will differ per image — busy photos with lots of texture compress worse than simple ones — but the shape of the curve is always the same.)
When to convert — and when to leave it alone
Converting is worthwhile when it moves an image toward the right tool for its job: a PNG screenshot with photographic content becoming WebP, an animated GIF becoming WebP or AVIF animation (often half the size), a legacy JPEG being re-encoded as WebP for a modern site. In those cases the new format genuinely earns its smaller file.
Leave it alone when the conversion is sideways rather than forward. Re-saving a JPEG as a JPEG at the same quality gains nothing and loses a little (more on that below). Converting a photo to PNG "for quality" produces a file several times larger with zero additional detail — the detail was already gone, and PNG's job is preserving pixels, not restoring them. And keep your originals: whatever you serve on the site, archive the highest-quality source you have. Future you, with better formats and faster connections, will want it.
One more practical rule: convert from the original, not from a copy that's already been through the wringer. Every lossy save is a one-way trip, and converting from an already-degraded JPEG bakes the artefacts into the new file permanently.
The caveat: conversion can't recover what's gone
This is the misunderstanding behind half of all format questions: lossy compression is irreversible. Once JPEG has discarded the high-frequency detail at quality 60, no converter, upscaler, or "enhance" button can put the true pixels back — the information simply isn't in the file. Saving that damaged JPEG as a PNG produces a bigger file containing the exact same damage. Upscaling a small image to larger dimensions invents plausible pixels; it never recovers the originals.
So treat your format decisions as a pipeline that only ever flows toward smaller: start from the best source, resize once, compress once, and serve the result. Anything that needs to go the other direction — a bigger version, a cleaner version — goes back to the original file. There is no shortcut around it, only workflows that respect it.