ZipPic

I Stopped Uploading Client Photos to Online Tools. Here's What I Use Instead.

zippic — Wed, 21 Oct 2026 22:37:53 GMT

If you handle client photos — real estate shoots, product photos, headshots, unreleased designs — every "free" online compressor asks you to do something you probably shouldn't: upload someone else's files to a server you don't control.

I used to do it too, because it was fast. Then a client asked, point blank: "Where do these photos go when I compress them?" I didn't have a good answer.

So I built the tool I wanted to exist.

ZipPic runs 18 media tools entirely in your browser with WebAssembly. Compression, bulk compression, HEIC to JPG, PSD to images, PDF to images, GIF and APNG makers, video tools, doc compression — all of it happens on your device. Nothing uploads. Open the Network tab while you work and check: zero bytes leave your browser.

That changes the workflow in three practical ways:

No caps to work around. TinyPNG stops you at 20 images and 5MB per file. A real estate shoot or a Shopify product batch blows past that in minutes. Local processing has no batch limit to hit.
No waiting on uploads. A 50MB PDF or a folder of RAW-adjacent phone photos doesn't need to go up to a server and back down again. It just processes.
No awkward client conversation. You can honestly say the files never left your machine.

It's free, no signup, and it works offline after the first load. That last part matters more than I expected — I've compressed photos on planes and in cafes with bad Wi-Fi.

I'm not saying never use a server tool. If you need heavy AI upscaling or team collaboration, a server makes sense. But for compress, convert, crop, watermark, and split — the everyday jobs — local is faster, more private, and has no reason to cap you.

Try it and check the Network tab. That's the whole pitch: https://zippic.app

(Disclosure: I'm the developer.)

ZipPic vs Squoosh: The Three Jobs Squoosh Can't Do

zippic — Tue, 20 Oct 2026 14:00:36 GMT

Squoosh is a genuinely good tool. If you want to squeeze one hero image and compare AVIF against WebP against MozJPEG with a side-by-side preview and fine-grained codec settings, it's still one of the best pages on the internet for that.

But most image work isn't one hero image. It's a folder of product photos. It's a GIF that's 12MB. It's an animated WebP banner. And on those three everyday jobs, Squoosh simply can't help you — not "does it worse," but doesn't do it at all. I checked each one against Squoosh's app and its GitHub repo before writing this.

1. Batch compression: one image at a time, forever

Squoosh's editor loads exactly one image. There is no multi-file upload, no queue, no "download all." Fifty screenshots means fifty rounds of open → compress → download.

This isn't an oversight that got fixed. Users have been requesting batch support since 2018 (the GitHub issues are still open), and the maintainers' answer at the time was to use the Squoosh CLI instead — which has since been deprecated.

ZipPic's bulk image compressor is built the other way around: drop in as many images as you like (there's no strict count limit; files under 50MB each are recommended), let it process, and hit Download All to get everything back as a single ZIP. JPG, PNG, WebP, GIF, AVIF, HEIC and even RAW files are accepted, and like Squoosh, everything runs locally in your browser — nothing is uploaded to a server.

2. GIF: Squoosh can't output one — and destroys animated ones

Open Squoosh's format dropdown and you'll find AVIF, MozJPEG, OxiPNG, WebP, WebP v2, JPEG XL (beta), QOI and the browser codecs. No GIF. Squoosh cannot save a GIF file, compressed or otherwise.

Worse, if you open an animated GIF in Squoosh, you don't get a smaller GIF back — you get the first frame as a still image. The animation is gone.

In ZipPic, GIF is a first-class format: the compressor takes GIFs in and gives compressed GIFs back, animation intact. And when a GIF needs more than compression — trimming frames, adjusting delays, reordering — there's a dedicated GIF Maker for creating and editing animated GIFs locally.

3. Animated WebP: flattened to frame one

Animated WebP is where this gets painful, because it's the format people reach for precisely to replace heavy GIFs. Squoosh doesn't preserve it. As its own maintainer put it in the repo: Squoosh doesn't "support animation at all" — open an animated WebP and only the first frame survives, converted to a static image. The same applies to animated AVIF.

ZipPic's compressor lists Animated WEBP as an output format. Feed it an animated WebP and you get a smaller animated WebP back, still moving. Feed it an animated GIF and you can convert it to animated WebP instead — usually the single biggest saving available for web animations, since WebP typically cuts 60–80% off a GIF's size at similar quality.

The honest summary

Job	Squoosh	ZipPic
Single image, deep codec tuning (AVIF, JPEG XL, QOI)	✅ Excellent	✅ Good
Batch-compress many images at once	❌ One at a time	✅ Unlimited batch + ZIP download
Compress a GIF	❌ No GIF output	✅ GIF in, GIF out
Compress an animated GIF / WebP, keeping the animation	❌ First frame only	✅ Animated WebP / GIF output
Runs 100% locally, no upload	✅	✅
Price	Free	Free

Squoosh remains a superb single-image codec laboratory, and I still use it that way. But the moment your job involves many images, a GIF, or anything that moves, you need a tool that actually does those jobs — that's the gap ZipPic was built to fill.

Disclosure: I build ZipPic. Every Squoosh limitation above is verifiable in the live app and the public squoosh repo on GitHub — check for yourself before you trust either of us.

Your PNG Screenshots Are 5x Bigger Than They Need to Be

zippic — Mon, 19 Oct 2026 03:32:52 GMT

I published a tutorial last month with 14 screenshots. After it went live, I checked the page weight out of curiosity: 38MB. Thirty-eight megabytes — for a page that is mostly text.

Every screenshot was a PNG, straight from my Mac's screenshot tool. A single full-screen Retina capture was 4.2MB. I had uploaded them exactly as they came out of the OS, the way most of us do.

Why screenshots are so heavy

Three things conspire against you:

Retina resolution. A screenshot on a modern display is 2x or 3x the CSS pixels. That 1440px-wide illustration in your article is actually a 4320px-wide PNG.
PNG is lossless. Great for crisp UI text, terrible for file size. Any photo-like gradient or shadow in the shot balloons fast.
Nobody compresses before uploading. Platforms will happily serve your 4MB original to every single reader.

The kicker: after compression, my 4.2MB screenshot came out at 380KB — and I could not tell the difference at article width. The detail PNG preserves is detail no reader will ever see, because the image is displayed at a fraction of its native resolution anyway.

The 30-second fix

I don't hand-tune screenshots anymore. My workflow now:

Take the screenshot as usual — PNG, full Retina glory.
Drop it into ZipPic's image compressor — free, runs entirely in your browser, no signup, no upload.
It compresses locally and shows a live before/after comparison. Nudge the quality slider until the text edges still look crisp.
Download, then upload the compressed version to your post.

That 14-screenshot tutorial went from 38MB to under 5MB. Load time went from "go make coffee" to instant — and every reader on mobile data got a faster page for free.

The part nobody thinks about: what's in the screenshot

Screenshots are uniquely sensitive uploads. Open tabs, file paths, a Slack DM in the background, an API key sitting in a terminal window you forgot was visible. Every "free online compressor" that asks you to upload a screenshot is asking you to hand all of that to a stranger's server first.

I started compressing locally for the file size. I keep doing it for the privacy. Nothing leaves your machine — the work happens in your browser via WebAssembly, and the file you download is the only copy that ever moves.

Next time you write a tutorial, try this: take one PNG screenshot, run it through a local compressor, and compare them side by side at article width. If you can't spot the difference — and you won't — there's no reason to ever upload the original again.

That 50MB PDF You're Trying to Email? It Could Be 3MB.

zippic — Sun, 18 Oct 2026 08:55:32 GMT

Last week I tried to send a scanned contract over email. 47MB. Gmail's attachment limit is 25MB. The client's upload portal capped at 10MB. I ended up splitting it into five parts like it was 2004.

The file was 40 pages of mostly text with a few scanned signatures. There was no reason for it to be 47MB — except that whoever scanned it saved every page as a full-resolution image with zero compression.

Why PDFs get so fat

Most bloated PDFs come from the same source: scanned pages or exported slides where images were embedded at far higher resolution than anyone will ever view. A scanned page at 600 DPI looks identical to one at 150 DPI on screen, but takes 4x the space. Multiply by 40 pages and you're emailing a small movie.

The traditional fix is Adobe Acrobat's "Reduce File Size" — if you have a subscription. Or one of those free online PDF compressors, where you upload your contract (with signatures, account numbers, whatever) to a stranger's server and hope for the best.

I wasn't comfortable with either option for client documents.

Compress it where it already is

PDF compression is just image recompression plus metadata cleanup — the kind of thing a browser can do locally with WebAssembly. No server needed, which means your documents never leave your machine.

Here's what I do now:

Open ZipPic's document compressor — free, runs entirely in the browser, no signup.
Drop in the PDF. It handles the parsing locally.
Pick a compression level. For screen reading and email, the middle setting is usually plenty — my 47MB contract came out at 3.1MB with no visible difference.
Download the result. Nothing was uploaded anywhere.

That 3.1MB file sailed through Gmail and the client portal without a second thought.

The files you should never upload

Here's the thing I keep coming back to: the documents that most need compressing are exactly the ones you least want to upload. Contracts, financial statements, medical records, unreleased specs — the "please compress this 80MB PDF" request almost always involves something sensitive.

We've normalized uploading these to random free tools because there wasn't a convenient alternative. Now there is. Your browser is fast enough to do it locally, and the result is identical.

Next time a PDF won't fit through email, try compressing it without the upload step first. Your documents — and whoever's waiting on them — will thank you.

I Compared ZipPic and TinyPNG Head-to-Head. Here's What I Found

zippic — Thu, 15 Oct 2026 09:03:56 GMT

I build and run ZipPic — 18 free media tools that run 100% in your browser, nothing uploaded. TinyPNG is the name everyone knows in image compression, so I decided to put the two side by side and measure honestly: UI limits, actual compression numbers, and privacy.

The limits you'll hit first

TinyPNG has a clean UI and batch support, but with hard caps: max 20 images per batch, 5MB per image. Fine for a quick job; annoying when you're processing a full asset folder or files from a camera.

ZipPic has no cap on batch count or file size. Dozens of images, files over 5MB — same flow. This was a deliberate design choice: I kept hitting TinyPNG's 20-file wall myself.

Actual compression numbers

I took the same 2MB PNG and ran it through both tools, outputting PNG, JPG, and AVIF:

Format	TinyPNG	ZipPic
PNG (keeps transparency)	649 KB	409 KB
JPG	223 KB	115 KB
AVIF	59 KB	41 KB

Visual quality was comparable in all three rounds — ZipPic just squeezed harder. The JPG result (nearly 50% smaller) is the one that matters most for web publishing.

Privacy: local vs. upload

This is the biggest architectural difference:

ZipPic compresses locally in your browser via WebAssembly. Your images never leave your device — no upload, no server copy, works offline after first load.
TinyPNG uploads your images to its servers, processes them, and sends them back. They say files are deleted afterwards, but if you handle client work, design drafts, or personal photos, "trust us" is a weaker guarantee than "it never left your machine."

My honest take

TinyPNG is a solid tool — simple, reliable, and fine for small batches of lightweight images. If that's your whole workflow, you don't need to switch.

But if you regularly hit the 20-file/5MB ceiling, care about squeezing every kilobyte (that JPG gap is real), or would rather your images never touched a server, ZipPic is the better fit. It's free at zippic.app — no signup, no upload limits, 18 tools, 11 languages.

Disclosure: I'm the developer of ZipPic. The numbers above are from my own tests — run your own and see.