WebP vs JPEG vs PNG: How I Actually Choose

After two decades of shipping websites, I can tell you the "which format?" question is decided wrongly more often than any other image decision — usually by habit rather than by looking at the picture. The honest answer fits in one sentence: photos go in JPEG or WebP, graphics go in PNG, and WebP wins whenever you control the site. The rest of this page is the reasoning, so you can handle the edge cases yourself.

The 30-second comparison

JPEG: old, limited, and still everywhere for a reason

JPEG is from 1992, and its longevity is not an accident. It was engineered around how human vision works — we notice brightness far more than color, and gradual changes far more than fine detail — and for photographs that recipe still delivers 80–90% size reductions that most people genuinely cannot see. (If you want the full pipeline, DCT and quantization and all, I walk through it in How Image Compression Actually Works.)

Its real superpower today is compatibility. Every browser, every email client, every ancient point-of-sale system, every marketplace upload form: they all eat JPEG without complaint. When I don't control where an image will end up, I send JPEG and sleep fine.

The trade-offs you live with: no transparency, ugly ringing artifacts around sharp edges and text, and generation loss — every re-save quietly degrades the image a little more. That last one bites people constantly; compress once, from the original, and keep the original.

PNG: the format for pixels you can't afford to lose

PNG (1996, built as a patent-free GIF replacement) is lossless: what you save is exactly what you get back, forever. It also has proper 8-bit alpha transparency, which JPEG simply doesn't.

PNG compresses by predicting each pixel from its neighbors and storing only the differences, then running the result through DEFLATE — the ZIP algorithm. That works brilliantly when neighboring pixels are similar (flat UI colors, text on a plain background) and terribly when they aren't (photographic noise). Consequence: a screenshot might be 15 KB, while a photo of the same dimensions balloons to over a megabyte.

So my PNG rule is simple: logos, screenshots, diagrams, anything with text or transparency — PNG, no debate. Photographs — never PNG for web delivery. I still see product photos shipped as 4 MB PNGs weekly, and it's the single most expensive image mistake you can make on a storefront.

WebP: the default when you own the website

WebP is Google's 2010 attempt to replace both formats at once, built on tricks from the VP8 video codec. Blocks are predicted from their already-decoded neighbors rather than compressed independently, which is most of why it beats JPEG by 25–35% at the same visual quality. Its lossless mode undercuts PNG by around 26%. It does transparency. It even does animation, better than GIF ever did.

The catch used to be browser support; that argument is dead — everything current supports it, north of 97% of real-world traffic. The catches that remain are smaller: some email clients and older desktop tools still choke on it, and encoding is slower than JPEG (irrelevant for a website, noticeable if you batch-process thousands of files).

To give you a feel for the difference, here's a typical result from a 2000×1333 product-style photograph compressed to matching visual quality — proportions like these repeat across most photographic content I've tested:

My decision rules, written down

This is the whole framework I use, in the order I apply it:

1. Is it a graphic — logo, screenshot, text, transparency? PNG. Stop here. No lossy format handles sharp edges gracefully, and a graphic as PNG is usually tiny anyway.
2. Do I control where it's displayed (my own site or app)? WebP. Smallest files, and every visitor's browser can decode it. If I'm feeling thorough I serve WebP inside a <picture> element with a JPEG fallback, but in 2026 that's belt-and-suspenders.
3. Is it going somewhere I don't control — email, a marketplace, a client's CMS, social media? JPEG. Compatibility beats a 30% size win the moment one recipient can't open the file. Amazon explicitly prefers JPEG; Instagram converts everything to JPEG anyway; most email clients still won't render WebP.
4. Will the file be edited again later? Keep a lossless master (PNG or the camera original) and export fresh copies. Never treat a compressed JPEG as your source of truth.

What about AVIF?

AVIF is the next format in line — roughly 50% smaller than JPEG, HDR support, transparency, built on the AV1 video codec. Support sits around 93% and climbing. I don't reach for it as a default yet: encoding is slow, tooling is patchier, and the gain over WebP is modest for typical web photos. My advice is to build your pipeline around WebP today in a way that makes swapping in AVIF trivial tomorrow — if you're using <picture>, it's one extra <source> line when you're ready.

Related guides

• How Image Compression Actually Works — the pipeline behind all three formats
• Reducing JPEG size without visible quality loss
• Compress WebP images in your browser