Compress an image without visible loss of quality
Why you should cut the pixel dimensions before touching the quality slider, and the point at which JPEG compression really starts to show.
A form refuses your attachment above 2 MB, and the photo straight off your phone is 4.8 MB. Or a gallery of thirty images takes eight seconds to appear on a mobile. In both cases the right reaction is not to drag a slider down to the minimum: it is to work out where the file's size actually comes from, then take it away where the eye will not notice.
What “no loss of quality” actually means
There are two families of compression, and they do not promise the same thing.
- Lossless — PNG, and WebP in lossless mode. The decompressed file is identical to the original, pixel for pixel. On a photograph the saving stays modest compared with an uncompressed image, and it becomes counter-productive if the source is already a JPEG: the PNG will end up far heavier than the file you started with.
- Lossy — JPEG, WebP in lossy mode, AVIF. The encoder throws away information the human visual system barely registers: fine colour variations, high-frequency detail. The saving is measured in tens of times over, not in percentages.
When a tool promises “no loss of quality”, it is almost always talking about the second family: the loss is real, but it sits below the threshold of perception at the display size you have in mind. That threshold is what you are aiming at, and it depends as much on the pixel dimensions as on the slider.
Start with the dimensions, not the quality
A file's size roughly tracks the number of pixels the image contains. A smartphone photo at 4032 × 3024 is 12 megapixels. Brought down to 1600 px wide, it becomes 1600 × 1200, or 1.9 megapixels: roughly a sixth as much data to encode, before you have touched the quality setting at all. This is nearly always the most effective step, and the only one that creates no artefacts whatsoever.
A few useful widths to work from:
- Thumbnail or profile picture: 400 to 600 px
- Illustration inside an article: 1200 to 1600 px
- Full-width banner: 1920 px, or 2560 px if you are catering for high-density screens
- A4 print at 300 dots per inch: 2480 × 3508 px
There is a stubborn misunderstanding to clear up here: DPI is only a label stored in the metadata. Taking an image from 72 to 300 DPI without changing the number of pixels alters neither its size nor its sharpness, only the instruction handed to the printer. The pixel dimensions are the only thing that genuinely counts. To adjust them while keeping the proportions, the resize an image tool does the job right in your browser.
The quality slider, with numbers
The JPEG quality scale runs from 0 to 100 and is anything but linear. Here is what the common settings give you on an ordinary photograph:
- 90 to 100 — virtually no visible gain over 85, for a file two to three times heavier. Keep it for images that will be edited afterwards.
- 80 to 85 — the safe setting. The difference from the original is not detectable on screen.
- 70 to 75 — the sensible compromise for the web. It is the slider's default position on the image compression tool, which shows the before and after sizes so you can judge for yourself.
- 55 to 65 — artefacts start to show in gradients: skies, skin, soft shadows. Acceptable for thumbnails.
- Below 50 — the 8 × 8 pixel blocks that JPEG works on become plainly visible.
The sound method: come down in steps of 5 and inspect the vulnerable areas at 100% zoom — a sky with a gradient, a shadow, the edge of some text. Those are what give way first, not the textured areas.
The format often matters more than the setting
| Format | What for | Worth knowing |
|---|---|---|
| JPEG | Photographs, images with continuous gradients | No transparency, poor on fine text |
| PNG | Screenshots, logos, flat colour, transparency | Lossless: the quality slider has no effect at all |
| WebP | The web in general | Roughly 25 to 30% lighter than JPEG at equal perceived quality, handles transparency |
| GIF | Nothing, apart from a short animation | Limited to 256 colours, outclassed for still images |
A screenshot saved as JPEG at 75 gives itself away instantly: halos appear around the letters, because the algorithm is built for gentle variation rather than for crisp black-and-white transitions. The same screenshot as a PNG stays perfectly legible and is often lighter. The reverse holds just as well: a photograph saved as PNG can be ten times the size of the equivalent JPEG. If you picked the wrong format at the outset, the image format converter lets you move between JPEG, PNG and WebP.
The traps that spoil the result
Transparency vanishes in JPEG
JPEG has no alpha channel. A PNG logo on a transparent background exported as JPEG has its transparent areas filled with a solid colour — black by default, since that is how an empty canvas is encoded, or white when the tool paints a background before exporting, as Convertu does. If the image is going to sit on a coloured background, stay with PNG or WebP.
Repeated compression stacks up
Every save as JPEG applies a fresh round of quantisation on top of the previous one. The first re-encode is the expensive one: as long as you keep saving at the same setting, without cropping or resizing, the block grid stays aligned and later passes remove almost nothing more. What really degrades an image is lowering the setting each time round, or editing the picture between two saves — shifting the grid starts the losses again. Always go back to the original file rather than to the version you have already compressed.
EXIF metadata is stripped
Re-encoding in the browser relies on a canvas, which carries nothing but the pixels: GPS coordinates, camera model, capture date and colour profile all disappear. That is excellent before you publish a photo online — nobody will be reading your home address out of the GPS data — but awkward for archiving. Keep the original to one side if that information matters.
Oversized files simply fail
Browser-side processing has a ceiling: past a certain size (a high-resolution scan, a stitched panorama), the engine hands back an empty canvas instead of an image. The threshold depends on the browser and drops sharply on a mobile. Convertu turns down anything above 40 megapixels and tells you so explicitly, rather than leaving you with a blank preview. Reduce the dimensions first, compress afterwards.
An already-optimised PNG can grow
An 8-bit PNG with a 256-colour palette is already very compact. Saving it again as a 24-bit PNG makes it heavier rather than lighter. If the file size refuses to budge, or climbs, that is probably what is happening: change the format rather than the setting.
When compression is not enough
If the file is still too heavy after a resize and a pass at 70, the problem lies elsewhere. Three common cases:
- The file is a HEIC. Recent iPhone photos come out as .heic, a format plenty of forms and applications flatly refuse. You need to run a HEIC to JPG conversion first, then compress the result.
- It is a scanned document. Text compressed too hard becomes unreadable, and any OCR you run on it will fail. Stay above 85 in JPEG, or keep the document as a PDF.
- You are chasing an unreasonable size limit. A 200 KB ceiling for a full-width photo means coming down in dimensions, not in quality. A sharp 1200 px image beats a 2400 px one riddled with artefacts.
Resizing, compression and format conversion all run entirely inside your browser on Convertu: the file goes to no server. Those three tools do require an account, and they are covered by the single subscription at €7 a year. The HEIC conversion runs server-side — one free conversion a day, then that same subscription if you handle them regularly.