JPG vs PNG vs WebP: Which Should You Use?

If you take one thing: WebP is the default now, not the adventurous choice. Every current browser reads it, and it is better than both alternatives at their own specialities — smaller than JPEG for photographs, smaller than PNG for graphics.

JPEG (1992) is the lossy photographic workhorse — MDN calls it "the most widely used lossy compression format for still images", built on the discrete cosine transform. It discards fine detail your eye is poor at noticing, which makes it excellent for photographs and poor for anything with hard edges. No transparency, no animation.

PNG (1996) is lossless. The W3C specification, now in its third edition, describes it as providing "lossless, portable, well-compressed storage" whose filtering and compression "preserve all information", and positions it as a patent-free replacement for GIF. Full alpha transparency, no animation in ordinary use. Compresses flat colour and repetition brilliantly and photographs barely at all.

WebP (2010) does both. MDN describes its lossy mode as "predictive coding based on the VP8 video codec" and its lossless mode as using "substitutions for repeating data". It supports transparency in both modes and animation, which makes it the only one of the three that covers every case.

Two others belong in the conversation. AVIF compresses better still — MDN puts it at a median 50% reduction against JPEG where WebP achieves 30% on the same set — and GIF is essentially obsolete for still images: every pixel is an index into a palette limited to at most 256 colours, which is why photographs in GIF look posterised.

Google's own documentation for WebP gives the comparisons that matter, and they are specific about what was measured:

• WebP lossy is 25–34% smaller than comparable JPEG at equivalent SSIM quality index. The SSIM qualifier matters — this is a like-for-like perceptual comparison rather than a file-size race at arbitrary settings.
• WebP lossless is 26% smaller than PNG.
• Transparency costs about 22% additional bytes in lossless WebP, and lossy WebP with transparency is typically around three times smaller than the PNG equivalent.

A worked example, for a 2000-pixel-wide photograph:

The PNG row is the important one. It is not a mistake — a lossless photograph really is roughly ten times a good lossy one, because there is no redundancy in a photograph for lossless compression to exploit. Saving photographs as PNG is one of the most common and most expensive mistakes in image work.

Not many cases, but they are real.

Universal compatibility. Everything reads JPEG: old print software, embedded devices, ancient corporate systems, that one client's photo-upload form written in 2007. If a file has to work everywhere without you being able to test, JPEG is the safe choice.

Print and photography workflows. Labs, stock libraries and camera software expect JPEG or TIFF. Sending WebP to a printer will produce a phone call.

Very old browsers. Only relevant if your analytics actually show them; every current browser handles WebP.

Where JPEG genuinely loses: it cannot do transparency at all, it damages text and line art badly, and it is simply larger than WebP for the same visual result. If your reason for choosing it is habit rather than one of the three above, it is habit.

PNG's advantage is that it is lossless and universally supported at the same time — WebP lossless is smaller but slightly less universally handled by non-browser software.

Use PNG for:

Screenshots, if you are not using WebP. MDN's guidance is explicit: "unless you're willing to compromise on quality, you should use a lossless format for screenshots." Text and interface edges are exactly what lossy compression damages first.

Line art, diagrams and logos where you do not have the vector original.

Images with sharp edges against flat colour, where lossy artifacts show immediately.

Anything an external tool must open reliably — a design handoff, an asset going into a print document.

Where PNG genuinely loses: photographs, catastrophically, as the table above shows. And even in its own territory WebP lossless beats it by around a quarter for a file every browser can read, which is why the compressor offers to switch the output to WebP when it notices a PNG that will otherwise only shrink through resizing.

AVIF is the best compressor of the four by a clear margin — MDN's median figures are 50% against JPEG versus WebP's 30% — with support for higher colour depths, transparency and animation. On paper it is the obvious successor.

Three reasons to hold WebP as the default anyway.

Encoding support is less consistent than decoding. A browser that displays AVIF happily may not be able to produce it, which matters for a tool that encodes in the browser. ToolForge's converter and compressor probe this at load — testing whether the canvas will actually emit the format rather than assuming — and only offer AVIF when the answer is yes. That is also why the option sometimes appears on one of your machines and not another.

Encoding is slow. AVIF is computationally much heavier than WebP, which is fine on a build server and noticeable in a browser tab with a batch of large photographs.

The marginal gain is smaller than the first move was. Going from JPEG to WebP is a large, easy win. Going from WebP to AVIF is a further improvement with more friction, and worth it mainly if images dominate your page weight.

The pragmatic position: WebP everywhere, AVIF where you serve multiple formats and can measure the difference. If you are hand-exporting files one at a time, WebP is the sensible stopping point.

If you control the HTML, you do not have to choose at all. The picture element offers formats in order and the browser takes the first it understands, so modern visitors get AVIF or WebP and everyone else gets JPEG.

That is the professional answer for a real site, and it costs you generating two or three copies of every image at build time — which is what an image CDN or a framework's image component does for you.

If you are converting files by hand for a CMS that takes one upload, convert to WebP and stop there. It is supported everywhere that matters, and the difference between WebP and a perfectly tuned multi-format setup is much smaller than the difference between WebP and the 4 MB PNG someone was about to upload.

Either way, the format choice is only half of it: an image served in the perfect format at four times the dimensions it displays at is still wasting most of its bytes. Working out the size you need is the other half.