The Complete Guide to Image Compression

Most pages are heavy for one reason: the images were never touched between the camera and the CMS. A phone photo is a 4000-pixel-wide, four-megabyte file designed to survive cropping and printing, and dropping it straight into an 800-pixel content column ships roughly twenty times more data than the layout can use. Image compression is the set of techniques that closes that gap — and, done properly, it does so without anyone noticing a difference.

This guide covers the technique side: what a quality slider actually changes, which levers shrink a file the most, how to pick settings you can defend, and how to run the whole process in the browser without uploading anything. Format selection is a related but separate question — if you're still deciding between WebP, PNG, JPEG, SVG and AVIF, our complete guide to web image formats handles that in depth. Here we assume you've picked a format and want to get the bytes down.

What compression actually does to an image

An uncompressed bitmap stores a colour value for every pixel. A 1920×1080 image at 24 bits per pixel is about 6MB before anything clever happens. Every image format on the web exists to make that number smaller, and they do it in two fundamentally different ways.

Lossless compression finds redundancy and encodes it more efficiently — runs of identical pixels, repeated patterns, predictable gradients. Decode the file and you get back the exact original pixel values, bit for bit. PNG works this way, as does WebP in its lossless mode.

Lossy compression goes further by throwing information away. JPEG, lossy WebP and AVIF all transform the image into frequency components and then discard the ones human vision is least sensitive to — fine chroma detail, subtle high-frequency texture. The result cannot be reversed, but because the discarding is guided by perceptual models, a well-tuned lossy file can be five to ten times smaller than lossless while looking essentially identical.

That distinction drives nearly every decision that follows, and it's worth understanding properly before you touch a slider. We break it down with examples in lossy vs lossless compression explained.

The four levers that shrink a file

Compression conversations usually collapse into "move the quality slider", but that's only one of four controls, and it's rarely the most powerful.

Lever 1: pixel dimensions

This is the big one, and it's the one people skip. File size scales roughly with pixel count, so halving both width and height cuts the pixel count to a quarter. Going from 4000×3000 to 1600×1200 removes 84% of the pixels before a single compression setting is applied.

The right target is dictated by your layout, not by the source. Work out the widest the image will ever be rendered — a full-bleed hero might be 1920px, a content-column image 800px, a card thumbnail 400px — and multiply by two if you want it to stay crisp on high-density displays. Then resize to that number. Our image resizer does the arithmetic and the re-render together, with aspect-ratio locking so you don't distort anything, and you can pick the output format at the same time.

If you're unsure what dimensions to target, best image sizes for websites and social media collects the conventions worth following.

Lever 2: the quality setting

Quality in JPEG and lossy WebP is a 1–100 dial that controls how aggressively the encoder quantises frequency data. It is not a linear scale, and it is not comparable across formats — WebP at 75 and JPEG at 75 are different amounts of discarding.

What matters in practice is where the curve bends. File size falls steeply from 100 down to roughly 80 while visible quality barely moves; from 80 to 60 the size keeps falling and quality starts to soften; below 50 the artefacts become obvious — blocky edges, banded skies, haloes around text. For photographic content, most people land between 70 and 80. Flat graphics and screenshots behave differently: they show JPEG artefacts much earlier and belong in PNG or lossless WebP instead.

Lever 3: the format

The same picture encoded as PNG, JPEG and WebP can differ by an order of magnitude. A photograph as PNG is enormous, because lossless coding has almost no redundancy to exploit in natural imagery. A logo as JPEG is both larger and worse than the PNG, because sharp edges are exactly what lossy encoders handle badly.

Switching a photographic PNG to JPEG or WebP is often the single biggest win available, and it costs nothing visually. Our image converter does genuine canvas re-encoding — you get a real PNG, JPEG, WebP or SVG-wrapped file to download, with a quality slider for the lossy targets and a live before/after size readout, not an estimate.

Lever 4: metadata and structural extras

Camera files carry EXIF blocks, GPS coordinates, colour profiles and sometimes an embedded preview thumbnail. On a small image this baggage can be a meaningful share of the file, and none of it affects how the picture renders in a browser. Re-encoding an image through a canvas — which is what browser-based tools do — drops this metadata as a side effect, which is usually what you want for web images and a genuine privacy improvement when the file has location data in it.

What the encoder is doing under the hood

A little intuition about the mechanism makes the settings far less mysterious.

A lossy encoder starts by separating brightness from colour. Human vision has far more receptors for luminance detail than for chroma detail, so encoders exploit that immediately: chroma channels are typically stored at half resolution in each direction, discarding three quarters of the colour information before the quality slider even enters the picture. You don't notice, because your eyes were never resolving that detail. You do notice it on saturated red text against a dark background, which is one of the few cases where this step visibly hurts.

Next the image is cut into small blocks and each block is transformed into a set of frequency coefficients — one describing the block's average tone, the rest describing progressively finer variation within it. Quantisation then rounds those coefficients, aggressively for the fine detail and gently for the coarse. The quality setting is essentially the coarseness of that rounding. At high quality almost every coefficient survives; at low quality entire bands of fine detail round to zero, which is exactly why aggressive JPEGs look blocky — the blocks lose their internal variation and flatten into visible squares.

Lossless encoders take an entirely different route. They predict each pixel from its neighbours, store only the (usually small) prediction error, and then entropy-code the result. That's why PNG excels at flat colour and hard edges — where prediction is near-perfect — and struggles with photographic noise, where every pixel surprises the predictor and there is nothing to compress away.

Understanding this explains two rules that otherwise look arbitrary: screenshots and diagrams belong in a lossless format because the prediction step is extremely effective on them, and photographs belong in a lossy format because the perceptual discarding is the only thing that meaningfully shrinks them.

Picking a setting you can defend

Guessing a quality number and shipping it is how sites end up with either bloated or visibly degraded images. A better process takes about a minute:

1. Resize first. Get the dimensions right before touching quality, so you're tuning the file you'll actually ship.
2. Encode at two or three settings. Something like 85, 75 and 65 covers the useful range.
3. Compare at 100% zoom, not fit-to-screen. Downscaled previews hide exactly the artefacts you're checking for.
4. Look at the hard parts. Smooth gradients (skies, studio backdrops) reveal banding; high-contrast edges (text, branches against sky) reveal ringing; skin tones reveal chroma mush.
5. Take the lowest setting that survives that inspection, then stop.

The image compression and format size estimator shortens step two considerably: upload once and it re-encodes your actual image as PNG, JPEG and WebP at your chosen quality simultaneously, reporting the real byte size of each. Because it's encoding rather than estimating from a formula, the numbers are the numbers you'll ship.

Compressing in bulk, and compressing to a target

Two workflows come up constantly and deserve dedicated handling.

Batch compression. Twenty product photos with one setting applied to all of them, downloaded in one pass. Our image compressor takes up to 20 images at once, shows a before/after thumbnail and percentage saved for each, and gives you a combined total so you can see the whole batch's weight drop as you move the slider.

Compressing to a target size. Sometimes the constraint is external: an upload form caps attachments at 100KB, or a marketplace demands under 2MB. Rather than nudging a slider and re-checking, the same tool has a target-size mode that binary-searches the quality value to land at or just under your number. For PNG — where quality is a no-op because the format is lossless — it downsamples dimensions instead, since that's the only lever that actually moves a PNG's size.

Both modes run entirely in your browser. The images are decoded, drawn to a canvas and re-encoded locally; nothing is transmitted to a server at any point, which matters when the files are client work, medical scans, ID documents or anything else you'd rather not hand to a third party.

DPI, print resolution and other red herrings

A persistent myth holds that web images should be "72 DPI" and print images "300 DPI", and that changing this setting changes the file. It doesn't.

DPI (dots per inch) and PPI (pixels per inch) are metadata describing physical output size. A 3000×2000 image tagged 300 DPI is intended to print at 10×6.7 inches; the same file tagged 150 DPI prints at 20×13.3 inches. The pixels are identical either way, the file size is identical either way, and browsers ignore the tag completely. When someone asks for a 300 DPI image, what they need is enough pixels for the physical size they're printing — 300 × the width in inches. Set the pixel dimensions and the DPI question resolves itself.

Similarly, "high resolution" on the web means pixel density relative to CSS layout size, not a metadata flag. Serving a 1600px-wide file into an 800px slot is what makes an image sharp on a Retina display. Beyond 2× there's no visible benefit and a real bandwidth cost.

Where compression pays off

The obvious payoff is bandwidth, but the one search engines care about is speed. A hero image is very often the largest element in the viewport, which makes it the element that defines Largest Contentful Paint — and LCP is a ranking-relevant Core Web Vital. Shaving a 2MB hero to 200KB can move that metric by seconds on a mobile connection. Why image weight wrecks your Core Web Vitals covers the mechanism, including the layout-shift problem that compression alone doesn't solve.

There's also a plain user-experience argument. Heavy pages cost real money on metered mobile data, drain battery through longer radio activity, and fail entirely on weak connections. None of that shows up in a desktop preview on office wifi.

Mistakes that quietly cost you

Compressing the same file repeatedly. Each lossy save compounds the damage. Keep a high-quality master and export from it every time.

Optimising the wrong images. A 30KB icon that's already efficient isn't where the wins are. Sort your assets by size and fix the top five; they usually account for most of the page weight.

Using PNG for photographs. It's the most common single mistake in image optimisation and often means a file five to ten times larger than it needs to be.

Ignoring the largest dimension. A perfectly tuned quality setting on a 4000px image still ships a 4000px image.

Treating "no visible loss" as "no loss". Lossy compression is permanent. It's the right trade-off for delivery, but never overwrite your archival originals with the compressed versions. If preserving the pixels exactly is a hard requirement, how to reduce image size without losing quality walks through what's genuinely achievable losslessly.

Conclusion

Image compression isn't a single slider — it's four levers applied in order. Get the pixel dimensions down to what your layout actually renders, pick a format that matches the content type, choose the lowest quality setting that survives inspection at full zoom, and let the encoder discard metadata you were never using. Done in that sequence, an oversized camera file routinely loses 80–90% of its weight while looking unchanged to every visitor.

The tools to do it are all client-side and free: resize to your target dimensions, compare formats and sizes on your real image, then compress the batch at a quality setting or straight to a byte target. Nothing you drop in ever leaves your browser — the encoding happens on your own machine, and the downloaded file is produced there too.