Optimize images for the Web without losing quality

A multi-megabyte image can be perfect for print and completely disproportionate for a web page. Optimization does not mean degrading an image until it becomes small. It means removing what the final display does not need: excessive dimensions, an unsuitable format, unnecessarily high quality or metadata that adds no value.

A practical order is: resize, choose the format, compress, inspect visually, then serve the right variant to the browser.

1. Start with dimensions

This is often the biggest win.

A 6000 × 4000 photo contains 24 million pixels. If the page never displays it wider than 1200 pixels, downloading and decoding the full-resolution source wastes resources.

Ask:

• what is the maximum displayed width?
• is there a mobile variant?
• do high-density screens matter?
• can the user open a full-size version?

An image displayed at 800 px wide rarely needs a 6000 px source.

2. Dimensions and file size are different things

Two 1600 × 900 images can have very different file sizes. Dimensions describe pixel count; file size also depends on format, image content and compression settings.

A detailed photograph compresses differently from a logo with a few flat colours. One preset for every image is rarely optimal.

3. Choose the format for the content

Content	Common choice	Reason
Photography	WebP, AVIF, JPEG	efficient lossy compression
UI screenshot	WebP or PNG	sharp edges and flat areas
Vector logo / icon	SVG	resolution-independent
Transparency	WebP, AVIF, PNG	alpha channel
Maximum compatibility	JPEG / PNG	long-established support

WebP is widely supported and handles lossy/lossless compression, transparency and animation. AVIF also offers strong compression and modern capabilities. JPEG and PNG remain useful as simple sources or fallbacks.

4. Lossy or lossless?

Lossless compression preserves the original pixel data exactly. Lossy compression discards information considered less perceptually important.

For web photography, sensible lossy compression can reduce file size dramatically without an obvious difference at normal display size.

The best setting is not “quality 100”. It is the lowest setting that still looks correct for the real use case.

5. Inspect at real display size

Do not judge a web image only at 400% zoom.

Check it:

1. at the size it will actually be displayed;
2. on a normal desktop screen;
3. in difficult areas such as hair, foliage, gradients, text and fine details;
4. on mobile when the asset is important.

If an additional 100 kB reduction is invisible in those conditions, it is likely useful. If it produces halos around text or destroys product details, it is not.

6. Resize before compression

A 4000 × 3000 source contains 12 million pixels. A target of 800 × 600 contains 480,000.

That is a 25× reduction in pixel count.

The final file size will not necessarily shrink by exactly 25×, but the potential gain is substantial. Compressing the giant source first and asking CSS to scale it down later optimizes the wrong file.

7. Create responsive variants when useful

A phone does not always need the same asset as a large desktop display. srcset, sizes and <picture> let the browser choose a suitable source and can also provide format fallbacks.

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

The principle is simple: do not make every visitor download the heaviest version.

8. Be careful with text and screenshots

Screenshots, diagrams and interface images can react badly to aggressive photographic compression. Letter edges and thin lines make artifacts obvious.

Try lossless modes or higher quality. When the graphic can be represented as SVG, vector output may be more appropriate.

9. Metadata

Photos may contain EXIF metadata: camera model, date, exposure settings and sometimes location information.

That can be valuable in a photographic workflow and useless on a public page. Removing unnecessary metadata may reduce file size slightly and avoid publishing information you did not intend to share.

Keep metadata that is genuinely required, especially colour information when removing it changes the appearance.

10. Measure the total page impact

Ten images at 900 kB each represent about 9 MB.

After resizing and optimization to an average of 180 kB:

10 × 180 kB = 1.8 MB

That is a 7.2 MB reduction from images alone.

On mobile networks, this difference can materially affect loading time and data usage.

11. Make the workflow repeatable

For one image, a standalone tool is enough. When the same process repeats—resize, convert, compress, optionally clean metadata—it is useful to formalize the sequence.

A common pipeline is:

import → resize → convert → compress → export

Order matters. Resizing after an initial lossy compression can lead to another unnecessary encoding step.

12. Checklist

Before publishing:

• dimensions match the display;
• format matches the content;
• compression has been checked visually;
• transparency is preserved where needed;
• text and fine details remain sharp;
• only useful metadata is kept;
• responsive variants exist where they provide real value;
• width and height are known so layout space can be reserved.

The best web image is not always the smallest possible file. It is the smallest file that still performs its visual and functional job correctly.