Why Your Images Never Leave Your Browser: How Client-Side Processing Works

Type "compress image online" into a search engine and most results work the same way: you upload a file, it travels to a server somewhere, gets processed, and a link comes back for you to download. That round trip is where the privacy and speed tradeoffs come from.

It does not have to work that way. Browsers have been able to decode, redraw, and re-encode images natively for well over a decade. A tool built on those APIs never needs to send your file anywhere.

What "client-side" actually means

Three browser APIs do the work, and none of them involves a network request.

The File API reads the file

When you drop a file onto a page, the browser hands JavaScript a File object — a handle to bytes already on your disk. Reading it is a local operation. There is no implicit upload; a file only travels if the page explicitly constructs a request and sends it.

The Canvas API decodes and redraws it

A canvas is a drawing surface with a pixel buffer behind it. Draw a decoded image onto one and you have the raw pixels in memory, where they can be scaled, rotated, cropped, or read directly. Every geometric operation these tools perform is a canvas draw with different arguments.

toBlob re-encodes it

The canvas method toBlob takes a MIME type and, for lossy formats, a quality value between 0 and 1, then hands back an encoded file. That single call is the conversion and compression step — the browser's own JPG, PNG, and WEBP encoders doing the work that a server would otherwise do.

WebAssembly extends the same idea further. It runs compiled code at near-native speed inside the page, which is how tools ship encoders the browser does not include natively. Web Workers keep any of this off the main thread so the interface stays responsive while a large file is processed.

Verify it yourself in thirty seconds

You do not have to take anyone's word for this, including ours. The check is quick and it works on any image tool.

• Open your browser's developer tools and go to the Network tab
• Clear the existing entries, then drop an image into the tool and process it
• Watch what appears. A client-side tool shows no request carrying your file — the largest entries will be the page's own scripts, loaded before you did anything
• If you see a POST with a payload roughly the size of your image, the file was uploaded

This is the only claim in this area that is actually checkable from outside. A privacy policy is a promise; the Network tab is evidence.

Why this is worth caring about

• No copy of the file sits on someone else's server, even temporarily — which matters if the image is a screenshot with account details, an ID scan, or an unreleased product photo
• There is no upload wait and no download wait, because there is no transfer in either direction — processing starts the instant you drop the file
• The tool keeps working offline once the page has loaded, since it is not depending on a server to do the work
• There is no queue, no rate limit, and no per-day quota, because you are using your own CPU rather than shared infrastructure

The tradeoffs, honestly

Client-side processing is bound by your device. A ten-year-old laptop will take longer on a large batch than a server would. For the file sizes most people work with day to day, under 20 MB, the difference is negligible and the round trip you are skipping usually costs more time than the processing itself.

There are also things browsers simply cannot do. HEIC is the clearest example: browsers do not decode it on a canvas, so a purely client-side tool cannot convert HEIC at all. Reading and writing the full EXIF, IPTC, and XMP metadata standards is another — that needs ExifTool, a native program with no browser equivalent.

This site runs into exactly that limit. The converter, compressor, resizer, cropper, and rotater all run in your browser. The metadata editor cannot, so it sends the image to a server, processes it in a private temporary location, and deletes it when your session ends. Every tool page carries a badge saying which of the two applies, before you upload rather than after.

It would be easier to write "nothing is ever uploaded" across the whole site. It would also be false, and a privacy claim that is 90% true is not worth making.

How to tell what a tool is really doing

• Check the Network tab, as above — it settles the question outright
• Look for a per-tool statement rather than a site-wide banner; blanket claims usually paper over an exception
• Be sceptical of file size limits well above 100 MB on a "private" tool, since browser memory limits make very large client-side processing impractical
• See whether the tool still works with the network disconnected after the page loads

The strongest privacy guarantee is not a promise not to look at your file. It is an architecture where the file never arrives in the first place.