Target sizeQuick pick
Drop photos here
or click to browse — JPEG, PNG and WebP, any number of files
Type the size you need — 200 KB, 1 MB, 5 MB — and the quality is searched until the file fits.
Your files never leave your browser — all processing is local.
Drop photos here
or click to browse — JPEG, PNG and WebP, any number of files
Almost nobody wants "quality 74". What people want is a photo that gets past the upload form: the box says 2 MB, the file off the phone is 5.4 MB, and the job is to make one number smaller than the other without the picture falling apart. So target size is the headline mode here. Type the limit — 200 KB, 2 MB, whatever the form demands — and the quality setting is worked out for you: the tool encodes at a first guess, measures the real byte count of the result, then halves the remaining range and encodes again, closing in from both sides until it lands just under your number. That is a binary search over the quality parameter, it usually settles in four to six rounds, and every round is a genuine encode being weighed rather than a size estimate. Dragging a slider by hand is the same search, done slower and with worse arithmetic.
By default the format stays put: JPEG in, JPEG out, PNG in, PNG out — the result drops straight back into wherever the original came from, same extension, no compatibility surprises. When you do want to know what changing format would buy, switch on the comparison and the same image is also encoded to WebP and AVIF, with all three sizes side by side at the quality that hit your target. The gap is usually real, and so are the trade-offs: WebP is safe everywhere that matters now, while AVIF often wins on size by a wide margin but encodes far more slowly — seconds for a large photo, not milliseconds — and older software, some desktop image viewers and a few CMSes still cannot open it. Read the numbers, then choose with the destination in mind.
Drop in a folder's worth of images and the whole batch runs in one pass, each file showing its size before, its size after, the quality that got there and the percentage saved, with one big total for the batch at the top. All of it happens in your browser: files are read locally, encoded in a Web Worker and handed back as ordinary downloads. Nothing is uploaded, which is the privacy answer, but on this page it is the speed answer too — a server-side compressor has to push every image up and pull every result back down, so a twenty-image batch means forty network transfers before a single byte gets compressed. Here there is no round trip to pay for, the only ceiling is your own machine, and the page keeps working with the network switched off.
One thing to be straight about: this is lossy re-encoding. The image is decoded to pixels and encoded again at a lower quality, so pixels do change — that is exactly where the saved kilobytes come from, and it is why a 12 MP photo squeezed to 100 KB looks softer than the same photo at 800 KB. If what you want is a smaller file with the pixels untouched, the metadata remover is the right page instead: it cuts the EXIF, GPS and thumbnail blocks out at byte level without ever handing the image to a decoder, so the output is bit-identical and a few kilobytes to a few hundred lighter. That is the entire saving available losslessly, so it will not get a 5 MB photo under 2 MB — but if a couple of hundred kilobytes was all you needed, take the free one first and come back here only if it fell short.
Not 80% of anything — not of the pixels, not of the original file size, not of some absolute notion of quality. For JPEG the number picks a set of quantisation tables, which decide how aggressively the fine detail in each 8×8 block is rounded off; for WebP and AVIF it steers an equivalent knob in that codec. The scale is the encoder's own, so quality 80 out of one encoder is not the same picture or the same size as quality 80 out of another, and the same 80 applied to a noisy night shot and a flat screenshot produces wildly different file sizes. That is the whole reason target-size mode exists: the only number that means anything across images is the size of the file that came out, so this tool measures that instead of asking you to trust the dial.
Because you are paying for a second generation of loss on top of the first. A JPEG is already the decoder's reconstruction of the original, artifacts and all. Compressing it means decoding that reconstruction and quantising it again — this time with the previous round's block edges and ringing treated as real detail worth preserving, which is the worst possible use of the bit budget. Do it repeatedly and you get the familiar mush around edges and text. So when you have the original — the camera file, the PNG export, the master out of your editor — compress from that in one step rather than re-squeezing something already squeezed. If you only have the JPEG, one careful pass to a target size is fine; what does the damage is five passes.
No. Re-encoding goes through a canvas, which knows about pixels and nothing else, so the output carries no EXIF at all — no GPS coordinates, no camera model, no timestamps, and no embedded thumbnail. For most people that is a bonus rather than a loss, and it means a compressed photo is also a stripped photo. But if metadata is the only thing you wanted gone, do not compress for it: the metadata remover deletes those blocks at byte level and leaves your pixels bit-identical, which is a strictly better deal than trading a generation of quality for the same result.
Because PNG is a lossless format — there is no quality dial in the format to turn. Every pixel is stored exactly, so the only way to make a PNG smaller is to store the same pixels more cleverly or to store fewer distinct pixels. This tool does the first only: oxipng re-runs the filtering and Deflate choices to find a better encoding of the identical image, so what comes back is the same picture in fewer bytes. It does not reduce the palette — dropping colours is a lossy edit, and doing that silently to a format you chose because it is lossless would be the wrong default. The wins are smaller and less predictable than JPEG's — a screenshot of flat UI can halve, a photograph saved as PNG barely moves. If a photo-like PNG has to hit a hard size target, the honest answer is to convert it to JPEG or WebP, and this page will show you what that would cost.
The search runs out at the bottom of the quality range and the tool tells you so, reporting the smallest file it managed instead of silently handing back something over your limit. A 4000×3000 photo cannot become a 20 KB JPEG that anyone would want to look at — at that point quality is not the lever any more, pixel count is. Scale the image down first (a 1600 px wide version of the same photo needs roughly a sixth of the bytes) and try again, or switch the output to WebP or AVIF, which will reach a given size at a visibly better quality than JPEG. The comparison view exists so you can see which of those two moves actually gets you there.
No. Files are opened with the File API, decoded and re-encoded inside a Web Worker in your own tab, and returned as downloads your browser generated. This page is a static file with no API behind it, so there is nowhere to upload to, no queue to wait in, no watermark, and no file-size cap beyond your machine's memory. It also keeps working offline once loaded — which is a fair test of the claim, since a page that needed a server would stop working the moment the network went away.
Need a different format, not just a smaller file? Convert here.
Only want the metadata gone with the pixels untouched? Strip it losslessly.
Compare the compressed output against the original, pixel by pixel.