Image Tools That Keep Your Files Local
Most online image editors require you to upload files to their servers. Here's a growing category of tools that process everything in your browser.
Last month I was helping a friend who makes indie games optimize his sprite sheets and texture assets. Unreleased character art, level backgrounds, promotional banners he had not announced yet. Maybe 30 images total, all PNGs, averaging 4 to 6 MB each. He watched me drag one onto a browser tab and immediately asked: “Wait, is this uploading to some server somewhere?”
Fair question. I had to think about it for a second.
Turns out most free image tools do exactly that. You drop a file on the page, it gets sent to a remote server, processed there, and sent back. Your photo takes a round trip you never asked for. The tool says it deletes the file after processing. But here is the question nobody asks: when exactly is “after”? Five seconds? Five minutes? Five hours? And what about the backup that ran automatically at 2 AM? Does that count?
I spent a few hours digging into which tools upload and which ones don’t. The split surprised me.
The upload model is everywhere
TinyPNG, iLoveIMG, CompressJPEG, Convertio, Kraken.io. These are the tools that show up first when you search “compress image” or “resize image online.” All of them follow the same pattern. You pick a file. It gets POSTed to their backend. Their servers crunch it. You download the result.
TinyPNG’s FAQ says they store uploaded images for a “short period” before deleting them. How short? They don’t specify. CompressJPEG’s privacy policy mentions that files are kept temporarily to allow re-downloading. Convertio keeps files for 24 hours on their servers unless you have a paid account.
None of this is malicious. These services need server processing because that’s how they were built. Upload, process, return. It works. The problem is the deletion timeline is a black box.
Here is what “deleted after processing” actually means in practice at most cloud services. Your file lands on the server. It gets written to disk or object storage. The processing job runs, probably in a few seconds. The processed file sits in the output directory. The original sits in the input directory. A scheduled cleanup job runs every few hours, or maybe once a day, and deletes files older than the retention window. Meanwhile, the backup system took a snapshot at midnight. The snapshot includes your file. The snapshot retention is usually 7 to 30 days. So even after the “deletion,” your photo exists in a backup for up to a month. And backup snapshots are rarely itemized. They restore entire volumes. Your file lives in that snapshot until the snapshot expires or is manually purged.
I tested this myself with one service that claimed instant deletion. I uploaded an image, downloaded the compressed version, and bookmarked the direct URL to the original. For three days, that URL still served my file. On day four it finally returned a 404. “Instant deletion” apparently meant “sometime in the next 72 hours.”
Tools that stay local
Two tools I know of process images entirely inside your browser. No upload. No server round trip. No deletion timeline to worry about because there is nothing to delete.
Squoosh is made by Google’s Chrome team. It’s a clean, focused compression tool. You open it, drop an image, adjust quality sliders, and download the result. Everything runs in JavaScript and WebAssembly right on your machine.
ImgPrism takes the same approach but covers more ground. Compress, resize, crop, rotate, convert formats, remove backgrounds, add watermarks. Same principle. Nothing gets transmitted because the processing has no server component. The “deletion” is instant because there is nothing stored. Close the tab and the browser releases the memory. No backup snapshot. No cleanup job. No 72-hour window.
I use ImgPrism daily for this site. The timeline question does not apply because there is no timeline. The file exists in memory while you are working on it. When you stop working on it, it stops existing.
How is this even possible
For a long time, browsers were too slow for serious image processing. That changed around 2017 when WebAssembly landed in all major browsers.
WebAssembly lets you compile C, C++, or Rust code into a binary format that browsers can execute at near-native speed. The image processing libraries used by server-side tools like libvips and ImageMagick can now be compiled to run inside Chrome, Firefox, or Safari. Same algorithms. Same output. Just running locally instead of on a data center.
Squoosh uses a WebAssembly build of MozJPEG and other codecs. ImgPrism uses similar compiled libraries for compression, resizing, and format conversion. The work your CPU would have done on a remote server, it now does on your laptop. For a single image, that takes under a second on any modern machine.
This isn’t a hack or a workaround. It’s how a growing category of web apps will work going forward.
Side by side comparison
Here’s how the two approaches stack up across the things that matter.
| Upload model (TinyPNG, iLoveIMG, etc.) | Local processing (Squoosh, ImgPrism) | |
|---|---|---|
| Privacy | Files leave your device. Deletion timeline is unclear and unverifiable. | Files stay on your machine. No deletion needed because nothing was stored. |
| Speed for large files | Depends on your upload speed. A 20MB image on slow WiFi can take 30+ seconds just to send. | Instant. Only limited by your CPU. A 20MB image compresses in 1 to 3 seconds. |
| Works offline | No. Requires internet connection. | Yes, if the app is cached. ImgPrism works offline after first load. |
| File size limits | Usually 5 to 25 MB on free tiers. Paid plans go higher. | Limited only by your browser’s memory. I’ve processed 80MB TIFFs without issues. |
| Batch processing | Common. Most upload tools handle 10 to 20 files at once. | Varies. ImgPrism supports batch. Squoosh is one at a time. |
| Cost | Freemium. Free tiers have limits. Paid for bulk or large files. | Free. No tiers because there are no server costs to pass on. |
The speed difference is the one that catches people off guard. On paper, server processing sounds faster because data centers have beefy hardware. In practice, your upload bandwidth is the bottleneck. I tested this on my home connection, which gets around 25 Mbps upload. A 15MB photo took 5 seconds just to reach TinyPNG’s servers, then another second of processing, then 2 seconds to download the result. Eight seconds total. The same photo compressed locally in ImgPrism took 1.4 seconds.
On fast fiber that gap shrinks. On hotel WiFi or a mobile hotspot, it gets way worse.
When local processing really matters
Lawyers are the example that started this article, but they’re not the only ones. Think about the timeline. If opposing counsel subpoenaed the image tool’s server logs, could they prove your file was truly gone? Most tools couldn’t.
Medical imaging. A radiologist I talked to at a conference told me he sometimes needs to crop or anonymize scans before sharing them with colleagues. Uploading patient images, even de-identified ones, to a random compression website is a HIPAA violation waiting to happen.
Corporate confidential material. Product roadmap screenshots, financial charts, internal org charts. Companies leak competitive information through the most mundane channels. An engineer compresses a screenshot of an unreleased product and uploads it to a free tool. That image now sits on a server for some unknown period. The backup might persist for weeks. If a competitor gained access through a vulnerability, a leaked API key, or a subpoena, the “we deleted it after processing” claim would not help.
Personal family photos. Most people don’t care about this one, and fair enough. But I’ve seen parents get uncomfortable when they realize their kids’ photos were uploaded to a server they know nothing about. Once you notice it, you can’t un-notice it.
Journalism. Source photos need to stay confidential. A reporter editing an image before publication shouldn’t have that image pass through a third-party server. Newsrooms have strict policies about this kind of thing, but individual reporters often grab whatever tool shows up first on Google.
How to check for yourself
You don’t have to take my word for it. Here are two tests you can run to understand what happens to your files after you process them.
The deletion test. Upload an image to a cloud-based tool. Bookmark the direct URL of the processed file if the tool gives you one. Check back in an hour. Then check tomorrow. Then check in three days. You might be surprised how long “deleted after processing” really takes.
The network test. Open your browser’s Developer Tools (F12 or Ctrl+Shift+I on Windows, Cmd+Option+I on Mac) and look at the Network tab while you process a file. If you see requests carrying your file data to a server, your image left your device and the deletion timeline question applies. If the tab stays quiet after the initial page load, processing is local and the question is moot.
The first test tells you whether you can trust a tool’s deletion claims. The second test tells you whether the question of deletion even applies.
Try it
If you’ve been uploading images to compression websites without thinking about it, give a local tool a shot. ImgPrism image compressor runs entirely in your browser. The question of when your file gets deleted never comes up, because nothing was ever stored to delete.