JPG vs PNG vs WebP vs AVIF: which image format should you use?

Four formats cover nearly every still image on the web, and each one is the right answer somewhere. JPG is the one everything opens. PNG is exact. WebP and AVIF are the newer, smaller options. Below is how they differ, what we measured when we saved the same images in all of them, and a plain decision guide at the end.

The short answer

If you only remember one thing: photos want a lossy format, graphics with flat color and sharp edges want a lossless one, and anything going to an unknown destination should be JPG or PNG.

How each format compresses

JPG (JPEG) divides the image into small blocks and stores each as a mix of smooth patterns, using a discrete cosine transform, then rounds away fine detail according to the quality setting. In everyday use it is lossy and 8 bits per color channel, and has been around long enough that every device and app reads it. Hard edges, like text on a flat background, tend to pick up faint ringing and smudges.

PNG is lossless. It predicts each pixel from its neighbors and compresses the small leftovers with the same family of compression used in zip files. It shines when the same colors repeat: a screenshot or logo can be tiny. A photo, full of random variation, cannot be predicted well, so PNG photos are large.

WebP has two separate modes. Lossy WebP, per its specification (RFC 9649), uses the intra-frame coding of the VP8 video codec. Like JPG it works in blocks, but it also predicts each block from its neighbors, so it needs fewer bits to describe the same picture. Lossless WebP is an entirely different encoder that stores pixel values exactly. Google’s WebP documentation reports lossless WebP files 26% smaller than PNGs and lossy WebP 25–34% smaller than comparable JPGs at equivalent SSIM quality; those are Google’s figures on its own test sets.

AVIF stores a still frame of the AV1 video codec inside a HEIF container, as defined by the Alliance for Open Media. AV1 is a newer and more elaborate codec than VP8 or JPEG, and MDN describes AVIF’s compression gain over JPEG as larger than WebP’s. AVIF supports lossless coding too, but it is mostly used lossy.

Measured: the same images in every format

We encoded two test images with the same open-source codecs our tools use: MozJPEG for JPG, libwebp for WebP, libavif with the AOM encoder for AVIF, and OxiPNG for PNG. Sizes are in kilobytes, where 1 KB = 1,000 bytes.

• Photo: a synthetic 1600 × 1200 scene (sky gradient, hills, a sun and fine grain-like noise), decoded from our test JPG to raw pixels first.
• Graphic: a 640 × 480 flat-color image with a transparent background. JPG has no transparency: the JPG rows were flattened onto white first.

What stands out:

• Lossy WebP at 75 was 25% smaller than JPG at 75 on the photo (61.2 KB vs 81.4 KB). At 88, though, WebP came out at 185.0 KB against JPG’s 176.0 KB. Same number, different scales: the quality figure means something different in each encoder.
• AVIF at 50 was the smallest lossy result by far, 12.3 KB. At 66 it jumped to 86.7 KB. Our test photo is covered in fine random grain; at the lower setting AVIF smooths most of it away, while at the higher one it spends bytes trying to keep it. Real photos with less noise usually behave more gently, but the lesson holds: judge by eye and by bytes, not by the setting.
• Lossless is the wrong tool for photos. PNG was 1,222.8 KB, 15× the JPG. Lossless WebP did better at 828.7 KB (32% smaller than PNG) but is still far larger than any lossy option.
• For the graphic, lossless wins outright. Lossless WebP was 0.9 KB and PNG 1.2 KB, while lossy WebP (4.7 KB), AVIF (2.4 KB) and JPG (8.6 KB) were all bigger, and lossy as well, so the edges are no longer pixel-exact.

Transparency and animation

Transparency. JPG has none: transparent areas must be filled with a solid color, which is what the PNG to JPG converter does (white by default, or any color you choose). PNG has full alpha transparency. WebP supports an alpha channel in both lossy and lossless modes, according to RFC 9649, and the AVIF specification stores transparency as an auxiliary alpha image. Google notes that lossy WebP with transparency is typically about three times smaller than the equivalent PNG, which makes it attractive for transparent product photos on a website.

Animation. JPG has no animation. PNG gained an official animated form when the W3C’s PNG Third Edition (a Recommendation since June 2025) incorporated APNG. WebP supports multiple frames with pauses between them, and AVIF supports image sequences. For anything long, web.dev recommends a video element instead of an animated GIF.

Color depth and HDR, at a high level

Ordinary images use 8 bits per color channel: 256 levels each of red, green and blue. That is fine for most photos on most screens. HDR (high dynamic range) and wide-gamut images need more levels, otherwise smooth gradients band visibly.

• JPG: 8 bits per channel in practice, per MDN. No standard HDR in the everyday format.
• PNG: up to 16 bits per channel. The Third Edition added a cICP chunk, so a PNG can declare HDR color spaces.
• WebP: 8 bits per channel. Lossy WebP also stores color at reduced resolution (4:2:0), which can soften fine colored detail such as red text.
• AVIF: 8, 10 and 12 bits, with HDR and wide color gamut signaled in the file, per the AVIF specification. It is the strongest choice of the four for HDR.

Whether HDR actually shows up depends on the display, the operating system and the app, so treat it as a bonus rather than a reason to switch.

Browser and app support (as of October 2026)

JPG and PNG work everywhere. For the newer two, these are the versions from which support begins, checked against MDN’s image format guide and Apple’s own release notes:

Apple’s Safari 14 release notes list “Added WebP image support”, shipping with iOS 14 and macOS Big Sur. The WebKit team’s Safari 16.1 post says still and animated AVIF are supported on iOS 16, iPadOS 16 and macOS Ventura. Note that Safari’s support for these formats depends on the operating system version, not just the Safari version.

Outside browsers, support is patchier. Some upload forms, print services and older desktop apps accept only JPG and PNG, whatever your browser can display. When a destination is unknown, send JPG for photos and PNG for graphics. MDN’s guidance for websites is the <picture> element: list AVIF and WebP sources first and a JPG or PNG fallback last, and each browser picks the first one it understands.

Encoding speed

Smaller files cost effort. Here is how long each encode of our 1600 × 1200 test photo took on one machine (Node 24.9.0, x64, single-threaded WebAssembly). Absolute times will differ on yours; the ratios are the useful part.

JPG and lossy WebP are quick. AVIF took roughly 8.8× as long as JPG here, at the encoder speed setting our tools use, and both lossless encoders were slower still on the photo. If you are converting a big batch on a phone, expect the JPG to AVIF converter to take noticeably longer than the WebP converter; it has an encoder speed setting that trades a little size for time.

Which format to use when

• Photo for email, a form, a print shop or anyone you don’t know: JPG. Compress it with the image compressor; quality 75 to 85 suits most screens.
• Photo on your own website: WebP, or AVIF for the smallest files, with a JPG fallback in a <picture> element. Convert in a batch with the WebP converter or the JPG to AVIF converter.
• Screenshot, chart, logo or anything with text: PNG, or lossless WebP on the web. Avoid JPG here; it smudges edges and can come out bigger.
• Transparent product shot or sticker for a website: lossy WebP or AVIF, both of which keep transparency at a fraction of PNG’s size.
• Something you received and can’t open: convert it with WebP to JPG or AVIF to JPG.
• A master copy you’ll edit later: keep the original file, and only make compressed copies from it. Each lossy re-save loses a little more.

For the practical side of shrinking images to fit a limit, including target sizes like 100 KB and email attachment limits, see our guide on compressing images for the web and email.

Written and checked by the PixWrench team against the sources listed above. Spotted something out of date? Tell us and we’ll check it and note the fix in the changelog.