JPG vs PNG vs WebP: which to use when

The last time I checked, a single product photo on a client's homepage was eating 847 KB as a PNG. Same image, re-exported as a quality-85 JPG: 94 KB. Thrown through a WebP converter: 67 KB with no visible difference. That's not a rounding error. That's the difference between a page that feels snappy and one that makes mobile visitors bounce before your hero section loads.

So let's talk about jpg vs png vs webp, not as abstract formats on a spec sheet, but as actual tools you're picking for actual jobs. I'll tell you what I recommend for each scenario, no hedging.

The One-Sentence Version

JPG for photographs, PNG for graphics with transparency or sharp edges, WebP for almost everything if you control your pipeline. Now let's ruin that simplicity with the details that actually matter.

JPG: The Workhorse That Won't Die

JPEG (let's just call it JPG, everyone's file extensions do) dates back to 1992. It's lossy, meaning it throws away data to shrink files, and it's built around how human eyes work. We're worse at seeing color shifts than brightness shifts, so JPG cheats on color detail and keeps luminance relatively clean.

This makes JPG genuinely excellent for photographs. Landscapes, portraits, product shots, anything with gradients and natural textures. A well-compressed JPG at quality 80-85 is often indistinguishable from the original to anyone who isn't pixel-peeping with a calibrated monitor.

Where JPG falls apart: text, line art, logos, anything with sharp edges and solid colors. The compression artifacts show up as blocky halos around high-contrast edges. And transparency? Forget it. JPG doesn't do alpha channels. You want a logo on a transparent background, you're using PNG or WebP, full stop.

Another JPG trap: repeated editing. Every save re-compresses. Open a JPG, tweak it, save as JPG again, and you've introduced a new generation of artifacts. For archival or work-in-progress, use PNG or a lossless format. Only bake to JPG as the final step.

My recommendation: Use JPG for all photographs destined for web. Experiment with quality settings. Most images get away with 75-85. Big hero images might deserve 90. Never use 100; the file size explodes for marginal gain.

PNG: The Specialist You Can't Replace

PNG arrived in 1996 as a patent-free alternative to GIF, and it inherited the web's expectations about transparency and lossless compression. Unlike JPG, PNG compresses without throwing away data. A pixel that's #FF0044 in your source stays exactly #FF0044 in the PNG.

This losslessness plus alpha transparency makes PNG unbeatable for specific jobs:

Logos and icons with transparent backgrounds
Screenshots with text (preserves sharp edges)
UI elements, buttons, badges
Any image where exact colors matter (brand colors, charts, diagrams)
Images you'll edit repeatedly before final export

The catch? File sizes balloon for photographic content. That 847 KB PNG I mentioned was a product photo someone exported from Photoshop's "Save for Web" defaulting to PNG. No transparency needed, no text, just a photo of a shoe. Wrong tool.

PNG also comes in two flavors that confuse people: PNG-8 (256 colors max, like GIF) and PNG-24 (full color). PNG-8 can shrink files for simple graphics but introduces banding on gradients. Most of the time you're using PNG-24 whether you know it or not.

My recommendation: Default to PNG only when you need transparency or perfect edge sharpness. For everything else, it's probably the wrong choice. If you're serving PNG photographs on a production site, you should have a specific reason I can argue with.

WebP: The Format That Should Have Won Already

Google announced WebP in 2010, and for years it was that annoying format you had to polyfill or ignore. Those days are over. Every modern browser supports WebP. Safari added full support in 2020 (version 14), which was the last holdout worth worrying about.

WebP gives you both lossy and lossless modes, plus alpha transparency, plus animation (replacing GIF in theory, though animated WebP adoption lags). The lossy mode typically beats JPG by 25-35% at equivalent visual quality. The lossless mode usually compresses 25% smaller than PNG.

Here's where it gets practical. I ran a quick batch on some real assets:

Image	JPG (85)	PNG-24	WebP (lossy, 85)	WebP (lossless)
Portrait photo	142 KB	1.1 MB	98 KB	n/a (don't)
Product shot	94 KB	847 KB	67 KB	n/a (don't)
Logo (transparent)	n/a	45 KB	28 KB	34 KB
Screenshot with text	187 KB	320 KB	134 KB	241 KB

The pattern: WebP lossy dominates JPG territory. WebP lossless or with transparency competes with PNG but doesn't always crush it. For logos specifically, a well-optimized PNG-8 sometimes beats WebP lossless, though WebP lossy with alpha is usually the sweet spot.

Caveats: WebP encoding is slower. Your build process or image pipeline needs to handle it. You need fallback strategies for the vanishingly small slice of ancient browsers, or for email clients, or for native apps with older WebViews. And animated WebP? Support exists but tooling feels half-baked compared to video formats.

My recommendation: If you control your stack, WebP should be your default for web delivery. Serve it with JPG/PNG fallbacks via <picture> elements or responsive image syntax. For one-off conversions without setting up a pipeline, our HEIC to WebP tool or JPG to PNG / PNG to JPG converters can bridge gaps.

The Actual Decision Tree

Skip the flowchart. Here's what to do:

Photograph, no transparency needed, broad compatibility required → JPG. Still the safest default if you can't serve multiple formats.

Photograph, no transparency, you control your assets → WebP lossy. Smaller, same quality, compress aggressively.

Logo, icon, anything with transparency → WebP with alpha if you can. PNG-24 if you can't. Never JPG (no transparency) unless you're committing to a solid background color.

Screenshot, diagram, text-heavy image → PNG if file size doesn't matter. WebP lossless if you need smaller. Avoid JPG; the text gets fuzzy.

Animation → Video (MP4/WebM) for anything longer than a few seconds. GIF if you must for meme compatibility. Animated WebP exists but rarely wins decisively.

Archive, master file, repeated editing → Neither of these three, honestly. Use TIFF, PSD, or your editor's native format. Only export to web formats at the end.

Size Comparisons That Actually Matter

I see too many posts citing "WebP is 30% smaller" without context. Thirty percent of what? At what quality? Compared to a carefully optimized JPG or a bloated default?

The truth: format choice is maybe half the battle. The other half is how you encode within that format. A badly exported JPG at quality 95 is often larger than a well-tuned WebP at quality 80. A PNG run through a proper optimizer like oxipng or ImageOptim can drop 40% without touching a pixel.

If you're serious about this, you need to look at your actual images, your actual quality tolerance, your actual traffic. Tools like our resize utility matter too. A 4000-pixel-wide photo scaled down to 1200 before format optimization saves more bytes than any format trick.

Browser Support: The Reality in 2024

Here's the current map, as of my last reliable check:

Chrome: WebP since 2012
Firefox: WebP since 2019
Safari: WebP since version 14 (macOS Big Sur, iOS 14), September 2020
Edge: WebP since Chromium adoption (2020)

Globally, WebP support sits around 96-97% depending on which metrics source you trust. The remaining slice is older Safari on unmaintained iOS devices, some embedded WebViews, and oddball corporate environments on ancient browsers.

For most sites, serving WebP with a JPG/PNG fallback covers everyone who matters. The <picture> element makes this trivial:

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

Email is the lingering exception. HTML email rendering is a swamp of inconsistent support. Stick to JPG and PNG for email campaigns unless you've tested extensively in your specific ESP.

What About AVIF and JPEG XL?

I'll mention these because you'll hear about them. AVIF, based on AV1 video encoding, can beat WebP by another meaningful margin. Browser support is growing but not universal (Safari added it in 2023). JPEG XL promised to be the one format to rule them all, but Chrome removed support in 2023 after adding it, citing maintenance burden and unclear adoption. The politics there are messy and still unfolding.

My take: Don't build around either yet unless you have a specific performance team with time to burn. WebP is the boring, correct choice for production today. Revisit in a year or two.

The Honest Bottom Line

JPG vs PNG vs WebP isn't a religious debate. It's resource allocation. JPG costs you some quality for compatibility and size. PNG costs you bytes for precision. WebP costs you pipeline complexity for efficiency.

If you're a solo developer or small team without image optimization infrastructure, start with JPG for photos, PNG for transparency needs, and add WebP when you can automate it. Our convert tools can handle one-offs or small batches without setting up a build pipeline.

If you do control your pipeline, WebP first with fallbacks is the modern standard. Not because it's new, because the numbers are genuinely better and the compatibility problem is solved.

Stop serving 800 KB PNG photographs. That's my real advice. Pick the right tool, tune your export settings, and your pages will feel faster without you touching a line of JavaScript.