Image Compressor topic guide

JPEG vs PNG vs WebP: how to choose the right image format

Direct answer

JPEG, PNG and WebP solve different problems. JPEG is a lossy format built for photographs and continuous-tone images; PNG is a lossless format that preserves every pixel exactly and carries an alpha channel for transparency; WebP is a newer format that supports both lossy and lossless compression and transparency in a single container. The right choice depends on the content of the image, whether transparency is needed, the destination's decoder support, and the file-size budget you are working against. This guide walks through each format with its actual capabilities and limits, then ties the decision to a real workflow.

Try the Image Compressor

What this workflow handles

Each format trades something for something else. JPEG discards image data the eye is less sensitive to in exchange for much smaller files - it is the right pick for a photograph at quality 75 and above, where the loss is invisible at normal viewing distance. PNG preserves every pixel exactly and adds an alpha channel for transparency - it is the right pick for graphics, screenshots, line art, text rendered as raster, and any image that has to overlay another background. WebP supports both lossy and lossless modes and carries an alpha channel in both; Google Developers' WebP documentation describes the format as a modern container for both compression types, and web.dev recommends WebP and AVIF for web delivery. None of this is a hard rule - the actual byte saving depends on the image content, the pixel dimensions, the encoder settings, and the destination's decoder - but the format capability boundaries are well documented and are the right starting point. MDN's Image file type and format guide, the Google Developers WebP documentation, web.dev's modern-formats article, the WHATWG HTML Living Standard and the Pillow documentation are the canonical references.

Use the image compressor to re-encode a single image in its original format at the same pixel dimensions, then compare the byte counts in the result panel before keeping the output.

How to use it

  1. Identify what the image actually is - a photograph, a graphic, a screenshot, a logo with transparency, or a UI element.
  2. If it is a photograph with no transparency, JPEG at quality 80 is the safe default; WebP lossy at the same visual quality is usually smaller if the destination can decode it.
  3. If it is a graphic with sharp edges, text or flat colour, PNG is the safe default; WebP lossless is usually smaller if the destination can decode it.
  4. If the image needs a transparent background, PNG or WebP - JPEG cannot keep alpha. Use PNG when the destination is not a website or when maximum compatibility matters; use WebP lossy or lossless with alpha for the smallest file on a website.
  5. Resize the image to the actual display size (including the 2x retina slot for web pages) before encoding, so the encoder does not have to compress pixels that will never be seen.
  6. After encoding, check the actual output: file size in bytes, pixel dimensions, and visual quality at the display size. Compare the byte counts of the source and the output before keeping the new file.
  7. Serve the chosen file from a <picture> element with a JPEG or PNG fallback for older browsers; reference the WebP vs JPEG guide for the fallback pattern.

Common mistakes

  • Choosing the format by the file extension rather than by the content. Renaming image.jpg to image.png does not change the format - the bytes inside the file are still JPEG, and most viewers and browsers will either reject the file or display it with the wrong colours. The format is determined by the bytes inside the file, not by the extension. If you actually want PNG, re-encode the image in PNG from the source; if you actually want transparency, choose a format that carries an alpha channel and re-encode from the source.
  • Saving a photograph as PNG to 'keep quality'. PNG is lossless and produces a much larger file than a JPEG of the same photograph - typically 5 to 10 times larger. The 'quality' is preserved because PNG cannot throw away pixels, but the JPEG at quality 75 and above is visually indistinguishable from the source at normal viewing distance and the file is much smaller. Use JPEG or WebP lossy for a photograph; keep PNG for graphics that actually need lossless encoding.
  • Picking WebP and forgetting that not every tool decodes it. WebP is decoded by every modern browser but not by every email client, print pipeline or older image tool. If the destination is anything other than a website with a modern browser audience, keep a JPEG or PNG fallback, or save the file as JPEG or PNG in the first place. The transparent-image-format guide and the WebP vs JPEG guide on this site cover the fallback pattern in detail.
  • Encoding the file at the highest quality and calling it done. The quality setting has a bigger effect on file size than the format choice for most images - the difference between JPEG quality 60 and JPEG quality 95 is often a 5x file-size multiplier, with no visible benefit at normal viewing distance for quality 80 and above. Encode at a balanced default (JPEG quality 80, WebP quality 80 to 85, PNG optimize-on) and compare the actual byte counts before raising the quality.

Check the output

After running the workflow, verify these four things on the actual file before you upload it anywhere.

  • File size. Confirm the encoded file is at or below the destination's documented limit and below the byte budget you actually need. Compare the encoded file's bytes to the source - a properly chosen format and encoder should produce a meaningfully smaller file. If the encoded file is the same size or larger than the source, the format or encoder choice was wrong for the content.
  • Dimensions. Confirm the final width and height match the actual display slot, including the 2x retina slot for web pages. The Pillow documentation and Chrome for Developers' Properly size images Lighthouse audit both treat intrinsic-vs-rendered dimension mismatch as the first thing to fix.
  • Visual quality. Open the actual output at the display size and look for: sharp text edges (no fuzzy outlines from JPEG 8x8 block artefacts), correct colour (no banding in sky or gradient regions), intact transparency (no white halos around transparent edges), and intact fine detail (no smearing of hair, fabric texture or small UI elements). If any of these show, raise the quality setting, switch to a less lossy mode, or pick a different format.
  • Real destination. Upload the final file to the actual destination - the page, the product listing, the email campaign - and view it there. Browser preview, design tool preview and the live page can render colour, transparency and layout differently; the live destination is the only check that catches all of them at once.

Frequently asked questions

JPEG, PNG or WebP - which format should I use?

It depends on the image. Use JPEG for photographs and other continuous-tone images that do not need transparency - JPEG is lossy and produces the smallest files at quality 75 and above. Use PNG for graphics with sharp edges, screenshots, line art and any image that needs transparency - PNG is lossless and carries an alpha channel that JPEG cannot. Use WebP for the smallest file at the same visual quality on a website - WebP supports lossy and lossless modes plus transparency, and every modern browser decodes it. MDN's format guide, Google's WebP documentation and web.dev are the canonical references for each format's capabilities.

Which format is smallest?

On the same image at the same visual quality, WebP lossy is usually smaller than JPEG, and WebP lossless is usually smaller than PNG - but not always. Google's WebP documentation reports WebP lossy files are about 25 to 34 percent smaller than comparable JPEGs at the same visual quality. The actual saving depends on the image content, the pixel dimensions and the encoder settings; for a small flat-colour icon the per-frame metadata in WebP can leave the WebP file about the same size as the PNG. Compare the byte counts before deciding to keep a converted file.

Which format supports transparency?

PNG and WebP support an alpha channel for transparency. JPEG does not - any transparent area saved as JPEG is composited onto a solid background (usually white) before the file is written. MDN's Image file type and format guide lists transparency as a capability JPEG explicitly does not have; PNG and WebP both list it. WebP supports transparency in both lossy and lossless modes, which is part of why web.dev recommends WebP for the smallest transparent image on a website.

When is PNG the right choice over WebP?

PNG is the right choice when the destination is not a website - email, print, a marketplace upload, a design tool - and when maximum compatibility matters. PNG is supported by every browser and image tool ever made, and is lossless so the saved file is pixel-identical to the source. WebP is decoded by every modern browser but not by every email client, print pipeline or older image tool. Use PNG when the destination's decoder list is unknown or includes non-browser tools.

When is JPEG the right choice over WebP?

JPEG is the right choice when the destination requires it (some marketplaces still publish JPEG-only or JPEG-preferred lists), when the toolchain downstream of the file does not decode WebP, or when the byte saving from a WebP conversion is small enough that the format change is not worth the risk. JPEG is the most widely supported lossy image format and has been for decades. Google's WebP documentation describes the format as additional to, not a replacement for, JPEG.

Does converting an image to WebP always make it smaller?

Usually, but not always. Google's WebP documentation reports WebP lossy files are about 25 to 34 percent smaller than comparable JPEGs at the same visual quality, and WebP lossless files are usually smaller than PNG. But the saving depends on the image: a small flat-colour icon can come out similar in size or slightly larger than the source PNG because WebP carries per-frame metadata. Always compare the actual byte counts of the original and the converted file before keeping the WebP version.

Which format is best for SEO and page speed?

The format that produces the smallest file at the visual quality your page needs - in most cases WebP or AVIF on a modern website, with JPEG or PNG kept as a fallback for older clients. Google Search Central's image best practices call out fast-loading pages as a positive ranking signal and Core Web Vitals (which depend heavily on image bytes) feed into the page experience system Google uses. web.dev recommends WebP and AVIF for web performance and the <picture> + <source> pattern for serving the smallest file a browser can decode. The direct ranking lever for an individual image is descriptive file names, alt text and the surrounding page context, not the format itself.

Sources

Explore the image compressor topic cluster

Each guide answers a different image-decision question. Pick the one that matches your situation, then use the linked tool to produce the output you need.

Related guides

  • JPEG vs PNG: which format should you actually use

    JPEG is lossy and intended for photos; PNG is lossless and carries an alpha channel, so it is the right format for graphics, screenshots and anything that needs transparency. Pick by content type, not by file size. Backed by MDN, WHATWG and the Pillow documentation.

  • Transparent image format: PNG vs WebP vs AVIF for alpha

    PNG is the safest format for transparent images on the web — lossless, alpha preserved, supported everywhere. WebP and AVIF also carry alpha channels and produce smaller files, but JPEG cannot. A practical guide to choosing the right format for transparent backgrounds, with browser compatibility data from MDN.

  • How to optimize images for the web

    Optimizing an image for the web is a four-step decision chain: pick the format that matches the content, resize to the actual display size, re-encode at a balanced quality, and serve the result with a modern-format fallback. A practical guide backed by web.dev, MDN, Chrome for Developers Lighthouse audits, and the Pillow documentation.

  • Image file size vs dimensions: why pixels do not equal bytes

    A 500 by 500 image can be larger in bytes than a 2000 by 2000 image. File size depends on pixel dimensions, compression format, quality setting, colour depth and image complexity — not dimensions alone. A practical explanation with sources from MDN, web.dev and Pillow.

  • Why is my image still large after compression

    Your image may still be large after compression because the source was already optimized, the format is inefficient for the content type, the dimensions are too large for the destination, or the quality setting is too high. A troubleshooting guide with actionable checks from MDN, web.dev and Chrome for Developers.

  • Resize vs Compress: which one actually shrinks your image

    Resizing changes the pixel dimensions of an image; compression keeps the dimensions and re-encodes the file at a smaller byte count. Pick resize when the source is larger than the display size, and compression when the dimensions are right but the bytes are still too high. Backed by Chrome for Developers' two Lighthouse audits and the Pillow documentation.

  • Image alt text and SEO: how to write alt text Google Images can use

    Alt text is the value of the alt attribute on an <img> element. Google Images uses alt text together with the file name and the surrounding page text to understand what an image shows. A practical guide grounded in Google Search Central, MDN and the WHATWG HTML Living Standard.

  • How to tell if an image is over-compressed

    An over-compressed image shows visible JPEG block artefacts, ringing around edges, colour banding in gradients and smearing of sharp text. A practical checklist for spotting each symptom at the actual display size, plus when to re-encode at higher quality or switch format. Backed by MDN, web.dev, Pillow and Chrome for Developers.

All image compressor guides