JPEG vs WebP vs AVIF: which format when

JPEG dates from 1992 and works on 8×8 pixel blocks: each block is converted with a discrete cosine transform, the high-frequency coefficients are quantised away, and colour is usually stored at half resolution (4:2:0 chroma subsampling). That is why heavily compressed JPEGs show blocky artefacts and colour smearing around sharp edges. The decoder is tiny and fast, and after three decades there is hardly a device that cannot read the result.

WebP, released by Google in 2010, borrows the intra-frame coding of the VP8 video codec. Blocks can be predicted from their neighbours before being transformed, which removes redundancy JPEG cannot see, and a loop filter softens block edges. Google's own measurements put lossy WebP at 25–34% smaller than JPEG at the same structural similarity. WebP also has a separate lossless mode that beats PNG by roughly a quarter on typical graphics.

AVIF is the still-image profile of the AV1 video codec, standardised by the Alliance for Open Media in 2019. It adds larger and variable block sizes, far more prediction modes, better entropy coding and optional film-grain synthesis. In practice AVIF files come out around half the size of a JPEG and about 20% smaller than WebP at matching quality, with the biggest gains at low and medium bitrates. At very high quality settings the advantage narrows, and AVIF tends to smooth fine texture that JPEG would keep as noise.

JPEG has no alpha channel at all: convert a transparent PNG to JPEG and the transparent area becomes whatever the converter fills it with, usually white or, in careless tools, black. WebP supports alpha in both its lossy and lossless modes, and by default compresses the alpha plane losslessly so edges stay crisp. AVIF also carries alpha, plus 10- and 12-bit colour and HDR metadata, which neither JPEG nor WebP can do.

For animation, GIF is limited to 256 colours per frame and compresses badly. Animated WebP has been supported everywhere for years and is typically several times smaller than the same GIF. Animated AVIF (image sequences) is smaller still but arrived in browsers later, so test it on the devices your audience actually uses before relying on it. For anything longer than a few seconds, a muted looping video is smaller than any image format.

Decoding support is no longer a worry. WebP has been readable in Chrome, Edge and Firefox for years and in Safari since version 14 (2020). AVIF decoding arrived in Chrome 85 (2020), Firefox 93 (2021), Safari 16 (2022, all Apple platforms from 16.4) and Edge 121 (January 2024). If your analytics show a meaningful share of browsers older than that, a <picture> element with a JPEG fallback costs nothing and covers them.

Encoding is a different story, and it matters for browser-based tools like PixelShrinkr, which use the browser's own canvas encoder. Every engine can write JPEG and PNG from a canvas. Chromium-based browsers and Firefox can write WebP; Safari cannot, and silently returns PNG instead. AVIF encoding from a canvas is currently available in Chromium-based browsers only. PixelShrinkr feature-detects all of this when the page loads and only offers the formats your browser can actually produce.

JPEG encodes in milliseconds. WebP takes a few times longer, which is still unnoticeable for a handful of images. AVIF is the outlier: the reference encoder searches an enormous space of block sizes and prediction modes, and at its slower speed presets a single 12-megapixel photo can take tens of seconds on a laptop. Browser canvas encoders and CLI tools use fast presets by default, trading a few percent of compression for a wait measured in seconds rather than minutes.

Decoding also costs more as you move right along that list. On a low-end phone, a page full of large AVIF files can take noticeably longer to paint than the same page in JPEG, even though fewer bytes travel over the network. For the largest, above-the-fold image this occasionally cancels out the transfer savings; for a grid of thumbnails it never does. When in doubt, measure Largest Contentful Paint on a real mid-range device rather than assuming smaller is always faster.

JPEG remains the only format you can send anywhere without thinking: email clients, print services, government upload forms, older CMS installs, and desktop software from the previous decade all accept it. It is also the format cameras write natively, the one whose EXIF and colour-profile handling is universally understood, and the one that decodes fastest on weak hardware. Progressive JPEG gives a usable preview after the first few kilobytes, which no browser currently offers for AVIF.

There is a quality argument too. For an archive master at quality 95, AVIF's size advantage shrinks to a few percent while its encoder smooths grain and fine texture. Photographers who want the pixels they shot, not a plausible reconstruction of them, are right to keep JPEG (or better, the raw file) as the master and generate WebP or AVIF derivatives for the web.

For photographs and anything with soft gradients, use a lossy format and let the encoder work: AVIF where you control the pipeline and can afford the encode time, WebP as the fast all-rounder, JPEG where compatibility or decode speed rules. For flat graphics, screenshots, logos and text, lossy coding is the wrong tool: chroma subsampling blurs coloured edges and quantisation puts halos around letters. Use PNG or lossless WebP, and if the source is vector, ship SVG.

The one honest exception is the large screenshot with a photo inside it, where lossless files become enormous. There, WebP at quality 90 or AVIF with 4:4:4 chroma (which AVIF supports and lossy WebP does not) keeps text readable at a fraction of the PNG size. Whatever you choose, pick it once per image type, encode from the original rather than from an earlier lossy copy, and check the result at 100% zoom before trusting a number on a slider.