How to Compress Images Without Wrecking Them

Your images are probably the heaviest thing on your page

Open the developer tools on almost any website, sort the network tab by size, and the same picture appears: a handful of images accounting for more bytes than every script, stylesheet, and font on the page combined. It is the most common performance problem on the web, and it is also the easiest one to fix — which makes it strange how often it goes unfixed.

Part of the reason is that "compress your images" is advice that stops exactly where the useful part begins. Compress them how much? With what settings? At what point does the file get small enough that people notice? This article answers those questions concretely, so you can make the decision yourself instead of trusting a slider.

Two kinds of compression, and why the difference matters

Lossless compression rewrites the file so it takes fewer bytes to describe exactly the same pixels. Decompress it and you get back the original, bit for bit. PNG works this way. So does ZIP. The catch is that lossless compression can only exploit redundancy that is actually there — a photograph of a forest has very little exact repetition, so lossless barely helps.

Lossy compression throws information away and keeps what your eye is bad at noticing. JPEG is the classic example. It works because human vision is far more sensitive to changes in brightness than to changes in colour, and far more sensitive to large shapes than to fine texture. A JPEG encoder discards colour detail and high-frequency texture first, because those are the things you are least likely to miss.

This is why the same "quality 70" setting can be invisible on one image and obviously wrong on another. The encoder is making a bet about what you will not notice, and some images make that bet much harder.

Where the quality slider actually breaks

If you compress a photograph and step the quality down, the degradation is not linear. In broad terms:

• 100–90: Enormous files, no visible benefit over 85. This range is mostly wasted bytes.
• 85–75: The sweet spot for photographs. Most people cannot pick the compressed version out of a lineup on a normal screen.
• 75–60: Still fine for most web use. You may start to see softness in fine texture — hair, foliage, fabric weave.
• 60–40: Artefacts become findable if you look. Smooth gradients start to show banding, and hard edges pick up faint halos.
• Below 40: Visible blocking. Only useful for thumbnails displayed very small.

The important word in all of that is photograph. The ranges shift dramatically for other kinds of image, which is the single most common mistake people make.

Screenshots, diagrams, and text are a different problem entirely

JPEG is built around the assumption that the image is made of gradual tonal transitions. A screenshot violates that assumption on every line of text. Text is nothing but hard edges — exactly the high-frequency detail JPEG discards first. Compress a screenshot as JPEG at quality 70 and the letters develop a smeared, muddy fringe that looks like the image has been photographed through a dirty window.

For anything with sharp edges and flat colour — screenshots, UI mockups, logos, charts, line drawings, pixel art — use PNG or WebP in lossless mode. Because those images genuinely do contain large areas of identical pixels, lossless compression works extremely well on them. A 1600-pixel-wide screenshot of a code editor can often be a smaller PNG than it would be a decent-quality JPEG, and it will be perfectly sharp.

The rule that covers ninety percent of cases: if it came out of a camera, use lossy. If it came out of a screen, use lossless.

The formats, briefly and honestly

JPEG is thirty years old, universally supported, and still perfectly good at the job it was designed for. It has no transparency. If your image is a photograph and you want zero compatibility risk, JPEG at quality 78 is a defensible default that nobody will ever complain about.

PNG is lossless and supports transparency, including partial transparency for soft edges. It is the right choice for logos, icons, and anything that has to sit on an unknown background. It is the wrong choice for photographs, where it routinely produces files five to ten times larger than an equivalent JPEG.

WebP does both. Lossy WebP typically produces files around 25–35% smaller than JPEG at visually comparable quality, and lossless WebP typically beats PNG by around 20%. It supports transparency in both modes, which JPEG cannot do at all. Support is now universal across current browsers, and has been for years.

AVIF compresses harder still, often 20% or more below WebP, and handles gradients and flat colour noticeably better — banding in skies and sunsets is much less of a problem. The trade-off is encoding time, which can be an order of magnitude slower, and slightly less mature tooling.

For most sites today, converting photographs to WebP is the single highest-return change available. It is a genuine reduction with no visible cost and no compatibility caveat worth worrying about. If you want to try it, our Image Converter handles JPEG, PNG, and WebP conversion directly in your browser, and the Smart Image Compressor lets you set the quality level and see the result before you commit to it.

Resize before you compress

This is the step people skip, and it matters more than the quality setting.

A modern phone camera produces images around 4000 pixels wide. A blog post's content column is rarely wider than 800 CSS pixels. Even accounting for high-density displays, you need perhaps 1600 pixels. Uploading the original means the browser downloads roughly six times more pixel data than it can possibly display, then throws most of it away during rendering.

Because file size scales with area, halving the width and height quarters the pixel count. Going from 4000px wide to 1600px wide removes about 84% of the pixels before compression even starts. No quality setting can compete with that, and unlike aggressive compression, downscaling to the size you actually display costs you nothing visible at all.

Practical targets:

• Full-width hero images: 1920px wide is plenty.
• In-article images: 1200–1600px.
• Thumbnails and cards: 600–800px.
• Avatars and icons: 200px, or use SVG.

How to judge the result, properly

Do not evaluate compression by looking at a thumbnail. Artefacts hide at small sizes and appear the moment someone opens the image full-screen or views it on a large monitor.

Instead, open the compressed version at 100% zoom and look specifically at the places where compression fails first:

1. Smooth gradients — skies, studio backdrops, soft shadows. These show banding: what should be a continuous fade becomes visible stripes.
2. High-contrast edges — dark text on light background, a roofline against sky. These show ringing: a faint ghost halo tracing the edge.
3. Fine repeating texture — grass, hair, knitted fabric, gravel. These go mushy, losing definition and turning into a vague smear.
4. Large flat areas — a plain wall, a solid background. These show blocking: faint 8×8 pixel squares, the tell-tale signature of JPEG pushed too far.

If those four areas look clean at 100%, the compression is fine. If they do not, step the quality up by ten and look again. This takes about thirty seconds per image and is far more reliable than guessing.

A workflow that takes two minutes

1. Decide what the image actually is. Photograph, or screen content?
2. Resize to the largest size you will genuinely display, roughly doubled for high-density screens.
3. Photographs: export as WebP at quality 75–80, or JPEG at 78 if you want maximum compatibility.
4. Screenshots, logos, diagrams: export as lossless WebP or PNG.
5. Open the result at 100% and check the four failure areas above.
6. If the file is still large, resize further before lowering quality. Dimensions are almost always the cheaper saving.

One thing worth knowing about privacy

Most online image compressors upload your file to a server, process it there, and send it back. For a holiday snapshot that is unremarkable. For a screenshot containing customer data, an unreleased design, a signed contract, or an identity document, it means handing a copy to a third party whose retention policy you have not read.

Compression does not actually require a server. Browsers have had the necessary image decoding and encoding built in for years, so the work can happen entirely on your own machine — the file never leaves it, and there is nothing to delete afterwards because nothing was ever uploaded. Every image tool on AeroTools works this way, which is also why they keep working when your connection drops mid-task.

It is worth checking, whatever tool you use. The difference does not show up in the output file, only in where your original went.