How in-browser image editing works, and why it is more private

Most websites offering to resize or convert your image do it on a server. You upload the file, their machine does the work, and you download the result. That is a reasonable way to build software, and it means a copy of your image exists on someone else’s computer. There is another way to build it.

What “runs in your browser” actually means

Browsers have had a complete image processing toolkit built in for years. The canvas element decodes images, exposes their raw pixels, and re-encodes them to PNG, JPEG or WebP. It is the same machinery a web page uses to display any picture — there is simply nothing stopping a page from using it to edit one.

So when you drop a file onto one of these tools, this is the whole sequence:

1. The browser reads the file from your disk into memory. Dropping a file on a page does not upload it; it grants the page permission to read those bytes.
2. createImageBitmap() decodes the compressed file into raw pixels.
3. Those pixels are drawn onto a canvas, where the edit happens — a crop copies a rectangle, a rotate remaps coordinates, colour removal walks the pixel array and rewrites alpha values.
4. canvas.toBlob() re-encodes the result, and the download is served from a temporary URL pointing at your own machine’s memory.

At no point does the image cross the network. Not because of a policy, but because there is no code that would send it.

How to verify it yourself

You do not have to take our word for it, and you should not have to. Two checks, neither requiring any technical background:

Watch the network

Open your browser’s developer tools (F12 on most desktop browsers), select the Network tab, then load an image into any tool on this site and process it. You will see the page’s own scripts load, and the advertisement. You will not see your image go anywhere — a multi-megabyte upload is impossible to miss in that list.

Turn off your internet

The blunter test. Load the page, disconnect from the network, then use the tools. Everything still works, because everything needed is already on your machine. A tool that uploads would stop dead.

What we do send

Being precise matters here, so: the page itself is downloaded from a web server like any other page, and this site shows one advertisement per page served by Google, which sets cookies and sees your IP address the way ads do everywhere. Our privacy policy spells that out.

What is never transmitted is the image. The advertisement and the editing are entirely separate things happening on the same page.

The trade-offs, honestly

This approach is not strictly better. It has real costs, and pretending otherwise would be dishonest.

Your device does the work. A 100-megapixel image on an old phone will be slow, where a server with 64 GB of RAM would not be. Very large batches are limited by your machine’s memory.

Some things are impractical. Large machine-learning models — the kind behind AI background removal — mean a substantial download before the first use. We chose not to ship one rather than make every visitor pay that cost; our colour removal covers flat backgrounds instead, which is the common case.

Encoders are the browser’s. A specialised server-side encoder like MozJPEG can squeeze files slightly smaller than Chromium’s built-in one. We measured what the browser actually produces in our format comparison.

Nothing is saved. There are no accounts and no history. Close the tab and the work is gone. That is the direct consequence of storing nothing.

Why non-destructive editing follows naturally

Because everything is local, re-running work is cheap — which shapes how the editor behaves. Rather than baking each change into the image, it keeps your edits as a list of steps and re-runs them from the original file whenever anything changes.

That is why you can delete the second of four edits, or move a resize before a crop, and get a correct result rather than an undo stack. It also avoids compounding compression damage: ten edits still mean a single encode at the end, instead of ten rounds of re-compression.

When you should prefer a server tool

If you need AI background removal on photographic subjects, automated processing triggered by an API, images too large for your device’s memory, or work that persists across devices, a server-based service is the right choice. The privacy trade-off is then a real decision to make, rather than one being made for you silently.

For the everyday jobs — crop, resize, rotate, convert, compress, strip a flat background — there is no reason for your image to leave your machine at all.