Image Compressor

Image compression reduces the number of bytes needed to store a picture. It works because photographs are enormously redundant: neighbouring pixels are usually similar, and the eye is far more sensitive to brightness than to colour, and far more sensitive to large shapes than to fine texture. A compressor exploits all three.

An uncompressed 12-megapixel photograph is about 36 MB — three bytes for every pixel. The JPEG your camera writes is perhaps 4 MB. Re-encoded as WebP at a sensible quality and sized for a web page, it is nearer 150 KB. Nothing has been lost that you can see at normal viewing size; what has gone is detail that was costing bandwidth and buying nothing.

Every one of those steps happens here inside your browser. There is no upload step, no queue, and no server that ever receives the file.

This is the one distinction worth understanding, because it determines what you can and cannot do afterwards.

Lossy

JPEG, WebP and AVIF discard information permanently. They transform the image into frequency components, keep the ones the eye notices and round away the ones it does not. The saving is dramatic — often 95% — and the discarded detail is gone. Compressing an already-compressed image a second time discards a second time, so repeated saves degrade an image in a way a single save does not.

Lossless

PNG stores every pixel exactly. It saves space only by describing repetition more efficiently, which is why it does brilliantly on a screenshot of flat interface colours and badly on a photograph of leaves. Decompressing a PNG returns the original bytes, so you can edit and re-save it indefinitely without decay.

The practical rule: photographs lossy, graphics lossless. A photograph has no flat areas for a lossless coder to exploit and plenty of texture a lossy one can throw away. A screenshot is the reverse — flat colour everywhere, and sharp text edges that lossy compression turns into a halo.

WebP is the default because it wins on nearly every axis: 25–35% smaller than JPEG at matched quality, a full alpha channel, and support in every browser shipping today. The reasons to choose otherwise are specific — JPEG for software too old to know what WebP is, PNG for pixel-exact output, AVIF when you want the absolute smallest file and can accept the slower encode.

AVIF is the newest and the smallest, typically another 20% below WebP. Its weakness is not decoding, which is widespread, but encoding, which is not — and the browser API fails silently, handing back a PNG when asked for something it cannot make. The tool tests for this on load and marks the format unavailable rather than giving you the wrong file.

The quality number is not a percentage of anything. It is a dial on how coarsely the encoder rounds away detail, and its relationship to file size is steeply non-linear: the last ten points cost far more bytes than the first fifty.

• 95–100 — visually lossless, and expensive. The file can be several times the size of the same image at 85 for differences you would need a pixel-difference tool to locate.
• 85–94 — excellent. Indistinguishable at normal viewing size. Use this for photography where the image is the point.
• 75–84 — the usual choice for the web, and where the default of 80 sits. Artefacts exist but you have to look for them.
• 60–74 — softening becomes visible on close inspection, especially around high-contrast edges. Fine for thumbnails.
• Below 60 — obvious blocking, ringing around text, and colour banding in smooth areas. Only worth it when bandwidth genuinely dominates.

Rather than trusting the numbers, drag the slider and look. The comparison view lays the compressed image directly over the original at the same size and position, so anything you can see moving is a real change in the pixels rather than a difference in how the two are displayed.

This is the part most compression advice skips, and it is the larger lever by a wide margin.

File size scales with the pixel count, and the pixel count scales with the square of the dimensions. Halving both sides leaves a quarter of the pixels. No quality setting achieves a 75% reduction without visible damage; halving the dimensions of an image that was being displayed at half size anyway costs nothing at all, because those pixels were never reaching the screen.

A 4000×3000 photograph displayed in a 800-pixel-wide column is carrying twenty times the pixels it can use. Compressing it harder is optimising the wrong thing. Resizing it to 1600px — twice the display width, so it still looks sharp on a high-density screen — removes 84% of the data before the encoder even starts. If the real photograph does not exist yet, the dummy image generator makes a placeholder at the exact dimensions you have decided on.

Downscaling here is done in halving steps rather than one jump. drawImage samples rather than averages when it shrinks by a large factor, so going from 4000px to 400px in a single pass discards nine of every ten pixels and leaves visible aliasing on any fine detail. Halving repeatedly averages instead, which is what a proper image library does internally.

Enlarging is refused unless you explicitly ask for it. There is no information in an image that was not captured, so scaling up invents pixels by interpolation: the file gets bigger and the picture gets softer, which is the opposite of what a compressor is for.

PNG has no quality slider, because it is lossless — there is no detail to trade away. What it has instead is a palette.

A full-colour PNG stores three or four bytes per pixel. A palette PNG stores an index into a table of up to 256 colours, which for a 128-colour image is a single byte, or less once the compressor has been over it. That is where the saving comes from, and on the right image it is enormous: a screenshot of an interface might contain a few dozen distinct colours, and storing 16 million possibilities to represent them is pure waste.

Median cut

Choosing which colours to keep is the interesting part. The tool uses median cut: it puts every colour in the image into one box, then repeatedly splits the box with the widest spread along its widest channel, at the median, until there are as many boxes as colours wanted. Each box contributes its average colour. Splitting at the median rather than the midpoint means each box ends up holding a similar number of pixels, so the palette is spent where the image actually is.

The channel choice is weighted perceptually — green counted heaviest, blue lightest, in the proportions the eye actually uses. A palette chosen by raw numeric spread wastes entries on blue gradations nobody can distinguish while banding the greens everybody can.

Dithering

Once the palette is fixed, every pixel has to map to one of its entries, and a gradient that used 200 shades mapping onto 16 produces visible bands. Floyd–Steinberg ditheringfixes this by carrying the rounding error forward: the difference between a pixel’s true colour and the palette entry it received is pushed into its not-yet-processed neighbours in fixed proportions. The result is a fine pattern that averages to the right colour, and a gradient stays smooth.

Turn it off for logos, icons and line art. Those areas are meant to be perfectly flat, dithering makes them noisy, and the noise also compresses worse — so you get a larger file that looks wrong.

1. 1. Add your images. Drag them in, paste from the clipboard, or choose files. Add as many as you like — they queue and process two at a time.
2. 2. Pick a preset. Ten of them, each setting format, quality and size together, because those three decisions are related and setting one in isolation usually leaves the biggest saving on the table.
3. 3. Adjust if you need to. Format, quality, palette, dithering and resize are all exposed. Changing anything and pressing Ctrl+Enter re-runs the whole batch.
4. 4. Check the result. The slider overlays compressed on original at the same size; zoom to 8× to inspect a specific area. Each image reports its before-and-after size, its saving and how long it would take to arrive over slow 3G.
5. 5. Download. Individually, or the whole batch as a ZIP with Ctrl+Shift+D.

If an image comes back larger, the tool says why rather than reporting a negative saving and leaving you to guess. The usual cause is re-encoding an already-compressed file at a high quality, where the second pass has to store the first pass’s artefacts as though they were real detail.

Images are typically the majority of a page’s weight, which makes them the majority of its loading time — and loading time is a ranking signal through Core Web Vitals.

Largest Contentful Paint measures when the biggest visible element finishes rendering, and on most pages that element is an image. Google considers it good below 2.5 seconds. A 2 MB hero on a mobile connection cannot meet that no matter what else you do; the same image at 150 KB usually can. Of all the levers available for LCP, compressing and correctly sizing the hero is normally the largest and the cheapest.

It is worth being precise about the mechanism: the ranking factor is the speed, not the compression. Compression is simply where the speed usually is. Serving a correctly sized image matters just as much — a 4000px file displayed at 800px is slow even when it is well compressed, which is why the presets set dimensions rather than only quality.

The share preview is a separate file with its own size, and it is the one people forget: the Open Graph generator writes the tags that point at it once you have a compressed version to link to.

Two more things that cost nothing once the file is small: set explicit width and height so the browser reserves the space and the layout does not shift, and use loading="lazy" on anything below the fold.

Every other compressor of this kind sends your images to a server, compresses them there, and sends them back. That is a reasonable engineering decision and a poor privacy one: photographs carry GPS coordinates, faces, documents, screenshots of things not meant to be seen, and once a file has been transmitted you are trusting a policy rather than a mechanism.

This tool does the work in your browser instead — the canvas API to decode and re-encode, a Web Worker so the page stays responsive while it happens. Your images never leave the device. The claim is easy to check: load the page, disconnect from the network, and carry on compressing. It will keep working, because there was nothing on the other end of a connection to begin with.

What happens to the metadata

Re-encoding through a canvas discards everything except the pixels, so EXIF does not survive: camera model, lens, exposure, timestamps and GPS coordinates are all gone from the output. That is the desired outcome — a photograph published with its location attached is a common and consequential accident.

The single exception is the orientation tag, which is read before anything else happens and applied to the pixels themselves. That is why a phone photograph comes out the right way up here, and why it stays that way afterwards: the rotation is in the image rather than in a tag that the next piece of software may or may not honour.