Every image on a web page is a format decision, and most of them are made by accident: whatever the camera saved, whatever the screenshot tool produced, whatever the designer happened to export. The accident is usually an expensive one, because images tend to be most of what a page weighs.
Four formats cover nearly everything on the web. UltraCompress Pro, one of the tools on my projects page, works with all four, plus HEIF. Here is what each is good at, what each is bad at, and how to choose without reading a specification.
JPEG: the one everything opens
JPEG has been the default for photographs since the early 1990s, and every browser, phone, email client and photo printer still accepts it without question.
Good at: photographs, soft gradients and natural texture. It throws away detail the eye is bad at noticing, and at sensible quality settings you will not miss it.
Bad at: sharp edges. Text and screenshots come out with smudgy halos around every letter. It has no transparency. And each time a JPEG is edited and saved again it loses a little more, so keep the original and export from that.
PNG: exact, and heavy
PNG is lossless: the pixels you save are the pixels you get back. It supports full transparency, soft edges and shadows included.
Good at: screenshots, diagrams, charts, logos with flat colour, anything with text in it.
Bad at: photographs. A photo saved as PNG faithfully keeps every speck of sensor noise, and the file can easily be several times the size of a good JPEG with no visible gain.
WebP: the sensible default
WebP has a lossy mode for photographs, a lossless mode for graphics, and transparency in either. Every current major browser has displayed it for years.
Good at: being a better JPEG and a better PNG at once. Lossy WebP is usually noticeably smaller than a JPEG of similar quality, and lossless WebP usually beats PNG. If you can only produce one modern format, produce this one.
Bad at: life outside the browser. Some desktop software and upload forms still refuse it. Its lossy mode also stores colour at reduced resolution, so thin coloured detail, such as red text over a photo, can bleed.
AVIF: the smallest, at a price
AVIF is built on the AV1 video codec, and as a rule it is the smallest of the four at the same visual quality, especially when you compress hard. It handles transparency, high dynamic range and wide colour.
Good at: photographs and large header images where every kilobyte counts.
Bad at: speed, because encoding is far slower than for the other three. At aggressive settings it smooths away fine texture, so skin and fabric can turn waxy. And older browsers cannot show it at all, which is why it should always arrive with a fallback.
HEIF, which many phones save photos in (often as .heic files), is good for keeping photos, but most browsers will not display it. Convert from it; do not publish it.
Choosing, without the lecture
- A photograph on a web page: AVIF first, WebP as the fallback, JPEG as the last resort, all in one picture element (below). If you can only make one file, make it WebP.
- A screenshot, diagram or anything with text: PNG, or lossless WebP if you want it smaller. Never JPEG.
- A logo or icon: if you have it as a vector, use SVG and ignore this list. Otherwise PNG or lossless WebP.
- A file someone will edit, print or attach to an email: JPEG for photos, PNG for anything with text. Both open everywhere.
Serving all three at once
You do not have to pick one modern format and abandon older devices. The picture element lets each browser choose:
<picture>
<source srcset="harbour.avif" type="image/avif">
<source srcset="harbour.webp" type="image/webp">
<img src="harbour.jpg" alt="Fishing boats in a harbour at dusk"
width="1200" height="800" loading="lazy">
</picture>The browser takes the first source whose type it understands and downloads only that file; a browser that knows neither falls through to the img, which carries the alt text and dimensions for all of them. Width and height let the page reserve space before the image arrives, so the text does not jump. Keep loading="lazy" for images further down: the main image at the top should load straight away.
Compression that stays on your machine
The usual way to compress an image online is to upload it to someone's server and download the smaller result. It works, and it leaves a copy of your file on a machine you do not control, for as long as their policy says. For holiday photos that may not matter. For a scanned identity document or a balance sheet exported as an image, it does.
UltraCompress Pro takes the other route. The compression runs in your browser using WebAssembly, which lets serious encoding code run inside a web page at a usable speed, so the image does not have to travel to anybody's server to get smaller. It is a progressive web app, so it still works with the network off, and brightness, contrast and saturation are adjusted on the Canvas API before compression rather than in a second tool.
A small file is a poor bargain if getting it meant handing the original to a stranger.
It also handles EXIF metadata, which deserves more attention than it gets. A photo straight from a phone can carry the camera model, the moment it was taken and sometimes the exact location. Whatever tool you use, check what it does with that before you publish a picture taken at home.
