Resize, compress, convert: three different jobs
“Make the image smaller” is three requests wearing one label. Resizing changes how many pixels exist, compression changes how those pixels are written down, conversion changes the codec. Each has its own failure mode, and the wrong one gives you a file that is both small and ruined.
Three operations, three mechanisms
| Operation | What changes | What it costs |
|---|---|---|
| Resize | pixel dimensions, e.g. 4000×3000 → 1600×1200 | detail the smaller grid cannot hold |
| Compress | encoding at the same dimensions | quality, at a rate you set |
| Convert | codec and container, e.g. PNG → WebP | whatever the new codec cannot represent |
Compression cannot recover pixels you never had, and that fixes the order: resize first, then set quality, then choose the format. Resizing last is the common mistake — you pay a compression hit at full resolution, then throw most of those samples away.
Lossy and lossless, honestly
JPEG quality is not a percentage of anything: a lower setting discards more high-frequency coefficients after the transform. On the 0–1 scale browsers use, 80–85 is roughly where photographs stop getting smaller fast enough to justify the damage; savings below 80 mostly arrive with visible cost.
Where JPEG breaks is predictable.
- Flat colour fields and gradients band into steps — the worst case for block quantisation.
- Text in images gains a halo. Standard encoders also discard colour resolution (4:2:0 subsampling keeps one colour sample per four pixels), so thin red type on a dark background turns to mush before grey text does.
- High-contrast edges get ringing, a faint doubled outline.
PNG has no quality knob: being lossless, a photographic PNG typically lands three to eight times the size of the same picture at JPEG quality 82. The only parameter that moves it governs how hard the compressor tries, changing file size by percent, never the pixels.
That losslessness is why screenshots and interface graphics should stay PNG: flat panels, crisp letter edges and solid colour compress well without quantisation, and a PNG survives a later resize because the resampler starts from exact pixels, whereas resampling an already-compressed JPEG smears artefacts into noise around text.
WebP, AVIF, and what a converter can offer
Lossy WebP is commonly reported 25–35% smaller than a JPEG of comparable appearance on photographs, and unlike JPEG it carries an alpha channel. The encoder already ships inside modern browsers, so there is no real downside — it is the practical win.
AVIF goes smaller still, most visibly at aggressive targets, but encoding takes far longer and decode support is thinner on older browsers and third-party viewers. HEIC is Apple’s default and is not a safe web deliverable.
Format availability depends on which encoders are present. A tool built on the browser’s canvas export can offer JPEG, PNG and WebP because the browser ships those; the quality argument it accepts only means something for the lossy types, and for PNG it changes compression effort. AVIF has to be compiled in and carried along, so a three-format converter is limited by its encoders rather than thin by choice.
Typical numbers
Typical for ordinary content, not measurements of your file.
- 4000×3000 camera JPEG, about 12 megapixels: 3–5 MB.
- Same photo at 1600×1200, quality 82 (6.25× fewer pixels): 250–450 KB.
- Same photo at 1200×800, quality 80: 150–250 KB, enough for email or a listing.
- 1920×1080 screenshot of a text-heavy page: PNG 400–900 KB and perfectly sharp, JPEG at quality 85 150–300 KB with ringing around the letters, lossy WebP at quality 80 90–160 KB and usually still more readable than the JPEG at that size.
Photographs shrink by resolution first; graphics shrink by codec choice first.
Traps that cost quality
Upscaling never returns detail. Interpolation paints a plausible smear between the samples that exist, so a 2× enlargement of a soft photo is the same soft photo, heavier; sharpening fakes the difference with edge halos.
JPEG generations compound. Decoding and re-encoding re-quantises coefficients, so artefacts already in the file are quantised again and worsen each pass. Saving twice or round-tripping through a messaging app charges this. Keep a lossless master and export once; for rotation or crop, tools that edit the compressed data directly skip re-encoding.
Resampling defaults flatter nothing. Canvas smoothing is on by default, but its quality hint defaults to
the cheapest filter, so one jump from 4000 to 1000 aliases; halving in stages keeps edges clean. CSS
image-rendering defaults to smooth scaling that blurs an enlarged image; nearest neighbour keeps pixel art
hard-edged but makes photographs blocky.
Transparency is flattened when converting to JPEG. The format has no alpha, so transparent areas become a solid fill — white in some encoders, black in others. Use PNG or WebP instead.
Orientation gets applied twice or dropped. A phone often stores an Orientation tag instead of rotating
pixels. Rotating the pixels but leaving the tag yields a picture turned 90° off; doing neither passes the
trap to the next viewer. Correct handling bakes the rotation in and resets the tag.
Which operation, which format
| Goal | Operation | Output |
|---|---|---|
| Email or chat photo | resize to a 1600 px long edge | JPEG 80–85 |
| Photo on a site | resize to displayed size | WebP, JPEG fallback |
| Sharp text screenshot | hold dimensions, lossless | PNG or lossless WebP |
| Graphic with transparency | resize only if needed | PNG or WebP, never JPEG |
| Master before editing | do not recompress | original file or PNG |
| Smallest file at fixed size | change codec, then tune quality | WebP, then AVIF |
Size is not the only constraint. A file holding an ID number, a medical image, the interior of your home or a child’s face should not be uploaded to a service you have not examined to save a few hundred kilobytes; the image resizer linked here runs all three operations on your own machine.