This product was not featured by Product Hunt yet. It will not be visible on their landing page and won't be ranked (cannot win product of the day regardless of upvotes).
zipo.pics
Privacy&Fast Compress Images Without Uploading in browser
I built Zipo.pics because I kept running into the same annoying moment: I needed to compress an image, and every tool wanted me to upload it first.
Most of the time that's harmless. But every once in a while the image is a client's unreleased design, a contract scan, or just something personal — and uploading it to a server I don't control feels wrong for no good reason. The image doesn't need to go anywhere. Shrinking a file is a local operation.
So I built it to actually be local. The compression engine is Rust compiled to WebAssembly, running in a Web Worker. There is no upload step because there's no server in the loop — the bytes never leave the tab.
**Honest tradeoffs, since you'll notice:**
- We're not always the smallest output. Native tools with full C libraries (mozjpeg, oxipng) squeeze tighter. Both are unavailable to us — `wasm32-unknown-unknown` has no libc, so neither compiles. We use pure-Rust encoders instead. - AVIF is noticeably slower than WebP. It's an expensive codec and we're running it in your browser, not on a GPU farm. - Single-threaded worker for now.
What you get instead: nothing uploaded, no waiting on a round-trip, and no limit on file size or how many images you run.
Would love your feedback — especially on which formats you actually reach for. If AVIF slowness is a dealbreaker for your workflow, tell me, that shapes what I optimize next.
No comment highlights available yet. Please check back later!
About zipo.pics on Product Hunt
“Privacy&Fast Compress Images Without Uploading in browser”
zipo.pics was submitted on Product Hunt and earned 2 upvotes and 1 comments, placing #139 on the daily leaderboard. Privacy-first · fully in-browser Compress Images Without Uploading — Free In-Browser Image Optimizer Free in-browser image compressor to batch-shrink PNG, JPG, WebP and AVIF without uploading. Rust + WebAssembly runs 100% locally — reduce file size, keep quality, photos never leave your device.
zipo.pics was featured in Open Source (69k followers), GitHub (41.4k followers) and Photo & Video (2.1k followers) on Product Hunt. Together, these topics include over 52k products, making this a competitive space to launch in.
Who hunted zipo.pics?
zipo.pics was hunted by Richang Foo. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Want to see how zipo.pics stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Richang Foo
Hey Product Hunt 👋
I built Zipo.pics because I kept running into the same annoying moment: I needed to compress an image, and every tool wanted me to upload it first.
Most of the time that's harmless. But every once in a while the image is a client's unreleased design, a contract scan, or just something personal — and uploading it to a server I don't control feels wrong for no good reason. The image doesn't need to go anywhere. Shrinking a file is a local operation.
So I built it to actually be local. The compression engine is Rust compiled to WebAssembly, running in a Web Worker. There is no upload step because there's no server in the loop — the bytes never leave the tab.
**Honest tradeoffs, since you'll notice:**
- We're not always the smallest output. Native tools with full C libraries (mozjpeg, oxipng) squeeze tighter. Both are unavailable to us — `wasm32-unknown-unknown` has no libc, so neither compiles. We use pure-Rust encoders instead.
- AVIF is noticeably slower than WebP. It's an expensive codec and we're running it in your browser, not on a GPU farm.
- Single-threaded worker for now.
What you get instead: nothing uploaded, no waiting on a round-trip, and no limit on file size or how many images you run.
Would love your feedback — especially on which formats you actually reach for. If AVIF slowness is a dealbreaker for your workflow, tell me, that shapes what I optimize next.