PNG vs JPG vs WebP: Image Formats Explained

Save the same screenshot three ways and you’ll get three wildly different files: a 2 MB PNG, a 300 KB JPG with slightly fuzzy text, and a 150 KB WebP that looks like the PNG. None of these formats is “best” — each one is the right answer to a different question, and using the wrong one costs you either quality or a lot of kilobytes.

The question that sorts everything out: what’s in the image, and where is it going?

Lossy vs. Lossless: The One Concept That Matters

Image compression comes in two kinds:

• Lossless (PNG, and WebP in lossless mode) stores every pixel exactly. Open, edit, re-save a thousand times — the pixels never change. The cost is size: lossless can’t shrink photographs much, because photos are full of noise-like detail that doesn’t compress.
• Lossy (JPG, and WebP in lossy mode) throws away detail your eye is bad at noticing — fine texture, subtle color variation — and gets dramatic size reductions in exchange. The catch: the loss is cumulative. Every re-save of a JPG discards a little more, which is why a meme screenshotted through ten accounts looks like soup.

This maps directly to content. Photographs hide lossy artifacts beautifully — that’s what JPG was designed for. Screenshots, logos, text, and flat graphics expose them immediately: lossy compression smears the sharp edges these images are made of, so they want lossless. (Video has the exact same split between delivery and working formats — see Understanding Video Codecs.)

The Comparison Table

When PNG: Screenshots, Logos, and Anything You’ll Edit

PNG earns its size in three situations:

• Transparency. PNG’s full alpha channel is why it’s the standard for logos, icons, and UI assets composited over other content. JPG flattens transparency to a solid background, always.
• Sharp-edged content. Text and flat color compress losslessly and stay perfect.
• Working files. Because PNG never degrades, it’s the right format for images mid-edit. If a JPG is headed into an edit pipeline, converting it to PNG first stops the generation loss — it can’t restore detail the JPG already discarded, but it freezes the quality where it is.

PNG’s failure mode is photos: a photographic PNG is routinely 5–10× the size of a visually identical JPG, for detail nobody can see.

When JPG: Photos and Maximum Compatibility

JPG has been the photo format since 1992, and two things keep it on top:

• It’s extremely good at photographs. At quality 80–85, compression artifacts are invisible at normal viewing sizes and the file is a tenth of the lossless equivalent.
• Literally everything opens it. Government portals, photo kiosks, ancient Office versions, e-commerce backends, embroidery machines. When an upload form is picky, JPG is the format that never gets rejected — which is also why PNG to JPG remains one of the most-used conversions anywhere: a multi-megabyte screenshot becomes an email-friendly file at quality 85 with text still crisp.

JPG’s hard limits: no transparency, and the re-save degradation. Shoot and share in JPG; don’t edit in it.

When WebP: The Web, Almost Always

WebP, Google’s 2010-era format, essentially does both jobs: lossy mode compresses photos roughly 25–35% smaller than JPG at equivalent quality, lossless mode beats PNG’s size while keeping full alpha transparency. For images served on a website, it’s close to a free win — image weight usually dominates Largest Contentful Paint, so converting PNGs to WebP (transparency intact) and JPGs to WebP is one of the highest-leverage page-speed moves available. Quality 80 is the classic sweet spot for photos; 100 switches to true lossless.

Now the caveats, because WebP has real ones:

• The long tail of software. Browsers all support it; plenty of other things don’t. Older Photoshop versions, some upload forms, kiosk systems, and assorted enterprise tools reject .webp outright.
• The right-click problem. Sites serve WebP, so images saved from the web land as .webp on your disk — and then your editor or that picky upload form refuses them. The fix runs in reverse: WebP to PNG for a lossless copy with transparency preserved, or WebP to JPG when the destination wants a photo format.

The pattern: WebP is a delivery format for the web, the way JPG is a delivery format for everything. Keep masters as PNG (or the camera’s original JPG), serve WebP.

What About AVIF and HEIC?

Two more formats show up in this conversation, and both fit the same mental model:

• AVIF is the next step past WebP — typically another 20–30% smaller at equivalent quality, with the same alpha support, and now decoded by all major browsers. Its encoder is slower and the non-browser software support is even thinner than WebP’s, so treat it the same way: a web-delivery format, adopted when your pipeline supports it, never a master format.
• HEIC is what iPhones save photos as by default. The compression is excellent, but support outside the Apple ecosystem is close to zero — Windows tools, upload forms, and most web services reject it. For sharing, iPhone photos want the same treatment as everything else here: export or convert to JPG for compatibility, or WebP if the destination is a page you control.

The pattern doesn’t change with new formats: one lossless master, the most efficient delivery format the destination actually supports.

Quick Answers

• Screenshot to share: JPG at quality 85 (small, text still fine) — or PNG if it’s going into documentation you’ll re-edit.
• Logo or icon: PNG, or lossless WebP if it’s only ever web-served.
• Photo for a website: WebP at quality 80.
• Photo for an upload form / email / unknown destination: JPG.
• Image you’re still editing: PNG, until the final export.
• Animation: none of the above — that’s the GIF vs MP4 question, and the answer is usually MP4.

One habit ties it together: keep one lossless master, export delivery copies per destination, and never re-save a lossy file in place. Formats are cheap to convert between — detail, once discarded, is gone.