Image Compressor

Compress an image to a target file size, in the browser

Most compression tools give you a quality slider and leave you to guess. This one works the other way round: you say how big the file is allowed to be — 200 KB, 2 MB, whatever the form you are fighting with demands — and the tool finds the highest quality setting that fits underneath that number. That is usually the actual problem. Nobody wakes up wanting quality 71; they want a photo under the 5 MB limit on a job application with as little visible damage as possible.

Drop your images in, type a target size, pick KB or MB, and press Compress. Everything happens locally: files are decoded, re-encoded and downloaded inside your browser, with no upload and no server-side copy. Up to 100 MB per file, and you can queue a batch. JPEG, PNG, WebP, GIF, BMP, AVIF, TIFF, HEIC and ICO files are accepted as input, subject to your browser being able to decode them — HEIC in particular decodes on some platforms and not others.

How it hits the number

The tool runs a binary search over the encoder's quality parameter. It encodes at a mid-point quality, measures the resulting bytes, and moves the search window up or down depending on whether the result came in under your target — converging over a series of passes on the highest quality that still fits. It reports the quality it settled on for each file, so you can see how hard it had to work.

This matters because the relationship between quality and file size is not linear and is different for every image. A flat studio shot on a white background might reach 200 KB at quality 90; a detailed forest photo of identical dimensions might need quality 45 for the same target. A single fixed quality setting applied to a mixed batch will overshoot on some files and needlessly damage others. Searching per image is what makes a byte target achievable without over-compressing the easy ones.

When quality alone is not enough

Sometimes there is no quality setting that gets a file under the target. A 24-megapixel photo cannot be squeezed into 50 KB by quality reduction alone — there are simply too many pixels, and even at the encoder's floor the file stays too large.

For that case there is an "allow dimension resize" option, on by default. When quality alone fails, the tool reduces the pixel dimensions in steps and retries the quality search at each smaller size, stopping as soon as a result fits. A companion slider sets how far it is allowed to go, from 100% of the original dimensions (never resize) down to 25%. Any file whose dimensions were changed is flagged in the results, and the output dimensions are shown next to the original ones, so a resize never happens silently.

Which lever you should prefer depends on the job:

• Turn resizing off when the pixel dimensions are the point — a print file, an image that must match an exact spec, a screenshot where the layout matters. You may then not reach the target, and the tool will tell you what it managed.
• Leave resizing on for photos headed to the web or to a form. A 4000 px-wide photo displayed 800 px wide is carrying detail nobody will ever see; halving the dimensions removes roughly three quarters of the pixels and is far less visible than driving quality into the floor. When a target is aggressive, resizing usually looks better than heavy quality reduction of the full-size image.

Lossy and lossless, and why the format you keep changes the answer

Compression comes in two kinds, and the difference decides what is achievable.

Lossless compression rewrites the data more efficiently and reconstructs the original pixels exactly. PNG is lossless: it predicts each pixel from its neighbours, stores the difference, and DEFLATE-compresses the result. Nothing is discarded, which is why it is right for screenshots, logos and anything you will edit again — and why its file sizes are not negotiable. There is no quality dial in PNG. The browser's PNG encoder takes no quality parameter at all.

Lossy compression discards information your visual system is least likely to miss, and cannot get it back. JPEG and WebP both work this way, transforming the image in small blocks, keeping the coarse structure and throwing away fine high-frequency detail, and storing colour at lower resolution than brightness because the eye is more sensitive to brightness. This is where large savings live.

The practical consequence: if you keep PNG output, the only way this tool can reduce the file is by making the image smaller in pixels. If you are targeting a demanding size and the format is PNG, either enable resizing or accept that the target will not be met. The format dropdown offers "same as input" (the default), JPEG, PNG or WebP, but format choice is a decision about the destination, and the byte target is what this page is really for.

What actually drives file size

Understanding this makes targets realistic instead of arbitrary. Four things dominate.

• Pixel count. Width times height, and it scales quadratically — halving both dimensions leaves a quarter of the pixels. This is the biggest single lever and the one people forget. Most images sent by email or uploaded to a website are several times larger than they will ever be displayed.
• Detail and noise. Lossy encoders spend bits on variation. Foliage, gravel, fabric texture, hair, film grain and high-ISO sensor noise are all expensive; a clear sky, a plain wall or a studio backdrop is cheap. Two photos with the same dimensions and quality setting can differ several-fold in size purely because of content. Denoising a grainy photo before compressing it can shrink the result substantially.
• Quality setting. The knob the search is turning. Its effect is steep at the top — the difference between the maximum setting and something slightly below it is often a large fraction of the bytes for very little visible change — and shallow at the bottom, where further reductions cost a lot of quality for few bytes.
• Format and encoder. WebP generally reaches a given visual quality in fewer bytes than JPEG. PNG on a photograph is enormous. And quality numbers are not comparable across encoders: quality 80 in your browser, in a desktop editor and in a command-line tool are three different things.

Metadata is a smaller factor but not nothing. Re-encoding through a canvas produces a clean file with no EXIF block, so camera settings, timestamps, editing history and any embedded GPS coordinates are dropped. That is a genuine privacy benefit when posting photos publicly, and something to be aware of if you were relying on the metadata for cataloguing.

Choosing a target

Some starting points, to be adjusted by looking at the result rather than trusting the number:

The target box accepts fractional values, so a 500 KB goal can be entered as 500 KB or 0.5 MB. Note that KB and MB here are the binary units your operating system usually reports, which is why a "1 MB" output may show as slightly over 1,000,000 bytes elsewhere — leave a little headroom against a hard limit.

Telling when compression has gone too far

The output is not a mystery you have to accept. Each completed file opens a before-and-after comparison with a draggable divider, and you can zoom in to inspect the image at the pixel level and pan around while zoomed. Compression artefacts are frequently invisible at fit-to-screen size and obvious at 400%, so judging at full-page scale is how people ship images that look bad on someone else's monitor.

What to look for, in the order it usually appears as quality falls:

• Ringing. A faint halo or ripple hugging high-contrast edges — text against a plain background, a branch against the sky. Usually the first thing to show.
• Blocking. Smooth gradients breaking into visible square tiles. Skies, studio backdrops and out-of-focus backgrounds show this first, because the eye is very good at spotting a discontinuity in a smooth ramp.
• Colour bleed. Saturated colour smearing past its boundary, worst on reds. A consequence of colour being stored at lower resolution than brightness.
• Loss of fine texture. Skin turning waxy, fabric weave flattening, foliage becoming mush. Insidious, because it does not look like an artefact — it just looks like a worse photo.
• Banding. Concentric steps in what should be a continuous gradient.

Two sanity checks. Compare at the size the image will actually be viewed — artefacts that vanish at display size are not worth spending bytes on. And check the reported quality figure: if the tool had to drop very low to reach your target, either the target is unrealistic for that image or the image should be resized instead.

Things worth knowing before you compress

• Always keep the original. Lossy compression is irreversible, and a compressed file cannot be restored by re-saving it at high quality. Treat compression as an export step.
• Do not compress the same file repeatedly. Every lossy save discards a fresh round of detail on top of what has already gone. Go back to the master and compress once.
• The file is always re-encoded. Even if a file is already under your target, it is decoded and encoded again rather than passed through untouched. For a source that is already a lossy JPEG or WebP, that is another generation. If a file already meets your requirement, leave it alone.
• Compress last. Crop, rotate, colour-correct and resize first; compression should be the final step before the file leaves your hands.
• Animation is not preserved. An animated GIF or WebP is captured as a single frame.
• Batches share one target. Every queued file is compressed to the same setting; images with different requirements need separate runs.
• "Download All" saves files individually rather than as a ZIP, with a short pause between each. Browsers may ask permission the first time a page saves several files at once. Output names get a -compressed suffix and the extension of the chosen format.

And the question everyone asks first: no, your images are not uploaded. Decoding, the quality search, any resizing and the download all run in your browser. Once the page has loaded, the compression works with the network disconnected, which is the reassuring test if you are handling photographs you would rather not post to a stranger's server.