Last year I was helping a friend list some furniture on a marketplace. She sent me the photos, I compressed them with one of those popular online tools — you know the ones, they're always the first Google result — and uploaded them to the listing. No big deal.
Except later that week, out of curiosity, I opened Chrome DevTools while using that same tool. Network tab. And I just watched. My 8MB photo of a bookshelf got shipped off to some server, processed, and sent back. I poked around a bit more and the requests were hitting an endpoint in what looked like US-East infrastructure. My photo of a scratched-up IKEA Kallax was now on a server in Virginia.
For a bookshelf photo, who cares. But I started thinking about all the other stuff I'd run through tools like that. Screenshots of contracts. Photos of my kid. A scan of my passport when I was in a rush. Every single one of those files hit someone else's server, sat in their memory (or disk, or object store — who really knows), and I just... trusted that they'd delete it?
That's what bugged me. Not some abstract privacy concern about browser-based image compression versus server-side tools. Just the simple fact that I had no idea what happened to those files after I clicked "compress."
So your photos are chatty
Here's something most people don't think about: your photos carry a surprising amount of baggage. EXIF data baked into the file can include the exact GPS coordinates where you took the shot, your phone model, the timestamp, sometimes even the direction you were facing. I've pulled EXIF data from my own photos and found my home address encoded in a picture I took in my living room.
When you upload that to a compression service, the compressed version they send back might have the metadata stripped. Great. But the original — with all that embedded data — already made the trip. They already received it. What they do with it is a question answered by a privacy policy that, let's be honest, nobody reads. And even the services with good intentions get breached. It happens all the time.
If you're curious about how to get files smaller without losing visual quality, I wrote a separate guide on reducing image size without quality loss. But right now let's talk about something more important than file sizes.
This gets way more serious when you're dealing with work stuff. If you're compressing product photos before a launch, or scans of legal documents, or medical images — you're creating a data liability every time those files touch a third-party server. There are entire regulations (GDPR, HIPAA, the whole alphabet soup) that exist specifically because data like this shouldn't be floating around on infrastructure you don't control. I'm not going to list every regulation because that's boring, but the gist is: if personal or sensitive data leaves your device without proper handling, someone is potentially on the hook for it. And "I used a free online tool" is not a great defense.
What if the files just... didn't leave?
This is the thing that got me interested in browser-based compression. The idea is dead simple: instead of uploading your image to a server for processing, the compression runs right in your browser. On your machine. Your files go nowhere.
When you drop an image into CanYouSmoosh, here's what actually happens: the file gets loaded into your browser's memory, a WebAssembly-compiled compression engine crunches it locally, and the result is generated right there in your tab. The compressed file is handed back to you from your own browser. No upload. No round trip. No server in Virginia.
You don't have to take my word for it. Open DevTools, switch to the Network tab, and compress something. You'll see the page load, you'll see the .wasm modules get fetched, and then... nothing. No outbound image data. It's a pretty satisfying thing to watch, honestly.
The WebAssembly thing
So how does a browser crunch images as well as a server? This is where WebAssembly comes in, and it's genuinely cool technology that doesn't get talked about enough outside of niche dev circles.
Basically: you can take code written in Rust, C, or C++ — the kind of serious, optimized code that powers desktop applications — compile it to a format called WebAssembly, and run it in a browser tab. It executes at near-native speed, but it's sandboxed by your browser. It can't touch your filesystem, it can't phone home, it can't do anything except process the data you give it in memory.
CanYouSmoosh uses this to run the same encoders that the server-based tools use. MozJPEG (Mozilla's optimized JPEG encoder), OxiPNG, Google's libwebp for WebP, ravif for AVIF. These aren't watered-down JavaScript reimplementations. They're the real thing, compiled to run in your browser. The compression quality is identical to what you'd get from a server — because it literally is the same code, just running on your machine instead of theirs.
Performance-wise, it's closer than you'd think. For a typical web-sized image, compression takes maybe 1-3 seconds. That's roughly the same as the total time you'd spend uploading to a server, waiting for it to process, and downloading the result — especially if your upload speed isn't great. AVIF is the slowest (it's computationally expensive everywhere, not just in the browser), but even that is reasonable for most use cases.
The airplane mode test
Here's my favorite party trick with browser-based tools. Well, "party trick" is generous — my parties aren't that exciting.
Load up CanYouSmoosh. Wait for the page to finish loading. Then turn off your Wi-Fi. Kill the connection entirely. Now try compressing an image.
It works. Because there's no server involved, there's nothing to connect to. The entire compression pipeline is already loaded in your browser. This is actually a great way to verify that a tool is genuinely client-side and not just marketing itself that way. If it breaks when you go offline, it was phoning home.
For anyone working with genuinely sensitive files — medical records, legal documents, confidential business stuff — this is kind of a cheat code. Load the page, disconnect, do your work, reconnect when you're done. Air-gapped image compression from a browser tab. No special software, no IT approval process, just a URL and airplane mode.
Not every "browser-based" tool is honest
Worth mentioning: some tools claim to process locally but don't. I've checked a few. The marketing says "your files never leave your device" and then you open the network tab and watch a multipart form upload fly out the door. Always verify.
The quick checks: watch the Network tab during compression, test it offline, and look for .wasm files in the loaded resources (those are the compiled engines). If the tool is open source, even better — you can read the code and see for yourself what it's doing. CanYouSmoosh is open source for exactly this reason.
Why I actually care about this
I'm not a privacy absolutist. I use cloud services. I have a Gmail account. I'm not typing this from a bunker.
But there's a difference between choosing to use a service that requires your data and unnecessarily sending your files to a server when a perfectly good alternative processes them locally. Image compression is a solved problem. The algorithms exist. WebAssembly made it possible to run them in a browser without sacrificing quality or speed. So why would you choose the version that requires your files to take a detour through someone else's infrastructure?
It's not about paranoia. It's just about not giving away data for no reason. And in case you're wondering — the compression quality you get from browser-based tools is the same as what you'd get from a server. Same WebP and AVIF encoders, same output, just running on your machine. When the local option is just as good — and in some cases faster, since there's no upload — it's kind of a no-brainer. Your photos, your documents, your files. They should stay on your machine unless you specifically decide to send them somewhere. That's it. That's the whole argument.