Use WebP for images on your own website, falling back to JPG when a file has to work everywhere: email attachments, print shops, older software. Use PNG when every pixel must be exact or the image has hard edges and few colours, as with screenshots, diagrams and logos without a vector version. AVIF often beats them all on size, and is worth serving as well if your site has a build step that can make it.
The numbers below show why. We encoded three images using Pillow 13 (libjpeg-turbo 3.2, libwebp 1.6, libavif 1.4), with the same settings for each image. The photo is a real camera image reduced to 1600 by 1088. The screenshot is a 1600 by 1000 dashboard with text, charts and a table, captured from Chromium. The logo is 512 by 512 with a transparent background.
| Format and setting | Photo | Screenshot | Logo (transparent) |
|---|---|---|---|
| JPG, quality 80 | 213,763 | 143,806 | Cannot store transparency |
| PNG | 2,536,470 | 114,756 | 15,482 |
| PNG, reduced to 256 colours | Not tested | 47,031 | Not tested |
| WebP lossy, quality 80 | 127,796 | 75,972 | 8,100 |
| WebP lossless | 1,733,558 | 24,600 | 5,952 |
| AVIF, quality 50 | 72,032 | 19,953 | 4,349 |
All sizes are in bytes. One warning about reading this table: “quality 80” in one format is not the same as “quality 80” in another, because each scale is that encoder’s own. Compare by looking at the results at the size you will show them, not by matching numbers.
Look at how each column’s winner changes. For the photo, PNG is 12 times the size of JPG. For the screenshot, PNG beats JPG even though JPG is lossy, and looks better. Lossless WebP cuts that same screenshot to less than a quarter of PNG’s size with no loss at all.
How each format works
JPG (JPEG)
JPEG is built around how we see photographs. It converts colour into brightness and colour channels, usually stores colour at half the resolution (chroma subsampling), splits the image into 8 by 8 blocks, and converts each block into frequencies. It then rounds off the high frequencies that eyes notice least, and that rounding is where both the savings and the loss come from.
This works beautifully on gradual variation, such as skin, sky and foliage. It works badly on sharp edges, because describing a hard black-to-white step takes a lot of high frequency detail. That is why JPG text has grey smudges around each letter, and why it lost to PNG on the screenshot. It has no transparency, and repeated saves at different settings slowly degrade it.
PNG
PNG is always lossless. Each row of pixels is first run through a filter that predicts values from neighbouring pixels, and the differences are compressed with DEFLATE, the same algorithm used in ZIP files (we explain it in how ZIP compression works). DEFLATE thrives on repetition, so flat colour and repeated shapes shrink dramatically. Camera noise does not repeat, which is why the photo stayed huge.
PNG supports a full 8-bit alpha channel, meaning smooth partial transparency for soft shadows and anti-aliased edges. It can also use a palette of up to 256 colours, as our 47 KB screenshot did. That reduces colours, so it is lossy in practice even though the file is technically PNG, but it is often invisible on interface graphics.
WebP
WebP is really two formats in one container. Lossy WebP comes from the VP8 video codec. It predicts each block from nearby blocks already decoded, then encodes the difference, which gives it an advantage over JPEG at the same visual quality. Lossless WebP (VP8L) is a separate design, with stronger techniques than PNG’s filters. Both modes support alpha, and it can also be animated.
Three limits are worth knowing. Lossy WebP always uses 4:2:0 colour, so fine coloured detail, such as thin red text, can bleed. Its maximum size is 16383 by 16383 pixels. And not all software accepts it, despite browser support, especially older desktop apps and some upload forms.
AVIF
AVIF stores AV1 video-codec frames. It gave the smallest file in every test above, at about a third of JPG’s size on the photo. The costs are slower encoding (3.9 seconds for the 1600-pixel photo in our run, against 0.4 for JPG and 1.8 for WebP at its slowest setting) and the risk of smoothing away fine texture at low settings. At the setting we used on the screenshot, check small text with your own eyes before trusting that 20 KB figure. Decoding is also heavier than JPEG.
Our tools do not produce AVIF. If you want it, use a build tool (sharp in Node, for example) or a desktop app such as ImageMagick with AVIF support.
Decision rules
Go through these in order, and stop at the first that applies.
- Is it a logo, icon or diagram you have in vector form? Use SVG, and see SVG vs PNG.
- Does the recipient’s software matter more than file size? Email attachments, print shops, government portals and anything for “non-technical people”: use JPG for photos and PNG for graphics. They work everywhere.
- Does it need transparency? On a website, use WebP. Elsewhere, use PNG. JPG is out.
- Do you need an exact copy, for medical images, source artwork for further editing or pixel-precise screenshots? Use lossless: PNG or lossless WebP.
- Is it mostly text or flat colour? Use lossless WebP, or PNG. Avoid JPG.
- Is it a photo for the web? Use WebP at around quality 75 to 85, ideally with AVIF offered first.
- Is it a photo for anything else? Use JPG at around quality 80 to 90.
And one myth to drop: converting a JPG to PNG does not improve it. The damage is already in the pixels, and you only get a bigger file holding the same damage. Keep your originals, and export from those.
Browser support
From the caniuse data as of this writing:
| Format | Chrome | Firefox | Safari | Global usage |
|---|---|---|---|---|
| JPG, PNG | All versions | All versions | All versions | Effectively universal |
| WebP | 32 and later for all features | 65 | 14 (macOS 11 or later) | About 97% |
| AVIF | 85 | 93 | 16.1 (macOS 13 or later), iOS 16 | About 96% |
Support for viewing is now close to universal, so a JPG fallback is mostly insurance. The <picture> element makes that insurance cheap, since the browser takes the first format it understands and ignores the rest:
<picture>
<source srcset="photo.avif" type="image/avif">
<source srcset="photo.webp" type="image/webp">
<img src="photo.jpg" width="1600" height="1088" alt="Describe the photo">
</picture>Keep the width and height attributes, which stop the layout jumping as images load.
Viewing and exporting are separate matters. Our browser-based converters encode through the browser’s canvas, and not every browser can write WebP. So our WebP pages note that they need Chrome, Edge or Firefox, even though Safari displays WebP without trouble.
Converting in practice
For a one-off, JPG to WebP and PNG to WebP cover the web case, and PNG to JPG handles the reverse, asking which background colour should replace any transparency. If you have a whole site’s worth of images, use a command-line tool or your build pipeline instead, so that the work is repeatable.
Format is also the second question, not the first. A 6000-pixel photo in a 700-pixel column is wasteful in any format, and resizing it first saves more than any format change could.