Lossy vs lossless image compression: which one is shrinking your file

Every “why is this file so big” question is really a question about two different promises. A ZIP file and a JPEG both shrink data, but they owe you different things: the ZIP promises that you get your data back, bit for bit; the JPEG promises only that it will look like your data. That single distinction — reversible or not — decides which format fits which image, why some files resist compression entirely, and where the visible quality loss comes from.

The two contracts

Lossless compression is reversible. It finds redundancy — repeated patterns, predictable runs — and encodes them more compactly, and the decoder restores the original exactly. PNG, GIF, and the lossless mode of WebP work this way, and so does every general-purpose archiver. The price of the guarantee is the savings ceiling: a file already contains all its information, so the compressor can only remove the redundant part.

Lossy compression is deliberately irreversible. It keeps the information a viewer would notice and discards the rest — fine detail, high-frequency noise, subtle gradients — on the theory that the eye will not miss it. JPEG and default-mode WebP work this way. The savings are dramatic for the same reason the round trip fails: the encoder is allowed to throw information away.

The numbers make the contract visible. A photo that is 6.2 MB as captured re-encoded at 70% JPEG quality typically lands around 800 KB — an 87% saving — because the encoder discarded the detail the eye does not register. The same photo as a lossless PNG stays large, because every pixel is owed the full truth.

Why your PNG resists the quality slider

This is the point where most “compress my image” tools quietly mislead: PNG is lossless, so it has no quality knob to turn. The slider sits on a format that cannot take the deal — lowering it changes almost nothing, because lossless compression must preserve every pixel regardless of how much you beg it to drop a few. If a PNG is large, the effective move is a format change, not a setting change: converting to WebP or JPEG typically cuts the file by 60–80%, because those formats are allowed to discard information the PNG was contractually obligated to keep.

The exception that keeps PNG alive is transparency. An image that needs an alpha channel — a logo on a colored background, a sticker, a cut-out — has no lossless home in plain JPEG, and a lossy attempt at an alpha edge produces the haloed, crunchy borders familiar from badly compressed logos. For anything with sharp edges, flat colors, and transparency, PNG or lossless WebP is the honest choice: the artifact risk of lossy encoding is higher than the size saving.

What lossy actually discards

A JPEG does not blur the whole image; it makes a judgment about what the eye can afford to lose. Smooth areas survive nearly intact, while high-frequency detail — fine foliage, hair, fabric texture, noise in gradients — is where the savings are taken from. That is why the same quality setting produces very different results on different photos: a portrait with a smooth background compresses far better than a treetop in bright sun.

The artifact signatures are readable once you know them:

• Blocking — the 8×8-pixel grid becomes visible when detail is dropped hard; the classic “blocky JPEG”.
• Gradient banding — smooth sky or studio backgrounds break into steps as intermediate tones are merged.
• Edge ringing — text and sharp edges grow faint halos where the encoder smeared contrast.

None of these appear at sane quality settings on a normal screen; they are the story of what happens below the sweet spot. Which is why the useful number is the output size at the setting you are actually considering, not a fixed preset — a landscape with smooth gradients and a foliage photo land at completely different sizes on the same slider.

The size side: what compression is actually for

Compression exists to fit a file where it must go: an email attachment limit, an upload cap on a marketplace listing, a page-weight budget, a messenger that rejects multi-megabyte photos. In each case the constraint is bytes, and the savings percentage is the only number that tells you whether you will pass. The two levers are format and resolution, and they are different jobs:

• Compression re-encodes at a quality you choose — the format-and-quality knob, for photos that must stay photographic.
• Resizing shrinks pixel dimensions to fit a maximum box — the resolution knob, for files that are too large because they are too big, not because they are encoded wastefully.

A 4,000×3,000 camera photo at 6.2 MB usually needs both: the resizer brings it to 1,600px inside a max box (never stretching, never upscaling, aspect ratio preserved), and the compressor then re-encodes that smaller image at 70% quality. Each tool does the job the other cannot — and both run entirely on the device, so a 25 MB photo never has to cross a network just to be made smaller, and the re-encoding removes embedded GPS and EXIF metadata whether you asked for that or not. That last part is disclosed on every result: a compressed file is a clean file, and the original remains the archive.

Picking by what the image must survive

The decision table is short:

Image type	Format	Why
Photos (screen, email, web)	JPEG or WebP, 60–80%	Lossy saving is large; artifacts invisible at sane quality
Logos, diagrams, text, flat colors	PNG or lossless WebP	Sharp edges must stay sharp; lossy ringing is worse than the saving
Anything needing transparency	PNG (or WebP with alpha)	Alpha edges need the lossless guarantee
Archival / originals	Keep the source file	Every derivative is a copy with metadata stripped

Let the calculator do it

The image compressor takes JPG, PNG, or WebP, and re-encodes it at a quality you set with a live size readout — the exact output size and percentage saved appear before you download, and the sweet spot (usually 60–80% for photos) is found by moving the slider, not by trusting a preset. PNG inputs are handled honestly: converting to WebP or JPG is what actually shrinks them, and the tool says so. The image resizer handles the other lever — fitting any image inside a maximum width and height with the aspect ratio preserved, never upscaling, reporting the exact output dimensions against the platform’s limit. Both process everything on your device in a background Web Worker, with the file never leaving the browser, and both display the exact method used so the result is never a black box.

The one rule

Ask what the image must survive — a round trip, or a screen? — and pick the format by the answer: lossless for anything that must come back intact or has sharp edges, lossy for photos where the eye is the judge and the saving is the point. Then use the slider as a finder, not a preset: the output size at the setting you choose is the number that decides whether the file fits where it needs to go.