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

Short answer, as of October 2026:

• Photos on a website: AVIF or WebP, with a JPEG fallback in a <picture> element. Both newer formats are supported by about 96 to 97% of browsers in use, and both compress photos better than JPEG.
• Photos you send or upload (email attachments, forms, marketplaces, print shops): JPEG. Every device and app opens it.
• Screenshots, diagrams, and anything that needs transparency: PNG, or lossless WebP if you control where it is displayed. Logos and icons are better as SVG when you have the vector file.

The rest of this article explains why, where each format breaks down, and how to serve AVIF and WebP without leaving older browsers with a broken image. If you only need to change a file's format, the SnapCompress converter turns JPEG, PNG, WebP, and HEIC into JPEG, PNG, or WebP in your browser, with no upload. It does not produce AVIF.

Last updated: October 8, 2026

What actually separates these formats?

Three properties decide almost every format choice: how the format compresses, whether it has an alpha channel (transparency), and which software can open it.

Lossy compression throws away detail the eye is unlikely to notice. MDN puts it plainly: photographs "can usually tolerate lossy compression, because the discarded detail is harder to see." Lossless compression keeps every pixel, which matters for text, sharp edges, and anything you will edit again. For screenshots, diagrams, logos, and line art, MDN recommends lossless encoding because blurring and colored fringes around edges are easy to see.

The "outside the browser" row is a SnapCompress recommendation, not a measured statistic. It reflects the practical risk that the recipient's mail client, photo app, or upload form rejects a newer format.

JPEG: still the default for photos you share

JPEG has been the standard for photographs since the early 1990s. MDN calls it "currently the most widely used lossy compression format for still images." Its strengths are boring and important: every browser, operating system, email client, and printing service accepts it, and you can trade quality for size with a single slider.

Where it fails:

• No transparency. JPEG has no alpha channel. A logo with a transparent background saved as JPEG ends up on a solid rectangle.
• Text and hard edges. Lossy compression produces visible ringing around letters and lines, which is why charts and screenshots look smudged as JPEG.
• Generational loss. Every lossy re-save discards more detail. Keep your original and export from it each time rather than re-saving the JPEG.

Use JPEG when you do not control where the file will be opened. That includes most "please attach a photo" situations. For sending photos by email specifically, see how to reduce image size for email.

PNG: for screenshots, diagrams, and transparency

PNG is lossless and supports full alpha transparency. MDN says "PNG is preferred over JPEG for more precise reproduction of source images, or when transparency is needed," and it is the usual fallback for any image that needs transparency.

The cost is size. A photograph saved as PNG keeps every bit of sensor noise, so it is usually several times larger than a JPEG of the same picture with no visible benefit. Don't use PNG for photos.

Use PNG for screenshots, UI mockups, charts, diagrams, and raster logos with transparent backgrounds. If you have the logo or icon as a vector, MDN recommends SVG first, because it stays sharp at any size.

WebP: the safe modern default

WebP is Google's image format for the web. According to Google's WebP documentation, lossy WebP files are 25 to 34% smaller than comparable JPEGs at equivalent SSIM quality, lossless WebP files are 26% smaller than PNGs, and lossless transparency costs about 22% extra bytes. These are Google's figures across its test sets; your images will vary.

On caniuse.com/webp, WebP had 97.18% global support (97.08% full, 0.1% partial) when I checked on October 8, 2026. Full support starts at Chrome 32, Edge 18, Firefox 65, Safari 16.0 on macOS (14 to 15.6 are partial), and Safari 14 on iOS.

WebP's weak spot is outside the browser. Older image editors, some email clients, and some upload forms still reject it. That is why the advice above keeps JPEG for files you send to other people.

AVIF: the smallest files, with real trade-offs

AVIF is the still-image format built on the AV1 video codec from the Alliance for Open Media. The AVIF specification page describes it as an open standard that supports lossy and lossless compression, high dynamic range, wide color gamut, transparency, and animation.

How much smaller is AVIF?

It depends on the image and the encoder settings, so treat any single percentage with care. The sources agree on direction:

• The web.dev guide Using AVIF to compress images on your site reports "greater than 50% savings vs. JPEG" seen by its authors and others.
• MDN says AVIF "offers much better compression than PNG or JPEG" and, compared with WebP, "slightly better compression."

So AVIF usually beats WebP on photos, but the gap between AVIF and WebP is smaller than the gap between WebP and JPEG. If you want to see how quality settings change file size on real images, the compressor benchmark is where SnapCompress publishes its measurements.

Browser support

On caniuse.com/avif, AVIF had 96.35% global support (96.33% full, 0.02% partial) on October 8, 2026. Full support starts at Chrome 85, Firefox 93, Edge 121, Safari 16.4 on macOS (16.1 to 16.3 are partial), and Safari 16.0 on iOS. Edge was the last major browser to add full support. As web.dev's Learn Images course puts it, a browser that doesn't support an encoding "won't be able to parse that image file at all," so AVIF without a fallback means a missing image for those visitors.

That is about one percentage point behind WebP. Still, MDN warns that AVIF support "is not yet comprehensive (and has little historical depth)" and tells you to provide a WebP, JPEG, or PNG fallback. The <picture> example below does exactly that.

Encoding cost

AVIF's main cost is on the encoding side. The web.dev AVIF guide spends most of its length on encoder speed settings and multi-threading, notes that "higher speed settings will run faster, but produce worse compression efficiency and quality," and strongly recommends an image CDN instead of encoding by hand. For a blog with a few dozen images, encoding once at build time is fine. For thousands of user uploads converted on the fly, budget for the CPU time or let an image CDN do it.

Progressive rendering

AVIF does not render progressively. MDN notes that AVIF files "must be fully downloaded before they can be displayed." That rarely matters for small images, but on a large hero image over a slow connection a progressive JPEG shows something sooner.

When to use AVIF

Use AVIF for photographic images on pages you control, served through <picture> with a WebP or JPEG fallback, especially large images where bytes matter most. Skip AVIF for files you hand to other people and for workflows where you cannot add a fallback. SnapCompress cannot create AVIF files; use an encoder such as Squoosh (listed in the web.dev AVIF guide), libavif, or sharp for that step.

How to serve AVIF and WebP with a fallback

The <picture> element lets the browser choose. Each <source> has a type; per MDN's picture reference, "if the user agent does not support the given type, the <source> element is skipped," and the <img> inside is the fallback when no source works. List the format you prefer first.

<picture>
  <source srcset="hero-800.avif 800w, hero-1600.avif 1600w" type="image/avif" sizes="(min-width: 800px) 800px, 100vw">
  <source srcset="hero-800.webp 800w, hero-1600.webp 1600w" type="image/webp" sizes="(min-width: 800px) 800px, 100vw">
  <img src="hero-800.jpg"
       srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
       sizes="(min-width: 800px) 800px, 100vw"
       width="800" height="533"
       alt="Describe what the photo shows">
</picture>

A few details that are easy to get wrong:

• Put alt, width, and height on the <img>, not on <picture> or <source>. The <img> is what actually renders; the sources only swap its file.
• Keep the same dimensions and crop across all formats. The browser picks a format, not a different picture.
• Encode each format from the original, not from the JPEG. Converting a JPEG to AVIF stacks a second round of lossy compression on top of the first.
• Frameworks and image CDNs often do this for you. If yours negotiates formats from the browser's Accept header, you get the same effect without writing <picture> by hand.

Which format should I use? A decision table

This table is a SnapCompress recommendation built from the MDN guidance and the support figures above. The pattern is simple: newer formats where you control the delivery and can add a fallback, older formats where you don't.

What about HEIC?

HEIC is what iPhones save by default. It is a camera and storage format, not a web format: most browsers cannot display it, so it does not belong in the comparison above. If you are dealing with iPhone photos that won't open, read HEIC vs JPEG, or convert them with the HEIC to JPG tool.

Converting between JPEG, PNG, and WebP

The SnapCompress converter runs entirely in your browser. Here is what it does, taken from its source code:

• Outputs JPEG, PNG, or WebP. It cannot output AVIF or HEIC.
• Encodes WebP with libwebp compiled to WebAssembly, and PNG with a WebAssembly PNG encoder.
• Uses 85% quality by default for JPEG and WebP. You can change it with the quality slider.
• If a JPEG or WebP result comes out larger than the file you started with, it re-encodes once at a lower quality and keeps whichever version is smaller.
• PNG output is always lossless, so there is no quality setting. Converting a photo to PNG will usually make it bigger.

Two conversions to avoid. First, converting a transparent PNG to JPEG removes the transparency, because JPEG cannot store it. Second, converting JPEG to PNG does not restore lost quality; it only makes the file larger. To make files smaller without changing format, use the compressor instead, and see how to compress images for quality settings. For the effect of image formats on page speed, see image optimization for Core Web Vitals.

If you work from the command line, Google's cwebp and the avifenc encoder that ships with libavif cover WebP and AVIF. The web.dev AVIF guide walks through avifenc settings.

Sources

All accessed October 8, 2026.

• Can I use: WebP image format, caniuse.com. Global support 97.18%, version table.
• Can I use: AVIF image format, caniuse.com. Global support 96.35%, version table.
• Image file type and format guide, MDN Web Docs. Format recommendations, AVIF progressive rendering, fallback advice.
• The picture element, MDN Web Docs. How type and the <img> fallback work.
• An image format for the Web (WebP), Google for Developers. WebP size comparisons with JPEG and PNG.
• Using AVIF to compress images on your site, web.dev. AVIF savings, encoder speed settings, image CDN recommendation.
• AVIF, web.dev Learn Images. Fallback advice.
• cwebp, Google for Developers.
• libavif, AOMedia on GitHub. Provides avifenc.
• sharp. Lists AVIF and WebP among its output formats.
• AV1 Image File Format (AVIF), Alliance for Open Media. AVIF features and specification versions.
• SnapCompress converter source code (src/lib/image-processing/converter.ts). Output formats, default quality, and retry behavior.