Image Compressor

PNG and WebP are, exactly: oxipng and libwebp's lossless mode rewrite the file without touching a pixel, so the decoded image is bit-identical. JPEG is the honest exception — no browser-side lossless JPEG recompressor exists, so JPEGs are re-encoded with MozJPEG at quality 85 by default and labeled visually lossless. Turn on strict lossless mode and JPEGs pass through untouched.

No, and not as a policy choice — as an architectural one. The encoders are WebAssembly modules that run in your browser, so there is no server that could receive the file. You can verify it: load the page, go offline, and compression still works.

Not today. You control JPEG quality directly, but there is no "compress to 100 KB" target-size mode that searches for the setting which lands on a number. If you need an exact ceiling, compress and then check the resulting size in the file list.

Yes — it detects the real format from the file's magic bytes rather than trusting the extension, then routes it to the right encoder: oxipng for PNG, MozJPEG for JPEG, libwebp for WebP. Mixed batches are fine; each file takes its own path. Formats outside PNG, JPEG, and WebP are rejected rather than silently passed through.

Because they were already well compressed. When a re-encode cannot beat the input, the tool returns your original bytes and marks the row already optimal — it will never hand you a bigger file than you started with. Photos exported by a modern encoder often land here, which is the correct outcome, not a failure.

Up to 200 files per batch, and no limit on how many batches you run — there is no quota to consume because the work happens on your hardware, not ours. Very large images can still exhaust the browser's memory; if one fails, its row reports the failure and the rest of the batch continues.

No account, no sign-in, no credits, and no watermark. The pipeline has no branding step — what you download is your image, just encoded more efficiently.