Compress images without uploading them

What this compressor actually does

Most online compressors work the same way: your file is uploaded, passed through a fixed preset such as "quality 80", and sent back. That preset has no idea what your image contains, so a smooth sky and a photo of tree branches receive identical treatment — one ends up unnecessarily large, the other unnecessarily degraded.

This tool inverts the process. Your image is analysed first, then encoded to fit the evidence. It is the same strategy used by professional build pipelines, running in a browser tab you can close at any time — and entirely on your own hardware, so nothing is uploaded. In plain terms: you drag in a file that is too large for the form, the email or the storage quota, and you get back a file that is smaller — same picture, fewer bytes, no round trip. If you want to check that rather than believe it, the compress without uploading page walks through a ten-second test you can run on any tool, including this one.

The five things that make the output smaller

1. Measured quality instead of a fixed preset. A small proxy is encoded at several quality levels and decoded again; each result is scored against the original using PSNR. The engine keeps the lowest quality that still clears a 40 dB fidelity floor, with headroom so the full-resolution encode stays there too.
2. Quality-aware format selection. Opaque photographs stay in a photographic codec; graphics with flat colour and few unique tones stay in PNG, where lossless and palette encoding win outright. Across our own measurements AVIF lands about a quarter below MozJPEG at equal measured fidelity, while WebP comes out roughly level with it.
3. Palette quantization for PNG. Screenshots, diagrams and flat illustrations rarely need 16.7 million colours. A median-cut quantizer reduces them to 256 (or fewer) with optional Floyd–Steinberg dithering, then writes a true indexed PNG — typically 70–90% smaller with no visible banding.
4. Iterative halving when downscaling. Shrinking a 6000 px photo to 1600 px in one step aliases badly. Halving repeatedly and smoothing at each stage preserves edge structure, which in turn lets the encoder spend fewer bits on the same perceived quality.
5. Metadata removal. EXIF blocks, thumbnails embedded inside the file, GPS traces and maker notes can add tens of kilobytes on their own. They are dropped, while the orientation tag is applied to the pixels first so nothing ends up sideways.

When the file is already as small as it gets

Compression has a floor, and most people meet it as a complaint: they run the tool twice, the second time does nothing, and the tool is called broken. It is not. A first pass removes the bytes a codec can describe more cheaply; the second pass is then handed a file whose bytes are already close to as random as they need to be, so there is almost nothing left to find. Measured on this engine, three photographs at 2400 × 1600 were encoded three times each at the same setting: they went from 1,368,828 bytes to 1,368,713 bytes — 115 bytes across all three.

What should happen next is that the tool says so. This one labels the result already optimal and, when a re-encode would come back bigger than the original, hands you the original file you uploaded — the same bytes you dropped in, not a copy that lost quality and gained nothing. The why your image won't get smaller page walks through that measurement, the three things that usually hold a file up, and the three levers that do move the number.

The complaints that bring people here are all the same complaint, phrased a different way each time: the image is not getting smaller, or it doesn't get smaller on the second try, or the file came back bigger than the original — bigger than before, in other words — or the copy it hands back barely got smaller, or the last pass only came out barely smaller than that, or nothing moves at all when you run it again and compress it again a third time. When a tool has to send the file to a server first, the original bytes come back as somebody else's copy from a random server, and the file you end up holding is not quite the one you chose. None of that is what happens here. Your photo never travels anywhere, and the tool will keep the original whenever a pass cannot improve on it. The why your image won't get smaller page walks through that measurement, the three things that usually hold a file up, and the three levers that do move the number. It also collects the complaints people make about batch work: a media library of several thousand images is not something you do by hand, one at a time, there is no daily limit, and there is no cap on how many files you bring and no account.

Choosing a strategy

Which output format should you pick?

Measured results

Most compressors quote a savings figure and leave it at that. These are the numbers this engine actually produced on our own test set, dated and with the method written out below, so the claim can be checked instead of taken on trust. Every value is a real encode by the page you are reading — the sizes were produced by the encoders, not estimated.

Auto mode: what actually comes out

† Averaged over the images that changed; the others came back untouched, which is what the 0% means. A photo that is already well optimised cannot be improved at this fidelity, so the engine returns your original file rather than a larger one. The range in brackets is the spread across the individual test images. PNG output is a separate strategy — palette quantization trades colour depth rather than applying the lossy fidelity floor — so its dB figures sit outside that floor by design.

At equal fidelity, is WebP really smaller than JPEG?

The usual figure is that WebP beats JPEG by 25–50%. We measured it rather than repeating it, by holding fidelity constant at 40 dB — the level this tool's own floor targets — and comparing the bytes each codec needed to get there. The result is more interesting than the slogan, and less flattering to WebP.

Two things explain the gap between this and the familiar claim. The first is the encoder: the 25–50% figure comes from comparing WebP against a baseline JPEG encoder, and MozJPEG — which is what this tool uses — is considerably stronger at high quality settings. The second is the metric: WebP's advantage is largest in perceptual measures such as SSIM and at lower quality settings, while this comparison is in PSNR, which is the definition our own fidelity floor uses. Neither of those makes WebP a bad format, and it remains the safest choice for compatibility. It does mean that AVIF is the one to pick when the smallest possible file is the goal, and that the honest headline for photographs is AVIF, not WebP.

How these numbers were produced

• Corpus. Three 2400×1600 photographs, each in three states: as an already-optimised JPEG, re-encoded at Q96 to stand in for a straight-from-camera file, and stored losslessly as a 3 MB PNG. Plus one 1440×900 interface screenshot generated in the browser so it is identical on every run. All files are pinned by SHA-256 and the measurement script prints every hash it used, so a changed encoder shows up as a changed hash rather than as a quiet shift in the table.
• Fidelity. PSNR on luma, measured the same way the engine's own quality search measures it, against the original pixels at full resolution.
• Encoders. MozJPEG (WebAssembly) for JPEG, the @jsquash builds for WebP and AVIF, and the browser's own canvas encoder plus this site's median-cut quantiser for PNG. A case that silently fell back to a browser-native encoder is never published as a WebAssembly result.
• Timing. Every case is encoded twice. The first pass pays for the codec download and WebAssembly instantiation, and only the second pass is reported — a cold-start number would misdescribe normal use.
• Environment. Chromium headless, Windows Server, Node 22. Output size depends only on the encoders and should hold anywhere; the timings depend on the machine and should be read as indicative.
• Reproduce. node _dev/measure-compression-matrix.cjs produces the first table, node _dev/measure-format-efficiency.cjs the second. Both drive the real engine in this page.

Known variance: AVIF is by far the slowest encoder here and its quality search can hit its patience budget on a loaded machine, so AVIF figures — especially the savings on already-optimised photos, which ranged from 0% to 37% across runs — are the least stable in the table. Measured 2026-09-20.

Frequently asked questions