Most guides to image formats give you a comparison table and leave you to it. The table is the easy part. The useful part is knowing which conversions are safe, which are one-way doors, and why a file sometimes gets bigger when you convert it to a “more efficient” format.
Here is the short version, and then the reasoning.
| JPG | PNG | WebP | |
|---|---|---|---|
| Compression | Lossy | Lossless | Both |
| Transparency | No | Yes | Yes |
| Best for | Photographs | Graphics, text, screenshots | Almost anything on the web |
| Browser support | Universal | Universal | 96.2% |
| Re-saving costs quality | Yes | No | If lossy |
The distinction that actually matters
Not the file extension. Whether the format throws information away.
JPG is lossy. The encoder discards detail it judges you will not miss, and the discarded detail does not come back. This is why JPG files are small and why photographs look fine in them.
PNG is lossless. It compresses, but every pixel you put in comes back out exactly. Nothing is discarded, which is why PNG files are large and why a screenshot of text stays crisp.
WebP is both, depending on how it is saved. This is the source of most confusion about it.
Everything else follows from this.
Why lossy is right for photographs and wrong for screenshots
Lossy compression exploits the fact that human vision is bad at noticing certain kinds of detail — subtle variation in smooth gradients, fine colour shifts, high-frequency texture. Photographs are made almost entirely of exactly that. Discarding it is nearly free.
Now take a screenshot containing text. Text is hard edges: sharp black-to-white transitions with nothing in between. That is precisely the high-frequency information a lossy encoder discards first. Save a screenshot as JPG and the text develops a grey halo, letters blur, and thin lines break up. The file is small and the content is degraded in the one way that matters.
The rule that follows: photographs to JPG or lossy WebP, anything with text or hard edges to PNG or lossless WebP.
The conversions that cost you
Converting between formats is not symmetric. Some directions are free, some are lossy, and some are lossy in a way you will not notice until later.
PNG → JPG. Lossy, and irreversible. You also lose transparency — transparent areas become white or black depending on the encoder. Converting back to PNG afterwards does not restore anything; you get a lossless copy of a degraded image.
JPG → PNG. Lossless in the sense that nothing further is discarded, but pointless in a specific way: you are storing an already-degraded image in a format optimised for perfect fidelity. The file usually gets substantially bigger while looking exactly the same. This is the single most common mistake we see.
JPG → JPG. Every re-save discards more. Editing a photo, saving, opening it, editing again and saving compounds the loss. Work from an original and export once.
Anything → WebP. Lossy WebP from a JPG means two rounds of lossy compression on the same image. It will usually still be smaller and still look acceptable, but you have paid twice. Where you have the original, convert from that.
PNG → WebP lossless. Genuinely free. Typically 20–30% smaller with pixel-identical output.
Why your file sometimes gets bigger
A conversion that promises efficiency and delivers a larger file is not a bug. It is one of these:
Already compressed. A JPG saved at a moderate quality has had most of its redundancy removed. Re-encoding it cannot find much more, and the new format’s container overhead can exceed what it saves.
Wrong format for the content. A photograph in PNG is large because PNG refuses to discard anything. A flat-colour logo in JPG is large because JPG is trying to encode hard edges it is not built for.
Small images. Below a few kilobytes, format headers dominate. A 16×16 icon may well be biggest in the format that is theoretically most efficient.
Our compressor handles this case explicitly: if a re-encode produces a file larger than the original, it keeps the original and tells you so on the row. A tool that silently hands back something bigger and calls it compressed is not doing you a service. In testing across two photographs we saw 2.36 MB reduced to 37.8 KB — a 98% reduction — and the guard exists for the cases where that does not happen.
Where WebP stands now
WebP reaches 96.2% of browsers — Chrome since 32, Firefox since 65, Edge since 18, Safari since 16. For web delivery the compatibility question is effectively settled.
It is meaningfully smaller than JPG at equivalent quality, supports transparency where JPG does not, and offers a lossless mode that beats PNG. For images on a website, it is usually the right answer.
The caveats are outside the browser. Support in desktop applications, older image editors, print workflows and some operating-system preview panes remains patchier than browser numbers suggest. WebP for your website, JPG or PNG for anything you are sending to another person or another system.
AVIF is the newer option, now at 94.7% browser support, and compresses better than WebP again — often noticeably so at low file sizes. Encoding is slower and tooling is thinner. If you are optimising a high-traffic site it is worth testing. For general use WebP remains the pragmatic choice.
What quality number to actually pick
Every lossy encoder exposes a quality setting, usually 0–100, and the number does not mean what people assume. It is not a percentage of quality retained. It is an index into how aggressively the encoder discards detail, and the relationship is sharply non-linear.
The useful ranges, for photographs:
- 95–100 — very close to visually lossless, and files two to three times larger than they need to be. Worth it only for images that will be edited further.
- 80–90 — the sensible default. Differences from the original are hard to see at normal viewing size, and the file is a fraction of the size.
- 70–80 — good for web delivery where page weight matters. Slight softening in fine detail if you look for it.
- Below 60 — visible artefacts around edges and in flat areas. Acceptable for thumbnails, not for anything a reader will look at properly.
The important point is that the curve is steep at the top and flat in the middle. Going from 100 to 90 typically halves the file size at almost no visible cost. Going from 90 to 80 saves much less and costs a little more. Going from 70 to 60 saves very little and costs a great deal. Most of the benefit is in that first step, which is why 100 is almost always the wrong choice.
Graphics with text and hard edges do not follow this curve at all — they degrade visibly at any lossy setting. Use a lossless format for those rather than hunting for a quality number that works.
Choosing, in practice
Photograph for the web → WebP, or JPG at quality 80–85 if you need maximum compatibility.
Photograph to send someone → JPG. It opens everywhere, on everything.
Screenshot, diagram, or anything with text → PNG, or lossless WebP for the web.
Logo or icon → SVG if you have it, because it scales to any size without loss. PNG if you need a raster version — rasterise from the SVG at the size you actually need rather than scaling a PNG up.
Image needing transparency → PNG or WebP. Not JPG, which has no alpha channel at all.
Archival original → keep it in whatever the camera or scanner produced, and convert copies. Never overwrite an original with a lossy export.
The one habit worth forming
Keep originals. Convert copies.
Almost every quality problem in this article comes from the same source: an original being replaced by a lossy version, then that version being edited and re-saved, then converted again. Each step is small and none is visible on its own. The result, after five rounds, is a photograph that looks noticeably worse than the one you took, with no way back.
Disk is cheap. The original is not recoverable.
Convert between JPG, PNG and WebP in your browser with our image converter, or reduce file size with the compressor. Nothing is uploaded.