WebP vs PNG vs JPG: Which Should You Use?

Three formats do most of the work on the web, and picking between them is the single cheapest performance decision available to a site owner. WebP vs PNG vs JPG is not really a question of which format is best in the abstract — each one was designed for a different kind of picture, and WebP was designed to replace both of the others. This post compares them directly on the four things that actually decide the choice: file size, transparency, edge quality, and compatibility. For the wider context, including SVG and AVIF, see The Complete Guide to Web Image Formats.

The One-Sentence Version

JPEG is lossy-only and has no transparency. PNG is lossless and has full transparency. WebP does both jobs in one format, at 25–35% less weight than JPEG and around 26% less than PNG.

That is the whole comparison. Everything below is why, and where the exceptions live.

Round One: File Size on the Same Image

Compression only makes sense relative to content, so it helps to think in terms of two archetypes.

A photograph — a product shot, a landscape, a portrait. Continuous tone, smooth gradients, no hard edges. Take a 1600px-wide photo and encode it three ways:

• JPEG at quality 80 — the long-standing baseline. Call it 100% for comparison.
• WebP at quality 80 — typically 65–75% of the JPEG size for the same perceived quality.
• PNG — routinely 500–1000% of the JPEG size. Lossless compression has no perceptual shortcuts to exploit, so it stores every subtle sensor variation faithfully and expensively.

A flat graphic — a logo, a chart, a UI screenshot. Large uniform regions, hard edges, text. Now the ranking inverts:

• PNG — excellent, because runs of identical colour compress beautifully. Call it 100%.
• Lossless WebP — around 74% of the PNG size for identical pixels.
• JPEG — smaller in bytes, but visibly wrong. The frequency-domain trick that hides detail in a photograph produces ringing halos around every glyph and border.

Two lessons fall out of this. First, the format's job depends on the content, not on your preference. Second, WebP wins both archetypes, which is exactly why it exists.

If you want to see these numbers on your own files rather than trusting averages, the Image Compression & Format Size Estimator reports what each format and quality setting would produce for a specific image — everything computed locally in your browser, so the file you are testing never leaves your machine.

Round Two: Transparency

This is the axis that eliminates JPEG outright for a large class of images.

JPEG has no alpha channel. None. A JPEG always fills its full rectangle with opaque pixels, so if you export a logo with a transparent background as a JPEG, the transparency is flattened — usually onto white, sometimes onto black — and it is gone permanently. There is no setting that changes this.

PNG supports 8-bit alpha: each pixel can be fully opaque, fully transparent, or any of 254 levels in between. That gradation is what lets an antialiased logo edge blend cleanly onto a dark hero image one day and a white card the next without a visible fringe.

WebP supports the same full alpha channel, in both lossy and lossless modes — and this is where the size advantage becomes dramatic rather than incremental. A transparent PNG-24 stores 32 bits per pixel with no lossy option; the equivalent WebP is frequently less than half the size. If your site has a folder of transparent PNG badges, icons or product cutouts, that folder is usually the single biggest easy win on the page.

Because transparency is so often the deciding factor between the two older formats, it gets its own treatment in PNG vs JPG: When Transparency Decides for You.

Round Three: Edges, Text and Artifacts

Lossy compression is bad at sharp boundaries. This is not a JPEG bug; it is intrinsic to how frequency-domain quantisation works. Coarsen the high-frequency coefficients and any hard edge sprouts faint halos — "ringing" — plus the scattered noise around text that people call mosquito artifacts.

Practically:

• Screenshots of software, dashboards, terminals, or anything containing rendered text should never be JPEG. The artifacts around glyphs are obvious even at quality 90, and the file is often larger than a PNG of the same screenshot anyway.
• Line art, diagrams and flat illustrations belong in a lossless format for the same reason.
• Photographs with a small amount of overlaid text are a judgement call; encode at a higher quality than you would otherwise use, or overlay the text in HTML instead of baking it into the image.

WebP inherits the same weakness in its lossy mode — but unlike JPEG it can simply switch to lossless for these images and still beat PNG on size. One format, two behaviours, chosen per file.

Round Four: Compatibility

This is JPEG and PNG's remaining advantage, and it is narrower than people assume.

WebP is supported by roughly 97% of browsers in use — every current Chrome, Firefox, Safari and Edge, on desktop and mobile. The gap is Internet Explorer 11, a few legacy embedded webviews, and some non-browser software: older desktop image editors, certain email clients, and a handful of CMS upload validators that still whitelist only JPEG and PNG.

That gap is a reason to keep fallbacks, not a reason to skip WebP. The picture element handles it in four lines:

<picture>
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Product hero" width="1200" height="630">
</picture>

The browser takes the first source it understands and ignores the rest. Set explicit width and height so the layout reserves space and you do not pay a Cumulative Layout Shift penalty for the optimisation.

For anything leaving your site — email attachments, files handed to a print vendor, images uploaded into someone else's system — send JPEG or PNG. Compatibility beats efficiency the moment you lose control of the renderer.

The Decision, In Order

Ask these in sequence and stop at the first match:

1. Is it a logo, icon or diagram you have vector artwork for? Use SVG, not any of these three. See SVG vs PNG for Icons and Logos.
2. Is it a photograph? Lossy WebP at quality 75–85, JPEG fallback.
3. Does it need transparency, or contain text and hard edges? Lossless WebP, PNG fallback.
4. Is it leaving your website entirely? JPEG for photos, PNG for graphics. Do not make a recipient's software your problem.

Two things apply on every branch. Resize before you compress — serving a 4000px image into an 800px slot wastes bytes no encoder can recover, and downscaling is usually a bigger win than any format change. And set the quality deliberately after converting, because format conversion alone leaves you at whatever default the encoder shipped with.

Making the Switch

Converting an existing image library is mechanical. Work from the highest-quality originals you have — re-encoding an already-compressed JPEG stacks one round of lossy quantisation on top of another, and while the damage is usually invisible, it is permanent. Feed those originals through the Image Format Helper to produce WebP versions, keep the originals as your picture fallbacks, then tune the quality setting with the Image Compressor, checking the result at full size rather than as a thumbnail.

Both tools decode and re-encode entirely in your browser using its own codecs. That matters more than it sounds: most online image converters upload your file to a server, which means client photography, unreleased product shots and screenshots containing customer data all end up sitting on infrastructure you do not control. Local conversion also means no queue, no file-size cap, and no per-day limit on how many images you can process.

Expect roughly a third off your photographs and often more than half off your transparent graphics, with no visible difference and no change to your stack.