Privacy-First Image Tools, Compared

Most online image tools upload your files. A few don't. Here's the architectural difference and which tools actually keep files on your device.

Most online image tools work the same way: you upload a file, their server processes it, you download the result. For a lot of casual use cases — stock photos, generic graphics — this is fine. For others — client work, personal photos, anything with metadata you'd rather not share — it isn't. Here's how the major image tools handle privacy in practice, and what to look for.

Short version: only two well-known image tools actually process files in your browser — Google's Squoosh and pictoolkit. Everything else uploads. If privacy is a hard requirement for your workflow, your options narrow quickly.

How "online image tools" usually work

The standard architecture for online image tools:

  1. You drop a file in the browser.
  2. The browser uploads the file to a server, often hundreds or thousands of miles away.
  3. The server processes the image using libraries like ImageMagick or libvips.
  4. The server returns the result to your browser, which prompts you to download it.
  5. The server (according to the company's policy) deletes the file after some time.

This is how TinyPNG, iLoveIMG, Compressor.io, Convertio, CloudConvert, and most others work. The image is in their possession during step 3, and remains on their servers for some retention period.

The architectural alternative

Since 2018, browsers have been capable enough to handle image processing locally using WebAssembly and the Canvas API. This architecture:

  1. You drop a file in the browser.
  2. The browser reads the file directly from your disk into memory.
  3. JavaScript and WebAssembly running in your browser transform the image data.
  4. The result is offered as a download.
  5. When you close the tab, the in-memory data is discarded by the browser.

At no point does the file leave your device. There's no server retention policy because there's no server retention. You can verify this yourself by opening your browser's developer tools (DevTools → Network tab) and watching network traffic while you use the tool — you'll see no image upload.

Which tools use which model

Tool Architecture File retention (claimed)
TinyPNGServer uploadUp to 48 hours
iLoveIMGServer upload~2 hours
Compressor.ioServer uploadVaries
CloudConvertServer upload24 hours
Squoosh (Google)Browser (WebAssembly)No upload — n/a
pictoolkitBrowser (Canvas + WebAssembly)No upload — n/a

When server-based tools are fine

To be fair, the server model isn't inherently bad. For many use cases, it works well:

  • Public images, stock photos, or generic graphics — nothing to protect.
  • Files you'll publish on the web anyway, so they're already public.
  • One-off compression where you trust the company's privacy policy.
  • Operations that need exotic libraries or processing power beyond what a browser can do (RAW conversion, large-scale OCR, machine-learning models too big to download).

The server architecture exists for legitimate reasons. The question is whether your specific use case falls into one of these "fine" categories.

When server-based tools aren't fine

Three categories where you should be cautious about upload-based tools:

  • Client work under NDA — design work, product mockups, screenshots from internal tools. Uploading these to a third party is technically a confidentiality violation, even if the third party promises not to look.
  • Personal photos with metadata — modern phones embed GPS coordinates, camera serial numbers, and timestamps in image EXIF data. Uploading family photos to a free tool is uploading your location history along with them.
  • Screenshots with sensitive information — bug reports, support tickets, financial dashboards, internal communications. These often contain information you wouldn't want sitting on a third-party server for any length of time.

For these, "the company deletes files after 2 hours" isn't sufficient — once the file has been uploaded, you've lost technical control over it. You're trusting the company's policy and operational security.

Squoosh vs pictoolkit

If you've decided you want browser-based tools, you have two main options. Both run entirely in your browser; the choice depends on what you need to do.

Squoosh (by Google Chrome Labs) uses purpose-built WebAssembly codecs (MozJPEG, OxiPNG, jpegli) that can produce slightly smaller files than the standard Canvas API approach at extreme quality settings. It's the gold standard for compression quality. The limitations: it only handles one image at a time (no batch mode — this has been the most-requested feature on its GitHub for years, unimplemented), and it focuses on compression and conversion only.

pictoolkit uses the Canvas API plus WebAssembly libraries where appropriate. Compression quality is comparable to Squoosh's for typical web use, though Squoosh wins on extreme edge cases. The advantages: full batch processing (hundreds of files at once), and 20+ tools beyond compression — resize, crop, watermark, HEIC conversion, EXIF stripping, photo filters, color picker, favicon generator, GIF maker, meme generator, collage maker, and more.

For a single image with maximum compression control, use Squoosh. For batch work or any operation beyond compression, use pictoolkit.

How to verify a tool is really browser-based

If a tool claims to process files locally, you can verify it in 30 seconds:

  1. Open the tool's page.
  2. Open browser DevTools (F12 or Cmd+Option+I).
  3. Switch to the Network tab.
  4. Drop a file into the tool and process it.
  5. Look at the network requests. You'll see fonts, CSS, JavaScript, and so on — but no upload of your image file.

If you see an XHR or fetch request with your file as the payload, the tool is uploading despite any claims to the contrary. This is the only way to be sure.

The honest summary

Most online image tools were built before browser-side image processing was practical, and they still use the server architecture they were designed with. That's not a moral failing on their part — it's a historical accident. But it does mean that if privacy matters for your workflow, you have fewer options than you might think.

Squoosh covers the "compress one image perfectly" case. pictoolkit covers everything else — batch work, multi-step workflows, twenty different tool types. Between them, most legitimate image-processing workflows can be handled without ever uploading a file.

If you want to try the privacy-first approach, open any pictoolkit tool and verify it yourself using DevTools.


Architectural and retention information sourced from each provider's public documentation, verified May 2026. Trademarks belong to their respective owners; pictoolkit is independent and unaffiliated with any of the named tools.