How to compress images without uploading them

Why uploading is a real problem, not just a preference

The default model for online image tools is: you send your file to a server, the server compresses it, and the server sends it back. That is a reasonable architecture for a public logo. It is a poor fit for a great many real situations.

Confidentiality. Client photography under NDA, unreleased product shots, patient or case imagery, financial documents, identity documents, internal screenshots. Once uploaded, those files exist on infrastructure you do not control and cannot audit.

Retention you cannot verify. Many tools state that files are deleted after an hour. You have no way to confirm that, and you have no way to know whether a copy exists in a backup, a log, a cache or a training corpus.

Compliance. If you handle personal or special-category data, uploading it to an arbitrary third-party processor can be a reportable transfer. The simplest way to have no data-processing risk is to have no data processed by anyone else.

Bandwidth and size limits. Uploading a 200-image batch means pushing hundreds of megabytes upstream over a domestic connection — often slower than downloading, and frequently capped by the tool's own file-size limit.

None of these are hypothetical objections. They are the reason client-side processing is worth a dedicated page.

How client-side compression actually works

For roughly a decade it was not practical to run real image codecs in a browser. That changed with WebAssembly: mature C and C++ codecs can now be compiled to a binary format that runs in the browser at close to native speed.

ImageAlchemy ships those codecs as WebAssembly modules — MozJPEG for JPEG, libwebp for WebP, OxiPNG for PNG and the AV1 encoder for AVIF. When you drop a file:

1. The browser reads the file from your disk into memory. No network request is involved.

2. The file is decoded, then re-encoded by the WebAssembly codec running in a Web Worker on your own CPU.

3. You get a new file back as a downloadable object. It never left the machine.

The only network traffic involved is the initial page load — the HTML, CSS, JavaScript and the codec binaries themselves. Once loaded, the tool works with your network connection disabled. That is the definitive test of whether processing is genuinely local, and it takes ten seconds to run.

How to verify a tool really is local

"Private" and "secure" are used loosely in this category, so it is worth knowing how to check a claim rather than trusting it. Three tests, in increasing order of rigour:

Test 1 — disconnect and use it. Load the tool, then turn off your Wi-Fi and drop an image in. If it compresses, the processing is local. If it spins, errors or hangs, it was uploading. This is definitive and requires no technical knowledge.

Test 2 — watch the network tab. Open developer tools, switch to the Network tab, and compress an image while watching. A local tool shows no request carrying your file — no large POST or PUT. A cloud tool shows an obvious upload of roughly the file's size.

Test 3 — check what the page claims it needs. A tool that advertises file-size limits ("up to 5 MB") or a per-day quota is server-backed, because a client-side tool's only real limits are your device's memory. Genuine local processing has no reason to cap you at 5 MB.

One honest caveat about this site: ImageAlchemy does record anonymous performance analytics — page paths and Core Web Vitals — under its privacy policy. It does not receive your images, your file names, or their contents. Those are separate claims and the policy states both precisely.

The honest trade-offs of client-side processing

Client-side is not free of cost, and a page that pretends otherwise is not worth reading. The real trade-offs:

First load is heavier. The WebAssembly codecs are several hundred kilobytes to a few megabytes, depending on format. Once cached, this is a non-issue; on a very slow first visit, a server-based tool may feel faster to start. ImageAlchemy loads codecs on demand rather than all upfront for exactly this reason.

Your CPU does the work. Encoding is compute-intensive, especially AVIF. A very old or low-powered device will encode more slowly than a server with many cores. In practice this is a difference of seconds on a batch, and batch processing runs across multiple workers.

No server-side pipeline features. A server can do things a browser cannot — crawl your website and find the images, for example. That is precisely why the Pro website audit needs a small proxy to fetch a page's HTML, and why ImageAlchemy is explicit that this one feature makes a network request (described in the privacy policy).

Weighed against those, the guarantee that your files are never transmitted is worth a few hundred kilobytes of cached JavaScript.

Why this also makes you faster

The privacy benefit is the headline, but there is a practical performance benefit that is easy to miss: local processing is not limited by upload bandwidth.

Compressing 200 images on a cloud tool means uploading hundreds of megabytes before the work even begins. On a typical domestic connection with a modest upstream, that upload phase dominates the whole task. Locally, the encode starts immediately and finishes at whatever speed your CPU manages — usually far sooner than the equivalent round trip.

There is also no per-file round-trip latency, no queue behind other users, and no session timeout. A batch of 200 images is one continuous local operation rather than 200 network transactions.

Who this is specifically for

Agencies and freelancers. Client work often arrives under confidentiality terms. Processing it locally means the imagery never becomes a third-party data-processing question at all.

Healthcare and legal. Where uploading imagery to an arbitrary processor would require an assessment, removing the upload removes the assessment.

Product teams pre-launch. Unreleased product photography and design assets are among the most sensitive material a company holds, and among the most likely to be compressed casually.

Anyone on a constrained connection. Where upstream bandwidth or a data cap makes uploading hundreds of megabytes impractical, local processing is straightforwardly faster.

Privacy-conscious users generally. If the file is personal, there is no reason for it to be someone else's log entry.

Doing it now

Drop your images onto the ImageAlchemy tool at the top of this page — or use Auto-Pick, which encodes each image in several formats and keeps the smallest result. Choose a format and quality (75–85 is the range that works for almost everything), process the batch, and download individually or as a single ZIP.

If you want to confirm the claim rather than take our word for it, load the page, disable your network connection, and compress something. If it works — and it will — nothing was uploaded.