WebP vs JPG vs PNG: Choosing the Right Image Format

Every few years I see the same thread on Twitter or in a Slack channel. Someone asks whether they should still be using JPG, someone else recommends WebP for everything, a third person insists PNG is fine, and the conversation devolves into format tribalism.

The actual answer is boring and useful: each format has a clear use case, and the cost of choosing wrong is real but not catastrophic. This post is the conversation I wish I could just send to people instead of having it for the hundredth time.

The three formats in thirty seconds

JPG (or JPEG). Lossy compression. Throws away visual information you probably will not notice, in exchange for much smaller files. Designed in 1992 for photographs. Still excellent for that one job.

PNG. Lossless compression. Reconstructs the original image bit-for-bit, but produces much larger files for photos. Supports transparency. Designed for screenshots, diagrams, logos, and anything with sharp edges or alpha channels.

WebP. Released by Google in 2010. Supports both lossy and lossless modes, plus transparency. Typically produces 25 to 35 percent smaller files than JPG or PNG at the same visible quality. Universally supported in modern browsers.

If you read nothing else, that is the decision in three sentences. The rest of this post explains why, and walks through the edge cases that actually trip people up.

How JPG compresses (and why it loves photos)

JPG breaks an image into 8 by 8 pixel blocks and runs each one through a mathematical transform called the discrete cosine transform. The result is a list of frequency components that describe how the colors change across the block. High-frequency components correspond to fine detail. Low-frequency components correspond to broad gradients.

The compression step throws away high-frequency information that human vision is bad at noticing. Then it stores what is left in a compact form.

This works extremely well on photographs because photos are full of gradients and natural noise, which compress beautifully. It works badly on screenshots and diagrams, which are full of sharp edges and flat color blocks. Those produce visible artifacts that designers refer to as "JPG mosquitoes," small fuzzy disturbances around edges.

A practical example: a 3000 by 2000 pixel photo of a sunset, saved as JPG at quality 80, often comes in around 400 KB. The same image as PNG would be 6 MB or more. For that use case, JPG is straightforwardly correct.

How PNG compresses (and why it loves flat color)

PNG uses lossless compression. It runs the image through a filter that predicts each pixel from its neighbors, then compresses the differences with the same algorithm used by ZIP files. The output is a perfect reconstruction of the input, byte for byte.

PNG shines when the image has large areas of identical color, hard edges, or transparency. Screenshots, icons, diagrams, logos, illustrations with flat fills. All of these compress efficiently because the predictor gets most pixels right and the leftover differences are tiny.

PNG also supports transparency through an alpha channel, which JPG does not. If you need anti-aliased edges on a logo overlaid against a non-white background, PNG is basically the only classical option.

Where PNG struggles: photographs. A photo as PNG is often 10 to 20 times larger than the same photo as JPG, with no visible quality improvement to make up for it. People who default to PNG for everything end up serving multi-megabyte hero images and wondering why their site is slow.

How WebP compresses (and why it took over)

WebP supports both modes. Lossy WebP uses a more modern prediction system than JPG and a smarter entropy coder, which typically produces files 25 to 35 percent smaller at visually equivalent quality. Lossless WebP similarly improves on PNG, usually by around 25 percent for the same use cases.

It also supports transparency in both modes. Lossy WebP with transparency is a category JPG cannot offer at all, and it is genuinely useful. Product photos with cleanly cut-out backgrounds, hero illustrations with translucent edges, anything that previously had to choose between PNG bloat and a JPG with a baked-in solid background.

The headline number, "25 to 35 percent smaller," sounds modest until you multiply it across an entire site. A media-heavy product page that was 6 MB on JPG and PNG often drops to 4 MB on WebP with no perceptual change. That difference is the gap between a page that loads instantly on a mid-range Android phone and one that does not.

When to use each format

A decision flowchart, distilled.

Is this a photograph, or anything photograph-like (real-world scene, gradients, natural noise)? Use WebP if you control the serving stack. JPG if you do not, or if you need maximum compatibility with weird tools.

Does this image have flat colors, sharp edges, text, or screenshots? Use WebP (lossless mode) if you control the stack. PNG otherwise.

Does this image need transparency? Use WebP if you control the stack. PNG otherwise. Avoid JPG entirely for this case.

Is this a tiny icon (under a few KB)? PNG is fine. The compression savings of WebP are absolute, not proportional, so they barely matter at this size.

Is this a screenshot for a blog post or documentation? PNG is the default. WebP is fine too. Avoid JPG, the text edges will look fuzzy.

Is this an avatar or social media profile picture? Whatever the platform accepts. They usually re-encode anyway.

Browser support reality

This is the part where the answer used to be complicated and is now simple.

WebP is supported by every modern browser. Chrome since 2010. Firefox since 2019. Safari since 2020 (macOS) and 2021 (iOS). Edge since 2018. The only places you might still run into trouble are very old enterprise installs of Internet Explorer, ancient Android devices that have not received system updates in years, and some embedded webviews.

For the vast majority of public-facing web traffic, you can serve WebP directly. For audiences with unusual constraints, the safe pattern is the HTML <picture> element with WebP as the primary source and JPG or PNG as the fallback:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="...">
</picture>

Browsers that understand WebP pick it. Browsers that do not fall back gracefully. No JavaScript required.

What about AVIF?

AVIF is the next contender. Based on the AV1 video codec, it usually compresses 20 to 50 percent better than WebP at the same quality. The catch is encoder maturity and browser support.

Browser support is good in Chrome (2020) and Firefox (2021), reasonable in Safari (2023+), and absent in older mobile webviews. So AVIF is shippable today via the same <picture> fallback pattern, but you need both AVIF and WebP sources to cover everyone modern, plus a JPG for stragglers.

The other AVIF wrinkle is encode speed. AVIF encoders are dramatically slower than WebP, which matters if you are batch-converting thousands of images or running optimization in CI. Decoding is fine, it is mostly an authoring-side cost.

My honest take: AVIF is worth adopting if you are running a serious media-heavy site and have the build pipeline to handle multi-format generation. For most everything else, WebP is the sweet spot in 2026. The browser support, encoder maturity, and tooling are all in place, and the compression wins versus JPG and PNG are large enough to matter without being so large that AVIF dominates.

Common mistakes I keep seeing

A few patterns worth flagging.

Defaulting to PNG for everything. This is the single most common cause of slow pages I get asked to look at. PNG photos can easily multiply your page weight by 10x.

Re-saving JPGs multiple times. Every save through a lossy encoder discards a little more information. By the third or fourth round trip, the result looks visibly degraded. If you are editing in stages, work in PNG or a lossless format and only export to JPG or WebP at the end.

Using PNG for transparent photos with soft edges. This works but produces huge files. WebP with transparency is the modern alternative.

Serving the same image at the same dimensions to every device. Even with the right format, a 3000 pixel wide image being downloaded by a phone displaying it at 400 pixels is waste. Use srcset for responsive images.

Trusting the source app's defaults. Quality 100 JPG is almost never what you want. Quality 80 to 85 is the sweet spot for most photos and produces files less than half the size.

A practical workflow

If you need a default workflow that works without much thought:

1. Photos and photo-like content: encode as WebP, quality 80.
2. Screenshots, logos, diagrams: encode as PNG, or WebP lossless if you control the stack.
3. Animated content where compatibility matters: stick with GIF or use a video format with autoplay muted loop.
4. Always include alt text. Always set explicit width and height attributes to prevent layout shift.

If you want a no-install tool for batch encoding and format conversion, Reezo's free image compressor and image converter both run entirely in your browser. Nothing gets uploaded anywhere. The compressor handles the size reduction. The converter handles the format change when you need PNG to WebP or JPG to WebP.

The takeaway

JPG for photos when you cannot use WebP. PNG for sharp-edged content and transparency when you cannot use WebP. WebP for everything else, with <picture> fallback if your audience is unusually old-browser-heavy. AVIF if you are running a serious media stack and have the pipeline to produce multiple formats.

That is the whole decision. It is genuinely not more complicated than that. The format tribalism on social media is mostly people who picked their position five years ago and never updated it. Browser support has moved. Encoder quality has moved. The right answer in 2026 is mostly WebP, and the cases where it is not are clearly delineated.