JPEG, PNG, WebP or AVIF: Which Format, and Why

Two questions, and the format falls out of them

Question one: is the image photographic or flat-toned? Photographic means continuous tone — skin, sky, foliage, sensor noise, no region where the value jumps from one pixel to the next. Flat-toned means the opposite: screenshots, logos, charts, diagrams, line art, text, anything with large uniform areas and hard edges between them. This is not a stylistic label. It is a statistical description of the pixel data, and the two families of compression were built for opposite statistics.

Question two: does the image need an alpha channel or animation? JPEG has neither and never will. PNG has alpha and can animate only through APNG, an extension the specification did not originally include. WebP and AVIF both have alpha and both animate. If you need a logo to sit over an unknown background, JPEG is out before the size discussion begins — a JPEG logo comes with a rectangle of background baked in.

What DCT and DEFLATE actually do to the pixels

JPEG chops the image into 8×8 blocks and rewrites each block as a sum of cosine waves, then divides those wave coefficients by a quantisation table and rounds. Fine detail lives in the high-frequency coefficients, and those are the ones the table divides hardest, so they round to zero and are gone. A photograph tolerates this because its high frequencies are largely noise. A hard edge does not: an abrupt step needs many high-frequency terms to reproduce, and when you delete them the reconstruction overshoots and undershoots either side of the edge. That is ringing, and it is why text in a JPEG looks fuzzy at the edges even at high quality.

The effect is measurable, and it is strictly local to edges. In our flat test image we took a band 1040 pixels wide by 70 tall around the headline. In the master, 56,119 pixels in that band are exactly 255,255,255. After a single JPEG pass at quality 75, 6,352 of them — 11.3% — are no longer pure white, deviating by up to 14 levels. In an empty white band of 86,400 pixels well away from any edge, not one pixel changed. JPEG does not degrade the image evenly; it degrades it precisely where flat-toned artwork lives.

PNG works the other way round. It predicts each pixel from its neighbours, subtracts the prediction, and hands the residuals to DEFLATE — the same algorithm as a zip file. A run of identical pixels compresses to almost nothing, which is why a screenshot shrinks so well. A photograph has no runs: every pixel differs slightly from its neighbour, the residuals are noise, and DEFLATE has nothing to grip. That is the whole explanation for the 2,021,576 bytes our photograph needed as PNG against 311,380 as JPEG.

The same two images, four encoders, measured

On the photograph the ranking is the one everybody expects. PNG 2,021,576 bytes, JPEG at quality 75 311,380, AVIF at the encoder's quality 75 174,774, lossy WebP at quality 75 105,608. But read that last pair carefully before drawing a conclusion: quality 75 in one codec is not quality 75 in another. The number is an index into that encoder's own quantiser, nothing more. All those figures tell you is that these two encoders, at their nominally identical settings, landed on different points of the size-versus-quality curve — not that WebP beats AVIF. Any honest comparison of two codecs fixes a quality metric first and then compares bytes, and that is a different, much longer exercise than the one on this page.

The flat screenshot is where the interesting reversal happens. PNG 88,693 bytes. JPEG at the same quality 75 setting: 152,065 bytes — 1.71 times the PNG, while also throwing pixels away. Lossy WebP: 40,060 bytes. Lossless WebP: 36,074 bytes, which is both smaller than the lossy version and pixel-exact. That is not an anomaly. Lossy WebP always subsamples chroma to 4:2:0, so coloured text and thin coloured rules get half the horizontal and vertical colour resolution, and the encoder then spends bits trying to reconstruct edges it has already blurred. On flat-toned artwork, lossless is frequently both smaller and better.

The one-way door — and the myth about re-saving

The loss is genuinely one-way. We converted our PNG master to JPEG at quality 75 and back to PNG: the returned PNG is 1,470,130 bytes, against 2,021,576 for the original. It is smaller because the JPEG pass smoothed detail out of the image, and no PNG encoder can put that detail back. The file is lossless from that moment on, but it is losslessly storing a damaged picture. PNG → JPEG → PNG never returns the original, and the smaller file size is the evidence, not a bonus.

The popular version of this — that every single re-save compounds the damage — turns out to be false as usually stated, and we measured it. Re-encoding the same JPEG ten times at the identical quality setting, with no crop, no resize and no edit in between, moved the mean absolute pixel error from 1.7591 to 1.7670 levels. That is a drift of eight thousandths of a level over ten generations: JPEG re-quantisation is close to a fixed point when the 8×8 grid stays aligned and the quantisation table does not change.

Change anything between saves and the compounding is immediate. We repeated the chain with a small centre crop before each save, which shifts the image relative to the 8×8 grid. After six such cycles the mean absolute error against a single-pass encode of the identical crop had risen from 1.76 to 2.32 levels — 32% more error — while encoding that same crop once from the untouched master stayed flat at about 1.77 regardless of which cycle we compared. The practical rule is therefore not "never re-save": it is keep the lossless master, edit from it every time, and export JPEG or WebP as the last step rather than as the working file.

Alpha, bit depth and the ceilings nobody mentions

PNG stores up to 16 bits per channel; JPEG as browsers implement it is 8. WebP is 8-bit in both modes, and its lossy mode is always 4:2:0. AVIF reaches 10 and 12 bits and can encode 4:4:4, which is why AVIF is the one of the four that handles a wide smooth gradient without banding, and the only one with a real answer for HDR imagery. If your image is a sunset sky or a soft product backdrop, that bit depth is worth more than any byte count in the table above.

WebP carries a hard ceiling that surprises people the first time they hit it: the container encodes width and height in 14 bits, so no WebP can exceed 16,383 pixels on either side. That is irrelevant for a web photograph and fatal for a scanned map or a long stitched panorama. AVIF and PNG have no comparable limit at any size you are likely to produce. It is worth knowing before you build a pipeline that converts everything to WebP by default.

Support and encode cost, and the rule that falls out

Support is no longer the deciding factor it was five years ago. WebP shipped in Chrome long ago, in Firefox 65 in January 2019, and in Safari 14 in September 2020. AVIF shipped in Chrome 85 in August 2020, Firefox 93 in October 2021, Safari 16 in September 2022, and finally Edge 121 in January 2024 — Edge was the last major browser to arrive. Every current version of every major browser decodes both. What remains is a long tail of old operating systems that cannot update their browser, which is exactly what the picture element with source and a JPEG fallback exists to serve.

Encode cost is the live constraint instead. On the same machine and the same 1600×900 photograph, best of five runs: WebP 287 ms, AVIF 1,163 ms, JPEG 119 ms. AVIF took four times as long as WebP, and against JPEG produced by the same tool it took nearly ten times as long. Different encoders were involved — cwebp for WebP, the system image framework for AVIF and JPEG — so treat the exact ratio as indicative rather than universal. The direction, though, is not in doubt: AVIF is AV1 intra coding, it searches a much larger space, and it is slow by construction. On a batch of a hundred thousand images that is a real budget line, and it is the reason plenty of teams settle on WebP.

The rule that falls out of all this fits in three lines. Photograph, no transparency needed: WebP or AVIF, with JPEG behind them for old clients. Screenshot, logo, chart, anything flat-toned: lossless WebP first, PNG as the safe fallback, and never JPEG. Anything that needs alpha or animation: WebP or AVIF, or PNG if the palette is small and lossless matters more than bytes.

Frequently asked questions

Is WebP always smaller than JPEG?

No. It usually is on photographs, and on ours it was 66% smaller at nominally the same quality setting — but those settings are not comparable across codecs, and a JPEG that has already been heavily compressed can grow when re-encoded to WebP, because the encoder now has to reproduce JPEG's block artefacts as if they were image detail. Always measure on your own images rather than trusting a headline percentage.

Does converting an old JPEG to WebP or AVIF restore quality?

It cannot. The detail JPEG discarded is not in the file, so nothing downstream can recover it. Converting is still worth doing to save bandwidth, and a good encoder will not add much new damage, but the ceiling is set by the JPEG you started from. If the original raw or PNG still exists, re-export from that instead — it costs nothing extra and the result is genuinely better.

Should I still publish JPEG at all?

As a fallback inside a picture element, yes — it costs one extra file and covers every device ever built. As the primary format for new work, there is now no photographic case where JPEG wins on size at equal quality, and no flat-toned case where it wins at all. It also remains the safest thing to hand someone who will open it in unknown software, which is why email attachments and printer drop-offs still default to it.

PNG-8 or PNG-24 for a logo?

PNG-8 stores an indexed palette of at most 256 colours and is dramatically smaller when the artwork genuinely has few colours — most flat logos do. PNG-24 stores full colour and is needed only for gradients or soft shadows. Check the result rather than the label: if the palette version is visually identical, keep it. And compare both against lossless WebP, which beat PNG by 59% on our flat test image.

Is AVIF worth the extra encode time?

It depends entirely on how many times each file is encoded versus served. A hero image encoded once and delivered a million times: encode it as AVIF and take the extra second. User-uploaded content encoded on the fly at request time: four times the CPU per image is a serious operating cost, and WebP is the pragmatic choice. AVIF also earns its keep on wide smooth gradients, where its 10 and 12-bit modes avoid banding that 8-bit formats cannot.

Why did lossless WebP beat lossy WebP on the screenshot?

Because lossy coding is the wrong tool for that data. The screenshot is mostly long runs of identical pixels, which the lossless mode encodes almost for free, while the lossy mode first subsamples the colour, then spends bits describing the edges it blurred. We measured 36,074 bytes lossless against 40,060 lossy — smaller and pixel-exact. If your image is flat-toned, try lossless before you reach for a quality slider.