The page is slow. You open the network tab expecting a heavy JavaScript bundle, and instead you find the culprit sitting quietly at the top: the homepage banner. A photo. Saved as a PNG. At 4000 pixels wide. Being shown in a box 1200 pixels wide, or 400 on a phone.

Images are usually the heaviest thing on a web page, and the easiest to fix, once you understand what the formats actually do. Each one makes different trade-offs, and choosing well is less about memorising rules and more about knowing what kind of picture you have.

Two ways to shrink a picture

Every image format compresses, but in one of two ways:

• Lossless compression is like zipping a file. Unzip it and you get back exactly the same pixels. It works by finding patterns and repetition, so it's brilliant for flat colours and sharp edges, and poor for photos, where almost no two neighbouring pixels are identical.
• Lossy compression throws information away, carefully. It removes detail your eyes are unlikely to notice. The result is much smaller files, at the cost of some quality you choose with a quality setting.

The whole game is matching the method to the content: lossy for photos, lossless for screenshots, logos and anything with text.

The formats, one by one

JPEG: the old reliable for photos

JPEG splits the image into small 8×8 pixel blocks and describes each block as a mix of smooth patterns, keeping the strong patterns and discarding the fine ones. It also stores colour at lower resolution than brightness, because our eyes are far more sensitive to brightness detail.

That's why JPEG is great for photos and terrible for text and sharp lines: you get blurry "ringing" around edges and visible blocks at low quality. It has no transparency, and every re-save loses a bit more quality, so always edit from the original, not from the last JPEG.

PNG: lossless and transparent

PNG is lossless and supports a full alpha channel, so edges can fade smoothly into any background. It's the right choice for screenshots, diagrams, UI elements and images with text. For photos, it's the wrong tool: the files come out many times larger than a JPEG that looks the same.

WebP: the all-rounder

WebP, developed by Google, does both: a lossy mode for photos and a lossless mode for graphics, with transparency and animation in either. Lossy WebP is generally smaller than a JPEG of similar visual quality, and lossless WebP is generally smaller than PNG. Every modern browser supports it, which makes it a safe default today.

AVIF: the newest, and the smallest

AVIF stores a still image using the AV1 video codec's compression. It usually beats WebP at the same visual quality, especially at low file sizes, and supports transparency, HDR and wide colour. The trade-offs: encoding is noticeably slower and more CPU-hungry, and some older devices and browsers still don't support it, so you serve it with a fallback.

And the honourable mentions

SVG isn't pixels at all, it's a description of shapes. For logos and icons it's unbeatable: tiny, and sharp at any size. GIF is limited to 256 colours and usually produces huge files for animation; a short muted video or an animated WebP is almost always better.

The bigger win is usually size, not format

Here's the part people skip. Switching a JPEG to WebP helps. Not sending a 4000-pixel image to a 400-pixel screen helps far more. Pixel count grows with the square of the width, so an image twice as wide as needed carries roughly four times the pixels.

The browser can pick the right size for you, and the right format, if you offer the options:

<picture>
  <source type="image/avif" srcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w" sizes="100vw">
  <source type="image/webp" srcset="/img/hero-800.webp 800w, /img/hero-1600.webp 1600w" sizes="100vw">
  <img src="/img/hero-1600.jpg" alt="Lobby of the new building"
       width="1600" height="800" fetchpriority="high">
</picture>

The browser uses the first format it supports and the smallest file that fits the screen. Two details matter here. The width and height attributes let the browser reserve space before the image loads, so the page doesn't jump around. And use loading="lazy" for images further down the page, but not for the main image at the top; lazy-loading that one makes the most important content arrive later.

Converting uploads on the server

For user uploads (property photos, profile pictures, product images), convert and resize once on upload, ideally in a queued job. PHP's GD extension can write both modern formats:

$image = imagecreatefromjpeg($originalPath);
$image = imagescale($image, 1600);  // width 1600, height keeps the ratio

imagewebp($image, $webpPath, 80);   // quality 0-100
imageavif($image, $avifPath, 60);   // PHP 8.1+, needs GD built with AVIF support

This is simplified, but it shows a useful side effect: re-encoding drops the original's metadata. Photos from phones often carry EXIF data including GPS location, which you rarely want to publish. The catch is that EXIF also stores the photo's orientation, so read it and rotate the image before re-encoding, or some phone photos will appear sideways. Libraries like Intervention Image handle these details for you.

The cheat sheet

• Lossy for photos, lossless for sharp edges and text.
• WebP is the safe modern default; AVIF is smaller but slower to encode, so serve it with a fallback.
• Never serve a PNG photo or a JPEG screenshot.
• Resize to display size and use srcset. That's usually the biggest saving.
• Set width and height, lazy-load below the fold, not the hero.
• Strip metadata from uploads, but respect orientation first.

What's the heaviest image you've found hiding on a production page? I suspect most of us have a PNG photo somewhere we'd rather not talk about.