The fork that comes before the format
Before you pick JPEG or WebP or AVIF, pick between lossy and lossless compression, that is the decision that actually matters, and the format name is almost a consequence of it. Lossy compression discards information the eye tends not to notice and never gets it back: the file shrinks irreversibly. Lossless compression rearranges the same bits more economically and reconstructs the image identically, pixel for pixel. A landscape photo tolerates loss without you noticing; a diagram with text and sharp edges betrays the loss immediately, with halos and grime around the letters.
Lossy
- Discards perceptually cheap detail; the result cannot return to the original.
- Much smaller files on photographic content and gradients.
- Artifacts show up on hard edges, text and flat areas.
- JPEG; lossy WebP; lossy AVIF.
Lossless
- Reconstructs the image identically, bit for bit.
- Ideal for text, icons, screenshots and line art.
- Terrible for photography: there is no "throwaway" detail to save.
- PNG; lossless WebP; lossless AVIF.
Notice that WebP and AVIF appear in both columns: each has a lossy mode and a lossless mode, and they are almost different codecs inside. JPEG, by contrast, is lossy-only in practice (the standard’s lossless mode never caught on), and PNG is lossless-only. That is why the fork comes first: it removes half the options before you compare sizes. When you want to move the quality dial and watch the file shrink, the image compressor does it in the browser, without sending the photo to any server.
What each format really does
JPEG converts the image to YCbCr space (splitting brightness from color), almost always subsamples the color, the famous 4:2:0, which stores color at half the horizontal and vertical resolution because the eye is less sensitive to it, and applies the Discrete Cosine Transform on 8×8 pixel blocks, quantizing the coefficients. Hence the two classic artifacts: blocking and ringing around edges. JPEG has no alpha channel (no transparency) and, in progressive mode, the data arrives in scans that refine the whole image from blurry to sharp, useful on slow connections.
PNG is lossless: it filters each row of pixels (predicting each one from its neighbors, Paeth-style) and compresses the result with DEFLATE, the same algorithm as ZIP. It carries a real alpha channel and comes in two flavors: PNG-8, an indexed palette of up to 256 colors (great for simple icons), and PNG-24/32, truecolor with or without alpha. It is excellent for few colors and crisp edges, and terrible for photography, with no loss there is no "invisible" detail to throw away, so a photo’s natural grain turns into a huge file.
WebP, from Google, is really two codecs under one name. Its lossy mode reuses the intra-frame coding of VP8 video, it treats the photo as a single key frame, and is limited to 8 bits per channel and 4:2:0 subsampling. Its lossless mode is a separate algorithm, more efficient than PNG. Both support alpha, including the lossy one (something JPEG never had), and WebP also does animation. It has been supported by every modern browser for years.
AVIF is the still-image sibling of the AV1 video codec, from the Alliance for Open Media, wrapped in the same container family (ISOBMFF/HEIF) as Apple’s HEIC. It is the most capable of the list: 10- and 12-bit color, HDR (with the PQ and HLG transfer curves), wide gamut, 4:2:0/4:2:2/4:4:4 subsampling, an alpha channel, animation and even film-grain synthesis. That power has a price, encoding AVIF is CPU-expensive, far slower than JPEG or WebP, which changes when and where it makes sense to generate it.
- DCT (8×8)
- Discrete Cosine Transform applied on 8×8 pixel blocks; the basis of JPEG compression. Quantizing its coefficients is what "loses" information.
- Chroma subsampling
- 4:2:0 stores color at reduced resolution (the eye forgives it); 4:4:4 keeps full-resolution color, better for colored text and fine edges.
- DEFLATE
- Lossless compression (LZ77 + Huffman) used by PNG and ZIP. It removes redundancy but discards no detail, which is why it does not help with photography.
- Intra-frame coding
- Compressing an image as if it were a single video key frame. WebP inherits this from VP8; AVIF, from AV1, which is why they descend from video codecs.
How much you save, and why the number depends on everything
Vendors publish numbers, and they are real as long as you read the fine print. Google measures lossy WebP at 25% to 34% smaller than a comparable JPEG at the same SSIM quality index, and lossless WebP at 26% smaller than PNG. The Alliance for Open Media cites AVIF at over 50% savings against JPEG (referencing Netflix) and over 30% against WebP (referencing Vimeo). All true, and all conditional.
Why "conditional"? Because the savings depend on the image content, on the quality metric chosen (SSIM, MS-SSIM, VMAF and butteraugli measure different things) and on the encoder and preset. Netflix’s own AVIF study reports gains via BD-rate and deliberately avoids VMAF, since it was trained for video, not still images. And the study’s concrete examples show the gulf: on one test image, a JPEG of 13,939 bytes became an AVIF of 4,176 bytes at comparable quality (a ~70% drop); on another, a JPEG of 20,429 bytes and an AVIF of 19,788 bytes were essentially tied (~3%). Same codec, same target quality, savings between 3% and 70% depending only on what the photo shows.
View the data
| Category | Value |
|---|---|
| JPEG | 100% |
| PNG | 100% |
| WebP | 96.15% |
| AVIF | 93.42% |
The shape of the chart is this guide’s central argument. JPEG and PNG have been universal since the 1990s. WebP passed 96% support and reached Safari in 2020. AVIF, newer, sits around 93%, which sounds high until you translate it: roughly 1 in 15 visitors still cannot display an AVIF. That is exactly why "convert everything to AVIF and be done" breaks: with no alternative, those visitors see a broken image.
The feature matrix
Size is only one axis. Many decisions resolve by capability: do you need transparency? Animation? Exact reconstruction? More than 8 bits for a banding-free sky? The matrix below crosses the four raster formats with what each offers, plus the Safari version that began displaying them and the relative encoding cost.
| Format | Alpha | Animation | Lossless | HDR / 10-bit+ | Safari since | Encode cost |
|---|---|---|---|---|---|---|
| JPEG | No | No | No (in practice) | No | always | Low |
| PNG | Yes | No (APNG aside) | Yes (only) | No | always | Low |
| WebP | Yes | Yes | Yes | No (8-bit, 4:2:0) | 14 (2020) | Low–medium |
| AVIF | Yes | Yes | Yes | Yes (10/12-bit) | 16.4 (2023) | High |
Two rows of this table settle entire cases. If you need transparency, JPEG is out, go PNG, WebP or AVIF. If you need more than 8 bits (a sky or skin gradient with no visible banding), only AVIF delivers on the web, and this is where it beats WebP not on size but on capability: lossy WebP is locked to 8-bit and 4:2:0. Need exact reconstruction of a text screenshot? Any format with "Yes" in the lossless column works.
The correct delivery: <picture> with fallback
Because AVIF and WebP are not universal, the right delivery is not to pick one format, it is to offer several and let the browser take the first it understands. The <picture> element does this: the browser walks the <source> list in order, skips the types it does not support and uses the first compatible one; the <img> at the end is the universal fallback that carries the alt text and dimensions. Put the most efficient, least supported format on top and the most compatible one at the bottom.
<picture>
<source type="image/avif" srcset="foto.avif" />
<source type="image/webp" srcset="foto.webp" />
<img
src="foto.jpg"
alt="Descrição da imagem"
width="1200"
height="800"
loading="lazy"
decoding="async"
/>
</picture>This is why "convert everything to AVIF" is bad advice: the correct delivery is not a file, it is a chain, and you generate the variants in a build pipeline or an image CDN, not by hand. To generate the versions, the image converter transcodes between formats in the browser; if the source is vector, the SVG to PNG converter rasterizes at the resolution you ask for. Always keep the lossless original archived, from a PNG or TIFF master you can regenerate AVIF and WebP when support shifts; from an already-compressed AVIF there is no going back.
Small images and icons
On a 48×48 thumbnail or an icon, AVIF’s compression advantage nearly vanishes, because there is little detail to save. An optimized PNG or a WebP tends to tie or win, and for a UI icon SVG beats them all, vector scales with no pixels and no new file per resolution.
CPU cost of encoding
Encoding AV1/AVIF is much slower than JPEG or WebP. In a cached build pipeline that is acceptable. Generating AVIF on demand per request, uncached, turns CPU into a bottleneck and a cost. Slower presets yield smaller files; fast presets throw part of the advantage away.
Fine textures and smoothing
At low bitrates, AV1 encoding tends to smooth grain and fine texture, leaving skin, foliage and fabric looking "plasticky". JPEG errs differently (blocking and ringing). Which flaw bothers you more depends on the image, and the metric you used to "prove" the savings may hide exactly this kind of loss.
Container overhead
AVIF wraps the AV1 payload in an ISOBMFF/HEIF container with metadata boxes. That fixed cost is irrelevant on a large photo, but on tiny payloads it can flip the advantage: the "smaller" AVIF ends up larger than a plain WebP or PNG of the same icon.
How to decide, by content type
Combine the fork (lossy vs lossless), the feature matrix and support, and the decision becomes mechanical. Classify the image by what it contains, not by the format it arrived in:
- Photography (landscape, portrait, product): lossy. AVIF on top for size and 10-bit, WebP as the second, JPEG as fallback, served via <picture>.
- Graphics with flat areas and text (diagrams, infographics): lossless. PNG or lossless WebP keep the edges crisp; JPEG and lossy AVIF/WebP smear the letters.
- Logo, icon or vector illustration: SVG. It scales with no loss of sharpness, weighs little and needs no file per resolution.
- Screenshot with text: PNG or lossless WebP. It is text over flat backgrounds, the same case as the diagram.
- Need transparency over a photo (soft shadow, a heavy PNG with alpha): WebP or AVIF with alpha, which compress the alpha far better than PNG-32.
One format you meet outside the web is missing: HEIC. Apple adopted it as the iPhone camera default because it stores photos in far less space than JPEG, it is the same HEVC video codec, in the HEIF container, a cousin of AVIF. The web barely uses it for two reasons: HEVC is burdened by patents and licensing, and browsers do not display it natively. So if you receive a .heic and need to publish it, convert first, the HEIC to JPG converter does it in the browser, and remember that when you convert you may carry along the EXIF location and camera metadata.
One last color detail, for anyone shipping 10-bit AVIF or dealing with transparency: understanding how color values are written and why a gradient develops bands helps diagnose the banding that 8-bit JPEG and WebP produce. The color spaces: HEX, RGB and HSL guide covers it, and if your images are size-responsive, pair <picture> with fluid typography and layout using clamp().
Frequently asked questions
Is AVIF always better than WebP?
Can I just convert everything to AVIF?
Why does PNG get huge on photography?
Which format for logos and icons?
Does JPEG support transparency?
There is no "best format", there is the right decision per image. Choose first between lossy and lossless, then by what the image contains: photography wants lossy AVIF/WebP with a JPEG fallback; text and flat areas want PNG or lossless WebP; a logo wants SVG. AVIF is the most capable, not the universal default: ship a <picture> chain, keep the lossless original, and distrust any savings percentage that does not say on which image, with which metric and with which encoder it was measured.