How to Optimize Images for the Web: Resize, Compress, and Convert

On a typical content page, images account for the majority of transferred bytes — often more than the HTML, CSS, and JavaScript combined. A single unoptimised hero photograph straight from a phone can be 4–8 MB, which is more than many entire well-built pages. Because browsers must fetch and decode images before they can paint them, heavy images directly delay what the visitor sees first.

The realistic goal is not a specific number but a discipline: every image should arrive at roughly the dimensions it is displayed at, in a format suited to its content, at a quality level that survives its actual context. A 3,000-pixel-wide photograph displayed in a 800-pixel column is the most common waste on the web, and no amount of compression fixes the underlying problem — the browser is decoding four times more pixels than it shows.

PNG is lossless and supports transparency. Lossless means pixels come out exactly as they went in, which makes PNG the right choice for line art, screenshots, logos, diagrams, and anything with sharp edges or flat colour areas. The price is size: photographic content in PNG is routinely several times larger than the same photo in JPEG, because lossless compression cannot exploit the tolerances of human vision.

JPEG is lossy and photographic. It was designed around how humans perceive colour and brightness, so it achieves dramatic reductions on photographs with few visible artefacts at moderate quality settings. It has two structural limitations: no transparency (transparent areas must be flattened to a solid colour, usually white), and it is always lossy — every re-save recompresses, so repeatedly editing and re-saving a JPEG compounds artefacts over generations.

WebP is the modern default for the web. It supports both lossy and lossless modes, handles transparency, and typically produces files 25–35% smaller than equivalent JPEGs with comparable visual quality. Every current browser supports it, so the historical compatibility argument has largely evaporated. As a rule: photographs and complex imagery to WebP (or JPEG as a fallback), sharp-edged graphics and anything needing exact pixels to PNG, and convert legacy formats to one of these before publishing. Use the Format Converter to move files between these formats.

The order of operations matters more than most settings. Resizing reduces the pixel count — a 3,000×2,000 image displayed at 750×500 can be resized to a quarter of each dimension, cutting the decoded data to about 6% of the original. Compression, by contrast, only reduces how efficiently those pixels are stored. If you compress before resizing, you spend your quality budget on pixels the visitor will never see, then throw most of that work away when you resize.

So the workflow is: determine the largest size at which the image will actually be displayed (including retina displays — a common convention is to serve 2× the CSS width for sharp rendering on high-density screens), resize to that with the Image Resizer, and only then apply compression with the Image Compressor. If you maintain a responsive layout, generating a couple of widths and letting the browser choose via srcset is the thorough version of the same idea.

One caution: never upscale to meet a layout. Enlarging adds no detail — it interpolates between existing pixels — and it inflates the file for nothing. If a source image is too small for its slot, the honest fixes are a larger source or a smaller slot.

Quality is a dial from visually identical to visibly degraded, and the useful range is narrower than the numbers suggest. Around 90–95, artefacts are essentially undetectable for most content; 70–80 is the practical sweet spot where photographs remain clean and the size savings are substantial; below about 60, JPEG's characteristic blocking and ringing start to appear, especially along high-contrast edges.

The right question is "quality for what context?" A full-bleed hero image viewed at full attention deserves 85+. A thumbnail that renders at 200 pixels wide will never reveal the difference between 75 and 95, so take the savings. Text screenshots are the exception that punishes aggressive settings — artefacts cluster around letterforms, so keep those at 90+ or in PNG.

Grayscale is an underused lever. If the image is genuinely monochrome — a scanned document, a black-and-white photograph — encoding it as grayscale rather than RGB removes two-thirds of the colour information at a stroke, with no perceptual cost at all, because there was no colour to perceive.

Every photo from a phone or camera carries EXIF metadata: camera model, lens, exposure settings, timestamps, editing software, and — most significantly — GPS coordinates where the shot was taken. For web delivery this is pure waste: the browser never displays it, the file simply carries it. It is usually only a few kilobytes, but it is free to remove with the Metadata Remover.

The privacy side is the stronger argument. Publishing a photo with intact GPS EXIF discloses exactly where and when it was taken — a genuine concern for photos taken at home, at a child's school, or anywhere the location itself is sensitive. The safe habit is to strip metadata from every image before it leaves your control, and to treat stripping as a default step in the publish workflow rather than a decision made per image.

Take a 4032x3024 phone photograph that weighs 4.7 MB. It is destined for a hero slot displayed at 1600 CSS pixels, served at 2x for retina, so the largest useful dimension is 3200 pixels. Resizing to 3200x2400 (the Image Resizer) drops the decoded data to about 64% of the original pixels before any compression is applied — the file is now 3.0 MB at the original quality, because fewer pixels need encoding.

Converting that resized image to WebP at quality 78 (the Image Compressor and Format Converter) lands it at roughly 240 KB — under 6% of the original 4.7 MB, with no visible degradation at display size. The same image left as a JPEG at quality 78 would be about 320 KB; WebP saves another 25% for the same visual quality. Had you compressed first and resized second, you would have spent your quality budget on 12 million pixels the visitor never sees, then thrown most of that work away.

The decision framework for any image is three questions in order: what is the largest dimension it will be displayed at (including 2x for retina)? what format suits the content (WebP for photographs, PNG for sharp graphics)? and what quality does the context demand (85+ for heroes viewed at full attention, 70-80 for thumbnails)? Answering those three before touching a slider prevents the two most common wastes: serving far more pixels than the layout shows, and paying for quality no one perceives.

Batch consistency beats one-off heroics. The dependable pipeline for a set of images is: strip metadata, resize to the display size (or a small set of responsive widths), convert to a single format — WebP for photographs, PNG for graphics — and compress at a quality you have validated once by eye. Applying the same settings across a whole folder keeps pages visually consistent and makes the expected file sizes predictable.

Responsive delivery extends the same principle across devices. Rather than serving one image to every visitor, generate two or three widths and let the browser pick the smallest it can use through the srcset attribute on the img tag. A phone on a slow connection receives the small variant; a desktop on fibre receives the large one. The Image Resizer can produce the set of widths you need, and the Format Converter ensures they are all in an efficient format. The payoff is real: a phone downloading a 200 KB image instead of an 800 KB one loads the page faster and uses less of the visitor data plan, with no visible difference on a small screen.

Finally, verify in context. Open the page at the real display size and look at the images where they actually appear, not in an image viewer at 100% zoom. Compression artefacts that are invisible at display size are, for practical purposes, not there — and optimisation is exactly the art of stopping at that threshold rather than paying for quality no one will ever perceive.