A free image compressor that runs entirely on your device. PNG and WebP come back pixel-identical via oxipng and libwebp; JPEG is re-encoded with MozJPEG and labeled visually lossless. Batch up to 200 files, download them as a ZIP, and keep every original byte on your machine — no upload, no account, no credits.
機能のスナップショット
0
files uploaded
200
images per batch
3 formats
PNG, JPEG, WebP
実際の制作ワークフローにマッピングされた実践的な価値。
メリット
01
Lossless where it is actually lossless
PNG and WebP are re-encoded losslessly, so the decoded pixels are identical to what you put in. JPEG cannot be losslessly recompressed in a browser, so we say visually lossless instead of pretending otherwise — and strict mode leaves JPEGs untouched.
メリット
02
Private because of how it is built
The encoders are WebAssembly builds running in a worker on your machine. There is no upload step to opt out of, and once the page has loaded it keeps working offline.
メリット
03
Batches that behave
Drop up to 200 images at once and take them back as a single ZIP. Files that are already well compressed are returned untouched rather than re-encoded into something bigger.
ソース素材から再利用可能な結果までのシンプルな 3 ステップのパス。
ステップ 1
Drop your images
Add PNG, JPEG, and WebP files — one image or a whole export folder.
ステップ 2
Compress on your device
Parallel workers run the WASM encoders. PNG and WebP are always rewritten losslessly; JPEG re-encodes at quality 85 unless you switch on strict lossless mode, which passes JPEGs through untouched.
ステップ 3
Download and check the numbers
Every row shows the before size, the after size, and whether that file was lossless, visually lossless, or already optimal. Save one file or grab the whole batch as a ZIP.
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.