A 4000×3000 photo straight off a phone can be 8 MB. The same picture, compressed, can look identical at 400 KB — a 20× reduction. That is not magic, and it is not just "lowering the quality" until things go blurry. Compression is a set of well-understood techniques for storing the same visual information in far fewer bytes. Understanding how they work makes it obvious why a photo and a logo need completely different treatment, and how to shrink a file without anyone noticing.
Two fundamentally different jobs
All compression falls into one of two camps, and mixing them up is the single most common mistake:
- Lossless compression stores the image so it can be rebuilt pixel-for-pixel identical to the original. Nothing is discarded — the file is just packed more efficiently. PNG, GIF, and WebP-lossless work this way.
- Lossy compression permanently discards some information to save far more space, accepting a small drop in fidelity you usually cannot see. JPEG, WebP-lossy, and AVIF work this way.
The rule of thumb: photographs → lossy (huge savings, no visible loss); logos, screenshots, text, line art, anything with sharp edges or transparency → lossless (lossy would smear the crisp edges). Everything below is really about how each camp achieves its savings.
How lossless compression shrinks a file
Lossless methods exploit redundancy — patterns the file repeats. A screenshot with a big flat blue header contains thousands of identical blue pixels in a row. Instead of storing "blue, blue, blue…" ten thousand times, the encoder stores "blue ×10,000". That is run-length encoding, and PNG builds on the same idea with two layers:
- Filtering — before compressing, PNG predicts each pixel from its neighbours and stores only the difference. In smooth areas the differences are mostly zero, which compresses beautifully.
- DEFLATE — the same entropy-coding engine used in ZIP files then packs those differences, giving short codes to common values and long codes to rare ones.
Because nothing is thrown away, lossless is perfect for graphics — but it hits a wall on photographs, where almost every pixel differs slightly from its neighbours (little redundancy to exploit). That is exactly where lossy takes over.
How lossy compression shrinks a photo
JPEG — still the workhorse of the web — is a masterclass in throwing away what your eyes do not notice. Simplified, it does four things:
- Separates brightness from colour. Human eyes are far more sensitive to brightness than to colour detail, so JPEG stores colour at lower resolution (chroma subsampling). You lose colour precision you were never going to perceive.
- Works in 8×8 blocks with the DCT. Each block is transformed (a discrete cosine transform) from "pixels" into "frequencies" — how much fine detail vs smooth gradient it contains.
- Quantization — the actual lossy step. High-frequency detail (fine texture) is divided down and rounded, often to zero. This is where the bytes vanish, and it is what the "quality" slider controls: lower quality = coarser rounding = smaller file = more detail discarded.
- Entropy coding. The mostly-zero result is packed losslessly, like PNG's final step.
This is why JPEG is superb for photos (it discards subtle texture you cannot see) and terrible for a screenshot of text (those 8×8 blocks smear sharp black-on-white edges into grey "ringing" halos). Newer lossy formats — WebP and AVIF — use the same core idea with smarter, larger, variable-sized blocks and better maths, which is how they beat JPEG at the same quality.
The "quality" slider, demystified
When a compressor offers light / medium / strong or a 0–100 quality number, it is choosing how aggressively to quantize:
- 90–100: near-lossless; large files. Overkill for the web.
- 75–85: the sweet spot for most photos — dramatic size cuts, no visible loss. This is where you should live.
- 50–70: noticeably smaller; fine for thumbnails or when you must hit a hard size limit.
- Below ~40: visible blocking and colour banding.
The catch: quality loss is cumulative and permanent. Re-saving a JPEG at 80%, then editing and saving again, compounds the damage each time (generation loss). Always keep an original and export compressed copies from it, rather than re-compressing the compressed version.
Where "resize" fits in
People conflate compress and resize, but they are different levers. Resizing changes the pixel dimensions (a 4000-px-wide image down to 1200). Compressing keeps the dimensions but stores each pixel more efficiently. They stack: a web photo that is both resized to the size it is actually displayed and compressed is often 95% smaller than the original with no visible difference. If a file is still too big after compressing, it is usually because the dimensions are far larger than needed — see how to resize without losing quality.
Hitting a specific size target
Sometimes the requirement is a hard cap — "under 100 KB", "below 2 MB for the upload form". The honest way to hit it is to compress, check the result, and step the quality down until you clear the limit — text-heavy or simple images hit tiny sizes easily, while detailed photos need a gentler hand. Our Compress tool lets you do exactly this in the browser, and there are focused walkthroughs for compressing to a specific file size, under an email limit, and bulk-compressing 100+ images at once.
How much can you actually save? Real numbers
It helps to have realistic expectations, because the savings depend entirely on the image type:
- A 12-megapixel phone photo (JPEG, ~4 MB) → re-compressed at quality 80 with a sensible resize to 1600 px, typically lands around 200–400 KB — a 90%+ reduction with no visible loss.
- A PNG screenshot (~1.5 MB) → kept lossless but optimised, often drops 30–50%; converted to WebP-lossless, more still — while staying pixel-perfect.
- A PNG photo (someone saved a photo as PNG, ~8 MB) → converting to JPEG or WebP at quality 80 can cut it 95%, because PNG was the wrong format for a photo in the first place.
- A logo saved as JPEG → the fix is not more compression but the right format: re-save as PNG or SVG to kill the halo artefacts, even if the file is slightly larger.
The pattern: the biggest wins come from fixing a format mismatch or an oversized dimension, not from cranking the quality slider down.
WebP and AVIF: the same idea, done better
JPEG's four-step recipe is 30 years old. WebP and AVIF keep the core idea — transform to frequencies, quantize away what you cannot see, entropy-code the rest — but modernise every step:
- Variable, larger block sizes instead of JPEG's fixed 8×8, so smooth areas use big efficient blocks and detailed areas use small precise ones.
- Smarter prediction of each block from its neighbours before encoding, leaving less to store.
- Better entropy coding (arithmetic coding) that packs the result more tightly.
The practical result: WebP is ~25–35% smaller than JPEG at the same visual quality, and AVIF another ~20% smaller than WebP, with fewer of the blocky artefacts JPEG shows at low quality. If you are choosing a format for the web today, this is why WebP is the sensible default and AVIF the aggressive one — covered in full in the format guide.
Common compression mistakes
- Re-compressing a compressed file. Editing a JPEG and re-saving compounds loss every time. Always work from the original.
- Using PNG for photos. It is lossless, so it cannot discard the detail that makes photos huge — the file balloons for no visible benefit.
- Cranking quality to 100. Above ~90 you pay a big size penalty for a difference nobody can see.
- Compressing but not resizing. A 4000-px image compressed to quality 80 is still far bigger than the same image resized to 1600 px first, then compressed.
- Compressing text screenshots as JPEG. Sharp black-on-white edges turn into grey "ringing" — use PNG for anything with text.
Do it privately
Because compression is pure maths on pixel data, it can run entirely in your browser — your photo never has to be uploaded to a server. That matters for anything personal: an ID, a receipt, a private photo. Every tool here works that way; you can confirm it by opening your browser's developer tools (F12 → Network) and watching for uploads while you compress — you will see none. More on why that is safer in how in-browser image tools work.
Key takeaways
- Lossless (PNG) rebuilds the image exactly — use it for logos, screenshots, text, and transparency.
- Lossy (JPEG/WebP/AVIF) discards detail you cannot see — use it for photographs, where it saves enormously.
- The quality slider controls quantization; 75–85 is the no-visible-loss sweet spot for photos.
- Quality loss is cumulative — always compress from the original, never re-compress a compressed file.
- Resize and compress are different levers that stack; use both for the web.
- Compression is just maths, so it can run locally in your browser — no uploads needed.