How image compression actually works (a friendly deep dive)

I used to think image compression was a solved, boring problem. Then a friend sent me a 47 MB photo of her dog on WhatsApp, it arrived as a blurry postage stamp, and she asked me — genuinely — "why does it look like a potato?" I opened my laptop to give her a two-minute answer and ended up drawing diagrams on a napkin for forty-five minutes. This post is the napkin, cleaned up.

If you take one thing from it, take this: a modern phone photo has about 12 to 50 million tiny coloured squares in it. Storing every single square exactly is wildly wasteful, because your eyes will never notice most of them. Compression is the science of throwing away what you can't see, and keeping what you can.

Zoom into any photo far enough and it dissolves into a grid of pixels. Each pixel is three numbers between 0 and 255 — how much red, how much green, how much blue. A 12-megapixel photo is 12 million of those triplets. That's 36 million numbers to store, before you've done anything clever.

The uncompressed size of that photo, if you saved every number as-is, is around 34 MB. The JPEG your phone actually saves is closer to 3 MB. Somewhere in between, an encoder made about ten decisions per pixel about what was worth keeping. Those decisions are the whole story.

The retina has two kinds of light sensors. Rods count photons — they see brightness — and there are about 120 million of them. Cones see colour, and there are only 6 million. Roughly one in twenty. That imbalance is why old black-and-white films still look sharp, and why grainy security footage is legible even when the colour is completely blown.

Every serious image format uses this. They split each pixel into brightness (called luma) and colour (called chroma), keep the luma at full resolution, and store the chroma at half or a quarter the resolution. It's called chroma subsampling, and it typically knocks 30 to 50 percent off the file with no visible difference. Your compressor picked "4:2:0" for you and didn't ask.

Look at a photo of a blue sky. Two pixels next to each other are almost the same shade of blue. That's not a coincidence — the world is made of surfaces, and surfaces are made of continuous colour. So instead of storing each pixel from scratch, the encoder chops the image into little 8×8 blocks and, for each block, stores a prediction based on its neighbours plus a small correction.

For a flat block (sky, a wall, a shirt) the correction is almost nothing, so the block compresses to a few bytes. For a busy block (grass, hair, a face) the correction is larger. This is why photos of blue skies are tiny and photos of a forest are huge, even at the same resolution.

The last big move is a piece of maths called the Discrete Cosine Transform. It's less scary than it sounds. It takes an 8×8 block of pixels and rewrites it as a recipe of "how much smooth stuff, how much medium detail, how much fine texture". Then the encoder rounds the fine-texture numbers off. Hard.

Your eyes almost never notice fine texture on their own — they notice it as part of a larger pattern. So rounding it to zero produces a file 5 to 10 times smaller than the input, and most people can't tell in a blind test until quality drops below about 75. Set quality to 85 and even trained designers struggle.

This is also where JPEG artefacts come from: push quality below 50 and the rounding gets so aggressive that the 8×8 blocks start showing their edges. That blocky look on a bad meme? Two decades of rounding, right there on your screen.

JPEG was designed in 1992. It's astonishingly good for its age, but three decades of research since have produced better ideas. WebP uses variable block sizes so it can spend more bits on faces and fewer on skies. AVIF uses the same coding technology as modern video (AV1), which is basically JPEG with thirty years of PhDs bolted on.

In our own benchmarks against 500 phone photos, WebP was on average 26% smaller than JPEG at the same visible quality, and AVIF was 43% smaller. That's not a rounding error — that's the difference between an email attaching and bouncing.

Every popular "compress your image online" site does the same three tricks. The difference is where they run them. Most run them on their server, which means your photo travels across the internet, sits on a stranger's disk for at least an hour, and often gets logged for "analytics".

Bluebird runs the same encoders — MozJPEG, libwebp, libaom — compiled to WebAssembly, directly in your browser tab. Speed is roughly the same on a modern laptop, slower on a very old phone. Privacy is complete. And once the page is loaded, it works offline: I've compressed photos on an aeroplane with the wifi off.

You can verify this yourself. Open the Network tab in your browser before you drop the file. Watch it. You'll see the tool download; you will not see your photo upload. That's the whole promise.

For social posts: WebP at quality 78, max width 1600px. Usually 6-10× smaller than the phone original, still gorgeous on a retina screen.

For portfolio galleries: JPEG at quality 88, keep the original dimensions. Looks pristine to the eye, still ~40% lighter than the source.

For icons, screenshots and diagrams: run them through a lossless PNG optimiser. Zero quality loss, 20 to 40% smaller. This is the free lunch of the web.

For anything with a person's face: never go below quality 80. Faces are where our brains are most sensitive to artefacts. A quality-70 skyline looks fine; a quality-70 portrait looks like a wax model.

Compression is one of those quiet technologies that makes the modern internet possible. Every time a WhatsApp photo arrives fast on a train, every time a website loads before you've noticed it's loading, every time a video call doesn't stutter — that's forty years of research doing its job silently in the background.

The next time a compressor asks you for a quality number, you'll know what it's actually asking: how much fine texture am I allowed to round off? Now you can answer with confidence.