Image compressor

Resize first, then compress

The single biggest saving usually has nothing to do with the quality slider. A photo straight from a modern phone is often 4,000 pixels across. Displayed at 800 pixels wide on a web page, three quarters of every dimension is thrown away by the browser anyway — you paid to transfer pixels nobody ever saw.

File size scales with area, not with width, so halving the longest edge quarters the pixel count. Here is that effect measured: one 1280 × 992 screenshot (91.4 KB as PNG), written out at a fixed quality of 0.75 with only the longest edge changing.

Dropping the longest edge from 1280 to 900 — a change most viewers would not notice on a page that displays the image at 600 — takes the JPEG from 76.3% of the original to 44.6%, and the WebP from 43.5% to 24.5%. Reaching the same saving with the quality slider alone means going to a setting where the artefacts are visible.

A practical order of operations:

1. Decide the largest size the image will ever be displayed at.
2. Resize the longest edge to about twice that, for high-density screens.
3. Then, and only then, adjust quality.

What the quality setting actually does

Lossy formats work by discarding detail the eye is bad at noticing — fine colour variation especially, since human vision is far more sensitive to brightness than to hue. The quality number controls how aggressively that discarding happens. The same image again, at full size, with only the quality changing:

Two things stand out. The curve is steep at the top and flat at the bottom: going from 0.95 to 0.85 removes a third of the JPEG, while going from 0.6 to 0.4 removes only a fifth of what is left, and that last step is where the damage becomes obvious. And WebP is smaller than JPEG at every single setting — at quality 0.75 it is 43% of the original where JPEG is 76%.

As rough guidance: 0.9 and above is for archiving, 0.75 to 0.85 is the usual web choice, 0.6 to 0.75 starts showing artefacts in gradients such as skies, and below 0.6 is thumbnails only.

Compression is not reversible. Each save at a lossy setting discards detail permanently, so repeatedly editing and re-saving the same JPEG degrades it a little each time. Always compress from the original, not from a previously compressed copy.

When compressing makes the file bigger

Look at the top row of the quality table again: JPEG at 0.95 is 144.6% of the PNG it came from. The “compressed” file is half again as large as the original, and it looks worse. This is the most common way image compression is used wrongly, and it happens whenever a screenshot or a flat graphic is pushed through a high-quality JPEG.

The reason is that the two formats are built for opposite kinds of picture. PNG stores runs of identical pixels cheaply, which is exactly what a screenshot is made of. JPEG assumes smooth gradients and spends its bits on the sharp edges around text, which is exactly what a screenshot has most of. Feed each format the picture it was designed for and both do well; swap them and both do badly.

Re-encoding losslessly is not the answer either:

Both lossless outputs are larger than the file they came from — the browser's PNG encoder is an honest but plain one, not the heavily optimised encoder that produced the original. This is a real limit of doing the work in a browser tab, and it is worth stating plainly: if your PNG has already been through an optimiser, this tool cannot beat it losslessly. What it can do is get you to a much smaller lossy file, or to a smaller size.

The practical rule that falls out of all three tables: for photographs, reach for WebP or JPEG and resize before you touch quality. For screenshots, diagrams and anything with text or flat colour, keep PNG or use WebP, and reduce the pixel count rather than the quality.

Choosing a format

WebP is the default worth reaching for. It compresses better than JPEG at the same perceived quality, supports transparency, and works in every current browser. The main reason to avoid it is a system elsewhere in your workflow that will not accept it.

JPEG remains the safest interchange format. Anything that reads images at all reads JPEG. It cannot store transparency, which is why this tool fills transparent areas with white when you convert to it — otherwise they would come out black.

PNG is lossless. That makes it the correct choice for screenshots, logos, charts and line drawings, where lossy compression smears the sharp edges into visible mush. It is the wrong choice for photographs, where it often produces a file several times larger than the JPEG it replaced.

Why local processing is the better arrangement

Most compression sites work by uploading your file, processing it on a server, and returning a download link. That means a copy of your image existed on someone else's machine, subject to their retention policy, their access controls, and their breach history. For a holiday snapshot that may not matter. For a passport scan, a medical document, or an unreleased product photo, it very much does.

Browsers have been able to decode, resize, and re-encode images natively for over a decade. Sending the file away was never technically necessary — it was just easier to build. Processing locally is also faster, because there is no upload wait and no queue, and it works with several files at once without a size cap imposed by someone's bandwidth bill.