JPEG, PNG, WebP or AVIF: choosing an image format you will not regret

Every picture you put on a page asks the same question, and most people answer it out of habit: save it as whatever the last project used. A format is a promise about what the picture is made of, and when the promise does not match the contents you pay for it twice — once in bytes, once in how the thing looks when it finally arrives.

The order of the questions matters more than the answers. Is this continuous tone, or hard edges and flat fills? Does anything need to see through it? The first question removes half the options before you have opened a menu, and the second removes one format permanently.

A photograph and a diagram compress differently

A photograph is a few million pixels whose neighbours are nearly the same colour as each other. A screenshot of a settings panel is a few thousand pixels of flat fill with sharp black glyphs on top of them. Compression gets all of its wins from the first property and nothing but trouble from the second.

JPEG works in 8×8 blocks. Each block is transformed from a grid of pixel values into a grid of frequencies, and the high-frequency coefficients — the ones describing fine detail — are divided by a large number and rounded towards zero. That rounding is the compression, and it is tolerable because the eye is much less sensitive to fine luminance detail than the raw numbers suggest.

Text is where "before anyone notices" stops being true. The strokes of a letter are exactly the hard, high-frequency detail the encoder is rounding away, so a JPEG screenshot comes back with soft edges and a faint ripple around every glyph. Ringing is the name for it: a hard edge cannot be ended cleanly at a block boundary, so the error leaks into the pixels either side. A diagram of flat fills gives the encoder nothing worth discarding, which leaves it spending its effort on the outlines — the one part of a diagram you can see.

What a screenshot weighs

Take a 1600 × 1000 screenshot of an app window. That is 1,600,000 pixels. Held in memory as RGBA it occupies four bytes for every one of them: 6,400,000 bytes, about 6.1 MiB. Nothing in that number depends on which tool you are holding; it is the arithmetic of a pixel grid, and it is the baseline every format starts from before it does anything clever.

Save it as PNG and the pixel data is filtered line by line and passed through DEFLATE, which is very good at the long runs of identical bytes that flat interface colours produce. The alpha channel costs a quarter of the raw total — 1,600,000 of those bytes — for the privilege of being empty everywhere. Save it as JPEG at a middling quality setting and the luminance of every one of those pixels goes through the same 8×8 transform as a holiday photo, text included.

JPEG also subsamples colour, keeping chroma at half width and half height: one colour sample shared across each 2×2 group of pixels. That saving is genuinely free on a photograph and buys nothing at all on a screenshot, because the thing you need to preserve in a screenshot is the luminance of the text, and luminance is not subsampled.

If you are ever unsure what a file really is, the first few bytes will say. PNG begins with 89 50 4E 47 0D 0A 1A 0A; JPEG begins FF D8 FF. Renaming a .jpg to .png changes nothing inside the file, and a browser reads the bytes rather than the name, so the rename achieves nothing until a build step takes the extension at its word and rejects the upload.

Transparency rules one format out

JPEG has no alpha channel. Not a limited one, not an optional one — the format has nowhere to put a fourth value, so there is no such thing as a JPEG with a see-through region. When you save a transparent PNG as JPEG, the encoder has to do something with the empty pixels, and editors disagree about what: some composite onto white, some onto black. Either way you get a solid rectangle where the transparency used to be, and the transparency is not recoverable from the result. This is the most common way a logo ends up sitting in a grey box on somebody's homepage.

PNG stores an alpha channel alongside the colour, which is exactly why its raw pixel is four bytes rather than three, and it can also be saved as a palette image with one colour marked transparent when you want the file small. WebP and AVIF both carry alpha and composite correctly against whatever the page puts behind them. If the logo exists as vector artwork, none of this applies and the right answer is SVG, which has no pixel grid to compress in the first place.

WebP is safe now, AVIF is smaller

WebP shipped in 2010 and spent most of a decade as the format nobody could rely on, because Safari would not decode it. That stopped being true in 2020, when Safari 14 shipped support, and every current version of every browser you are likely to be serving to now reads it. That makes it the safe modern default: one file, lossy or lossless as you choose, with alpha and animation both available at the same time.

AVIF is newer and usually smaller at the same visual quality, particularly at the low bitrates where a full-width hero image lives. It gets there by borrowing the intra-frame coding from the AV1 video format, and intra-frame coding is expensive by design: AV1 spends a great deal of computation to save a little bandwidth, so an AVIF encode can take several times as long as the same image in WebP. Its support is younger too. Chrome read AVIF from version 85 in 2020, Firefox from 93 in 2021, Safari from 16.1 in 2022 — so a phone kept for six years, or a publishing tool written before 2022, may not be able to open the file you produced.

The arrangement I would pick is AVIF for the browsers that ask for it and WebP for everything else: two encodes, one <picture> element with the AVIF first, and the encoder time paid once at build time rather than by every visitor. If you are producing a single file and cannot serve a fallback, produce WebP.

The formats side by side

The Reach column is the one that moves. AVIF's row is the only one still filling in, which is why it is the one worth checking against your own analytics before you commit a site to it.

What each format can carry

PNG's animation cell reads no because APNG is a separate specification bolted onto the format. Current browsers render it, but design tools rarely write it, so you cannot count on producing one by accident. WebP's lossless mode is the one to reach for on a diagram: it keeps every pixel exact and still lands well under the PNG, because its colour cache handles flat fills better than DEFLATE alone does.

Animation, and the progressive JPEG

GIF is a lossless format with a 256-colour ceiling per frame and a single fully transparent colour. That ceiling was generous in 1987 and is a visible defect on anything photographic now: skies band, gradients stair-step. An animated WebP does the same job with a real colour space and a fraction of the weight. GIF survives on inertia in the tools, not on any property of the format.

The other flag worth knowing is progressive versus baseline JPEG, and it is the one setting almost nobody changes deliberately. Baseline writes the image top to bottom in a single pass, so a slow connection reveals it as a strip that grows downwards. Progressive writes several passes: a coarse, blurry version of the whole picture first, then successive refinements, so the reader sees the composition immediately and sharpness arrives after. It usually comes out a little smaller at the same quality setting as well, which is why the "save for web" command in most editors reaches for it by default. The cost is more work at decode time, which was a real objection in 2005 and is not one now. Leave it on.

The mistakes that actually cost you

A logo saved as JPEG. Flat colour gets ringing along every edge, the type goes soft, and the transparent background becomes a solid rectangle.

A screenshot saved as JPEG. This is the one people do most, because the camera roll and the screenshot folder share an export dialog. The text is the first thing to fail, and text is usually the entire reason the screenshot exists.

A photograph saved as PNG. Photographic detail is close to incompressible to DEFLATE, so the file stays in the megabytes where a JPEG of the same picture is a fraction of that. PNG is the right answer for flat images and roughly the worst possible one for a photo.

A JPEG re-encoded from another JPEG. Each lossy pass discards detail that has already been discarded once, and the losses compound: the second generation is visibly worse than the first at the same quality setting, and the third worse again. Resizing an image and saving it is a second generation. Converting it to PNG and back is a second generation too, and the PNG step costs you nothing but recovers nothing either. Go back to the original every time, and export once at the size you will actually display.

The rule I use

The order of the questions is short. Does it have hard edges and text, or continuous tone? A screenshot, a chart, a logo or anything with type on it goes to PNG, or to lossless WebP if you want the smaller file. A photograph goes to WebP, and to AVIF as well if you can serve a fallback. Then: does anything need to be transparent? If yes, JPEG is off the table no matter what the first answer was.

The check that catches almost every mistake is to open the saved file at 100% zoom and look at the smallest text in the picture. If the letterforms are crisp and the background behind them is the colour you expected, you picked correctly. If the type looks like it is being viewed through a smeared window, you saved a diagram in a photograph's format, and no amount of quality slider will fix it — the transform is doing exactly what it was designed to do to the detail you needed.