PNG, JPG, or WebP: choosing an image format and not regretting it

Published 14 July 2026 · 6 min read

Images are usually most of a page's weight, and the format choice is usually made by whatever the screenshot tool defaulted to. Two mistakes account for nearly all of the damage: photographs saved as PNG, and screenshots saved as JPG.

Both come from the same misunderstanding of what these formats are designed to compress.

Lossless and lossy compress different things

PNG is lossless. It finds exact repetition — runs of identical pixels, patterns it has seen before — and stores them once. Decompressing returns the original bytes exactly. This works brilliantly on flat colour: a screenshot of a text editor is largely repeated background, and PNG compresses it enormously.

JPG is lossy. It transforms the image into frequency components and discards the high-frequency detail the human eye is least sensitive to. It exploits the fact that we notice brightness far more than colour, so it stores colour at lower resolution. On a photograph — continuous tone, no exact repetition — this achieves compression PNG cannot approach, at no visible cost.

Each is close to worst-case for the other's content. A photograph in PNG has almost no exact repetition to exploit and comes out five to ten times larger than necessary. A screenshot in JPG is nothing but the sharp high-frequency edges JPG discards, so text acquires visible halos and smearing.

The decision

• Screenshots, UI, logos, icons, diagrams, anything containing text — PNG or lossless WebP. Sharp edges must stay sharp.
• Photographs and continuous-tone images — JPG or lossy WebP, quality 80 to 85.
• Anything needing transparency — PNG or WebP. JPG has no alpha channel at all.
• Line art, flat illustrations, and icons that need to scale — SVG, if you have the vector source. It is resolution-independent and usually smaller.
• Animation — a video format. Animated GIF is enormous compared to an equivalent MP4 or WebM, often by a factor of ten.

What WebP actually gives you

WebP does both modes — lossy and lossless — and supports transparency in either, which JPG cannot do at all. It is typically 25 to 35% smaller than an equivalent JPG at matched visual quality, and around 25% smaller than PNG for lossless content.

Browser support is universal among current browsers, including Safari since 14. The remaining reason to hesitate is not browsers but everything else: some desktop applications, older email clients, and internal tooling still do not accept it. For images on a web page, WebP is the sensible default; for a file someone will download and open in an unknown application, PNG or JPG remains safer.

Quality settings

The quality number is not a percentage of anything meaningful — it is a knob controlling how aggressively detail is discarded, and the relationship between it and file size is steeply non-linear.

• 95 to 100 — near-lossless and very large. The last few points cost a great deal of size for a difference nobody can see.
• 80 to 85 — the practical sweet spot. Visually indistinguishable from the original for most photographs, at a fraction of the size.
• 60 to 75 — acceptable for thumbnails and images that are never viewed large.
• Below 60 — visible artefacts: blocking in smooth gradients, ringing around edges.

Generation loss

Lossy compression is not idempotent. Decoding a JPG and re-encoding it discards more information, even at quality 100, because the transform and quantisation steps do not round-trip exactly.

In practice this means every save of a JPG is a small permanent degradation, and a file that has been through several rounds of edit-and-save is visibly worse than the original with no single step to blame. The rule that follows: always convert from the highest-quality original you have, never from a previously compressed copy. If a source is available as PNG or raw, start there.

Transparency becomes white

JPG has no alpha channel, so converting a transparent image to JPG requires compositing it onto some background — conventionally white. This is where the white box behind a logo on a dark page comes from.

There is no way around it within the format. If transparency matters, the output has to be PNG or WebP.

Metadata, and a privacy note

Photographs carry EXIF metadata: camera model, exposure settings, timestamp, and often exact GPS coordinates. Publishing a photo straight from a phone can disclose precisely where it was taken, which is a real and frequently overlooked privacy problem.

Conversion through a canvas — which is how browser-based converters work — discards all of it as a side effect. That is a privacy win by default, and a loss if you are cataloguing photographs, so keep originals if the capture data matters.

EXIF also carries an orientation flag. An image that displays upright in one viewer because of that flag may appear rotated after conversion, since the stored pixels were never rotated — only the flag said so.

Serving the right one

On the web you do not have to choose a single format. The picture element lets the browser pick the first source it supports, so modern browsers get WebP and everything else falls back.

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

Two details in that snippet matter beyond format. Always set width and height — without them the browser cannot reserve space and the page shifts as images load, which is the largest contributor to a poor layout-shift score. And write a real alt attribute: it is what screen readers announce and what is shown when the image fails.