Resize, compress, convert: three different jobs

Updated 4 min read

“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

OperationWhat changesWhat it costs
Resizepixel dimensions, e.g. 4000×3000 → 1600×1200detail the smaller grid cannot hold
Compressencoding at the same dimensionsquality, at a rate you set
Convertcodec and container, e.g. PNG → WebPwhatever 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

GoalOperationOutput
Email or chat photoresize to a 1600 px long edgeJPEG 80–85
Photo on a siteresize to displayed sizeWebP, JPEG fallback
Sharp text screenshothold dimensions, losslessPNG or lossless WebP
Graphic with transparencyresize only if neededPNG or WebP, never JPEG
Master before editingdo not recompressoriginal file or PNG
Smallest file at fixed sizechange codec, then tune qualityWebP, 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.

Open the tool: Image Resizer

Back to guides

More guides