Cool Easy

← All articles

How to compress images for a website without losing quality

The difference between a 2MB image and a 120KB image can be invisible to the eye and several seconds of page load time. Here's how to get there without a desktop app.

20 May 2026 · 3 min read

Why image size matters more than most people think

Images are almost always the largest assets on a webpage — larger than HTML, CSS, and JavaScript combined for most content sites. A page with five unoptimised photographs might total 8–10MB of image data. The same page with properly optimised images might total 400KB.

That difference is seconds of load time on a typical connection, and it compounds: slower pages rank lower in search results, have higher bounce rates, and create a worse experience on mobile. Image optimisation is one of the highest-return performance improvements available, and it's largely a one-time setup cost.

The good news is that most of the gain comes from three straightforward steps.

The system

Step 1: Resize to the actual display dimensions

Before touching quality settings or format, check whether your image is larger than it will be displayed. A product image on a page where it appears at 600px wide doesn't need to be 3000px wide. A blog post hero image at 1200px display width doesn't need to be a 5000px camera export.

Open Toolbelt in the side panel and use the Image Resize tool. Drop in the image, set the width to the display width (add 2x for Retina/HiDPI: if the display width is 600px, export at 1200px). Download the resized version.

This step alone often reduces file size by 50–80% before any quality compression.

Step 2: Convert to WebP

Unless you're targeting legacy browsers (IE, very old Safari), WebP should be your default format. At equivalent visual quality, WebP files are typically 25–35% smaller than JPEG and 25–50% smaller than PNG.

In Toolbelt, when you resize or convert an image, select WebP as the output format. Set quality to 80. This one change — JPEG to WebP at 80 quality — typically produces files that look identical on screen and are significantly smaller.

For images that require transparency (logos, UI elements with transparent backgrounds), WebP supports alpha channel, so you can switch from PNG to WebP without losing transparency support.

Step 3: Fine-tune quality for the right trade-off

For images where file size is critical (e-commerce thumbnails, image-heavy galleries, mobile-first pages), step the quality down to 75 and compare visually with the original. For most photographic content, the difference is invisible.

A practical test: open both the original and the compressed version in separate tabs and switch between them while looking at the same region. If you can't identify which is which, the compressed version is good enough.

For hero images and large feature images where quality is more visible, 82–85 is a safer quality floor.

Step 4: Repeat for each image format variant

If you're serving images to a mix of browsers (or using a CMS that expects JPEG), you may need both a WebP version and a JPEG fallback. The HTML <picture> element handles this:

<picture>
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Description">
</picture>

Modern browsers use the WebP source; older browsers fall back to JPEG. Most modern static site generators and CMSs handle this automatically if you provide both formats.

Common mistakes

Compressing without resizing first. Compressing a 3000px image to 80 quality and then serving it at 600px display width still wastes data. Resize first, then compress.

Setting quality too low for hero images. At 70 quality, compression artefacts are visible on large display images — blocky areas, blurring around edges. Quality below 80 is appropriate for thumbnails and small images; use 82–85 for anything large.

Ignoring PNG files for photos. PNG uses lossless compression and is appropriate for graphics, screenshots, and images with transparency. It's the wrong format for photographs — a JPEG or WebP at 80 quality will be a fraction of the size with no visible difference.

Optimising once and forgetting. If new images get added to the site without going through the optimisation workflow, the problem returns. For sites that update frequently, build the optimisation step into the publishing workflow (many CMS plugins handle this automatically).

FAQ

What's the best format for web images?

For photographs and complex images with many colours, WebP is the best choice — it produces smaller files than JPEG at equivalent quality and is supported by all modern browsers. For images that need transparency, WebP also beats PNG in file size. For simple graphics, icons, or images with flat colors and sharp edges, SVG (if vector) or PNG (if raster) are appropriate. JPEG is a reasonable fallback for browsers that don't support WebP, though that's rare now.

How do I know what quality setting to use?

80–85 is a reliable starting point for most photographs. The degradation below 85 is usually visible only on close inspection or on high-resolution displays. Below 70, compression artefacts become noticeable. Above 90, file size grows rapidly with minimal perceptible quality gain. Export at 80 and compare with the original at 100% zoom — if you can't see a difference, 80 is correct.

What does "resize to display size" mean in practice?

If your website shows a thumbnail at 400px wide, the image file only needs to be 400px wide (or 800px for 2x/Retina displays). Serving a 3000px source image that gets scaled down to 400px by the browser wastes data — the browser downloads all 3000px and then discards most of them. Match the image file dimensions to the display dimensions.

Should I use lazy loading instead of compressing?

Both. Lazy loading defers loading offscreen images until the user scrolls to them — this reduces initial page load time. Compression reduces the size of each image when it does load. They address different parts of the performance problem and should both be implemented.