How to Reduce Image Size for a Website Without Losing Quality

Most advice on this subject starts with the quality slider. That is the third decision, and it is the least important of the three.

Work through them in the right order — dimensions, then format, then quality — and an 80% reduction with no visible difference is an ordinary result rather than an ambitious one.

Understanding what makes a file large#

File size is driven by three things: how many pixels there are, how many bits each pixel needs, and how much redundancy the encoder can find.

An uncompressed 4000×3000 photograph contains 12 million pixels at 3 bytes each — about 36 MB. Every compression scheme is a strategy for getting that down. Reducing dimensions attacks the first factor directly and is by far the bluntest, most effective instrument available.

This is worth internalising: halving the width and height quarters the pixel count. Not halves — quarters. Nothing in the quality slider comes close to that leverage.

Step 1: Resize to the size it will actually be displayed#

This is the step people skip, and it is where most of the waste lives.

A photograph exported straight from a phone is somewhere between 3000 and 4500 pixels wide. Displayed in an article whose text column is 700 pixels wide, more than 95% of that pixel data is discarded by the browser after being downloaded over the visitor's connection.

The rule: export at roughly twice the display width, to stay sharp on high-density displays, and no more.

Beyond twice, the returns vanish. The difference between a 2× and a 3× image on a modern phone screen is not something people can see; the difference in file size is.

Reducing dimensions is not "losing quality" in any way that matters, provided you are removing pixels that would never have been shown. Enlarging is the destructive operation — those pixels have to be invented, and no algorithm invents detail that was not captured.

Step 2: Choose the right format#

Covered in depth in JPG vs PNG vs WebP vs AVIF, but the short version:

• Photographs → WebP. Typically 25–35% smaller than JPEG at the same visual quality, and supported by every current browser.
• Logos, icons, diagrams → SVG if it is vector, otherwise PNG or lossless WebP.
• Screenshots with text → PNG or lossless WebP. Lossy compression turns small text to mush.
• Anything needing transparency → WebP or PNG. JPEG has no alpha channel.
• Email or print → JPEG. WebP support outside browsers is still unreliable.

The single most common and most expensive format error is saving a photograph as PNG. It can be five to ten times larger than necessary with no visible benefit, because PNG's lossless compression has nothing to exploit in a photograph.

Step 3: Set the quality by looking#

Now the slider.

For photographs, start at 78 and compare against the original at the size it will actually be displayed — not zoomed to 200% in an image editor, where you will find flaws nobody will ever see.

What breaks first, as quality drops:

• Smooth gradients. Skies, out-of-focus backgrounds, studio backdrops. Banding and blotchy patches appear here before anywhere else.
• Skin tones. Faces are what people look at, and subtle mottling on a cheek is noticeable in a way that the same artefact on a brick wall is not.
• Sharp edges against flat colour. Text, logos, product edges. Coloured fringing appears.
• Fine repeating texture. Fabric weave, hair, foliage. Turns to smear.

What hides compression well: busy natural texture, high contrast, motion blur, grain.

Because of this, there is no single correct number. A landscape full of foliage might be indistinguishable at quality 65. A studio portrait against a smooth grey background might band at 80. Compare, do not assume.

Step 4: Serve the right size to each device#

Everything so far produces one good file. Responsive images let the browser choose among several.

<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w,
          photo-800.webp 800w,
          photo-1200.webp 1200w,
          photo-1600.webp 1600w"
  sizes="(max-width: 700px) 100vw, 700px"
  width="1200"
  height="800"
  alt="A description of what is in the photograph"
>

The srcset lists the available files with their actual pixel widths. The sizes attribute tells the browser how wide the image will be displayed. The browser combines those with the device's pixel density and picks the smallest adequate file — before layout, before any JavaScript runs.

The effect is significant: a phone downloads the 400-pixel file while a desktop gets the 1600-pixel one, from the same markup.

Most site builders and frameworks generate this automatically. If yours does, do not fight it.

Step 5: The attributes that cost nothing#

Always set width and height. These let the browser reserve the correct space before the image loads, which prevents the content below from jumping when it arrives. That jump is Cumulative Layout Shift, and it is one of Google's Core Web Vitals. Set the intrinsic pixel dimensions; CSS can still resize it.

Use loading="lazy" below the fold. The browser defers fetching until the image is close to the viewport. On a long page with twenty images, this is a large saving.

Never lazy-load your largest above-the-fold image. Deferring it directly delays Largest Contentful Paint — the exact metric you are trying to improve. For that one image, use fetchpriority="high" instead.

Write real alt text. Not for file size, but because it is what a screen reader announces and what search engines read. Describe what the image shows and why it is there. "Chart showing image weight falling from 2.1 MB to 180 KB after conversion to WebP" beats "chart".

Step 6: Measure#

Guessing is optional; measuring is not.

• Your browser's network panel. Reload with the cache disabled and sort by size. The offenders are immediately obvious.
• PageSpeed Insights. Reports Core Web Vitals and names specific oversized images.
• WebPageTest. Waterfall view showing exactly what delayed the largest paint.

One caution: test on a throttled connection. On desktop broadband, a 2 MB hero looks instant. On a mid-range phone over a typical mobile connection, it is several seconds of blank space.

A worked example#

A client sends a hero photograph straight from a camera:

From 8.4 MB to 41 KB on the device where it matters most — a reduction of over 99% — with no visible difference at the size anyone actually sees it.

Note where the leverage was. The resize did most of the work; the format change did most of the rest; the quality setting was a refinement.

Common mistakes#

Uploading straight from the camera. The single most common cause of a slow site.

Compressing before resizing. Wasted effort — resize first, then compress the smaller image once.

Using the same image everywhere. One file serving a hero, a thumbnail and an avatar means two of those three are enormously oversized.

Enlarging small images. Detail that was not captured cannot be recovered. Find a bigger source.

Compressing the same file repeatedly. Each lossy save degrades the image further. Keep originals somewhere and always export from them.

Optimising images while ignoring everything else. If your page also loads 900 KB of JavaScript, a perfectly optimised image is not the bottleneck.

---

Our free image compressor does the resize and the format conversion in one pass, shows the before-and-after size for each file, and runs entirely in your browser — nothing is uploaded.

Related: JPG vs PNG vs WebP vs AVIF, why image optimisation is crucial for Core Web Vitals, and compressing JPEGs for email.