What this does
Every image you put on the web is a trade between how it looks and how long it takes to arrive. This tool lets you make that trade deliberately: drop in a JPEG, PNG or WebP, choose a quality or a byte budget, and download the result. The before and after sizes sit next to a live preview, so you can see what a given saving actually costs.
The compression happens on your machine, in your browser, using the same engines the industry uses everywhere else: mozjpeg for JPEG, libwebp for WebP and oxipng for PNG, compiled to WebAssembly and downloaded to your device the first time you use the tool. Your image is never uploaded, which is not a policy claim but an architectural one: there is no server that could receive it. The FAQ explains how to verify that in the network panel rather than take our word.
One thing this tool deliberately does not do is change the format. A JPEG goes in and a JPEG comes out. Converting between formats changes what the file is, and that decision deserves its own tool rather than a checkbox surprise.
How to use it
- Drop an image onto the tool, or choose one from your files. JPEG, PNG and WebP are detected from the file’s own bytes, so a mislabelled extension does not matter.
- For a JPEG or WebP, adjust the quality slider and release it. Each release re-encodes, and the preview and the size line update to match. PNG has no slider: it is optimised losslessly the moment it lands.
- If what you actually have is a size limit, type it into the “fit under” box and press “Find best fit”. The tool searches for the highest quality that stays under your number.
- Press download. The file is named after the original, so photo.jpg comes back as photo-compressed.jpg.
Hitting an exact size
Upload forms with hard limits are where image compression stops being abstract: an application portal that refuses anything over 500 KB does not care how the photo looks, only what it weighs.
There is no formula that predicts a JPEG’s size from a quality setting. The only way to know what an image weighs at quality 62 is to encode it at quality 62 and look. So that is what the tool does: it encodes at a quality, checks the size against your budget, and halves the search space each time, the same way you would find a number in a sorted list. The 1 to 100 scale takes at most seven encodes to search exhaustively, each attempt is remembered rather than repeated, and the answer is the highest quality whose measured size fits. If even the lowest quality cannot get under your budget, the tool says so plainly instead of handing you a file that misses the brief; that usually means the image’s pixel dimensions are the real problem, and resizing, not recompressing, is the honest fix.
Why the same quality gives different sizes
Quality 75 might turn one 4 MB photo into 400 KB and another into 900 KB. That is not the tool being inconsistent; it is the images being different. JPEG and WebP spend their bytes on detail: edges, texture, noise. A photo of fog is cheap at any quality. A photo of gravel is expensive at every quality. This is also why the target-size search exists: because size at a given quality is a property of your particular image, discoverable only by encoding it.
Two practical consequences are worth knowing. First, sharpening and grain effects make files bigger at the same visible quality, because the encoder faithfully spends bytes describing the noise. Second, re-compressing an already-compressed image compounds the artefacts of both passes, so when you can, compress from the original rather than from a previous compression.
Measured results
The defaults in this tool now stand on our own benchmark run rather than on habit, measured with the same WebAssembly encoder builds this page runs in your browser, over a fixed 29-image corpus. On photographs, quality 75 averaged 1.1 bits per pixel; 85 cost half as much again; 95 cost 3.3 times as much for a difference in SSIM of five hundredths. The full curves, the per-image data and the method are on the JPEG quality settings page, and the measured case for switching formats entirely is on WebP vs JPEG. The PNG optimiser’s effort level is measured on the same corpus: see below.
What happens to a PNG
PNG is lossless, and this tool keeps it that way: every pixel of the output is identical to the input, by construction rather than by luck. The optimiser, oxipng, works by trying smarter ways to describe the same pixels, reordering filters and recompressing the stream, so the saving depends entirely on how well the file was packed in the first place. The effort level it runs at is a measured choice: on our corpus, level 2 captured 8.1 of the 8.9 percentage points of saving available, and the levels above it bought the remainder for up to seven times the wait; the full table is published with the rest of the benchmark data. Exports from design tools and screenshots often carry easy savings; a PNG that has already been through an optimiser will barely move, and the tool will honestly tell you when the result is no smaller.
If the PNG is a photograph, no lossless repack will rescue it: photographic detail is what lossy formats exist for, and the same picture as a JPEG at quality 80 is routinely a fifth of the size. A format converter is the right tool for that job, and one is on this site’s roadmap.
Limitations
It is not a resizer. Compression changes how pixels are stored, not how many there are. If an image is 6000 pixels wide and the place it is going displays 800, the biggest saving available is the image resizer, and no quality setting substitutes for it.
Animated WebP is not supported. The tool works on still images; an animation will be refused rather than silently flattened to its first frame.
Metadata handling is a side effect, not a promise. Lossy re-encoding drops EXIF data, including GPS coordinates, but PNG optimisation preserves metadata. If removing metadata is the goal, use the EXIF remover, whose whole job that is.
Large images take real time. The encoders run single-threaded on your device, so a 40-megapixel photo can take a few seconds per attempt, and a target-size search multiplies that by up to seven. The page stays responsive while it works; the work is real, it is just happening on your hardware rather than someone else’s.