Image Compression: How Small Before It Looks Bad

"Can this be smaller?" usually gets answered by dragging the quality slider. But quality carries far less weight than pixel count.

Size ≈ pixels × cost per pixel

A 4000×3000 photo is 12 megapixels. At 1200×900 it is 1.08 megapixels — 9% of the pixels, and roughly a tenth of the file size.

Meanwhile, dropping JPEG quality from 90 to 80 saves about 30%; 80 to 70 saves another 20% but visible artefacts start. So the order is always:

1. Resize — decide how large it will actually appear
2. Pick a format — JPEG / PNG / WebP have different jobs
3. Tune quality — the smallest value that still looks right

Doing it backwards wastes effort: compress to quality 50 first and the detail is already gone, resizing will not bring it back.

Choosing the target size

Web images are usually displayed at 600–1200 CSS pixels. Most phones and laptops are 2× screens, so export at twice the display width.

Use	Target width	Note
Inline article image	1200 px	Displayed at 600 CSS px
Hero / cover	1600 px	Leaves cropping room
Thumbnail	400 px	Never ship a large image scaled down by CSS
Print, A4 photo	2480×3508	300 dpi
Email attachment	≤ 1600 px	Some clients cap at 10 MB per message

"72 dpi is the web standard" is a print-era leftover. Screens only see pixels; dpi only matters when ink is involved.

Format first

Content	Use	Avoid
Photos, gradients	JPEG or WebP	PNG (up to 5× larger)
Screenshots, text	PNG or WebP	JPEG (coloured fringing around glyphs)
Icons, logos	SVG	Any raster format
Transparency needed	PNG or WebP	JPEG (no alpha channel)

For photos, WebP is typically 25–35% smaller than JPEG at equal quality. The compatibility story is settled in browsers; the remaining risk is "the recipient will open it in an old desktop app".

Image Converter handles batch format changes; Image Resizer resizes and recompresses by longest edge or width, in bulk.

What the quality numbers feel like

Quality	Appearance	Use
90–95	Indistinguishable from source	Intermediate files that will be edited again
80–85	No visible difference at normal viewing	Default for delivery
70	Slight blocking in smooth areas	Thumbnails
Below 50	Obvious blocks, soft text	Placeholders only

Why 80 is the hinge: JPEG works on 8×8 blocks. Past a certain quality, high-frequency detail is discarded wholesale and the block boundaries become visible. Human vision is most sensitive to flat regions — sky, plain backgrounds — and forgiving of texture. So the same photo degrades in the sky long before it degrades in the grass.

Judge by viewing at 100% on a flat area, not by looking at the thumbnail.

Three ways people over-compress

1. Re-saving JPEG repeatedly. Every save is another lossy pass; five generations is visibly degraded. Keep a PNG or the original for anything edited more than once.
2. Saving screenshots as JPEG. Text edges get colour fringing that cannot be undone. Screenshots are always PNG.
3. Upscaling after compression. The pixels are gone; interpolation does not restore them.

Watermarks go last

Add the watermark after resizing — otherwise it shrinks with the image and gets soft. But add it before the final quality pass, or the sharp watermark edges are what JPEG damages first.

A checklist that holds up

• [ ] Target width = 2× the display width
• [ ] Format matches content (photo → JPEG/WebP, screenshot → PNG, icon → SVG)
• [ ] Quality at 80–85
• [ ] Checked a flat area at 100%
• [ ] No transparency in a JPEG
• [ ] Original kept if further editing is likely

Following this order, a 4 MB phone photo lands under 200 KB and still looks sharp. The size came from step one, not from the slider.

For the opposite problem — reading text out of an image — Image to Text (OCR) is the tool, and it benefits from the same discipline: crop and resize before sending, because a 4000px image downscaled by the server loses the detail OCR needs.