Skip to content

By Sakshi • • 8 min read

Why Image Tools Upload Your Photos

Resizing an image needs no server. So why does almost every online image tool send your file to one? The answer is mostly about business models — and you can check any tool yourself in about thirty seconds.

Here's something worth sitting with: your browser has been capable of resizing, cropping, compressing and converting images entirely on its own for well over a decade. The Canvas API landed in browsers around 2010. No upload is technically necessary to change a photo's dimensions.

And yet if you search for an image resizer, most of the results will take your file, send it to a server somewhere, process it there, and send it back. For a passport photo, an ID scan or a photo of your child, that's a meaningful thing to know about — so it's worth understanding why it happens.

Four reasons servers get involved

1. It's the easier thing to build

Server-side, you install a mature image library — ImageMagick, libvips, Pillow — and it handles every format, every edge case, color profiles, EXIF, CMYK, animated GIFs, the lot. In the browser you're working with what the browser natively supports, and anything beyond that you implement yourself. Honestly: client-side is more work, not less. That alone explains a lot of the market.

2. Uploads create a metering point

This is the commercial reason, and it's the important one. If processing happens on your device, there is nothing to meter — no way to enforce "3 free images per day", no way to gate batch processing behind a subscription, no way to make you create an account. A server in the middle is what makes a freemium funnel possible. Client-side tools give away the whole product at once, which is a harder business to run.

3. Some features genuinely need more compute

AI upscaling, object removal and generative fill involve models far too large to ship to a browser. That's a legitimate technical reason. It's worth noting, though, that the ceiling keeps moving: background removal used to require a server, and now runs locally via WebAssembly — which is exactly how our background remover works. The model downloads once, then runs on your own hardware.

4. Uploaded files are, themselves, an asset

Not always sinister, but always true: once your file is on someone's server, it exists in their logs, their backups and their jurisdiction. Some terms of service grant broad licenses over uploaded content. Some retain files for a period "to improve the service." Read a few and you'll notice how much variation there is in what you've agreed to.

What "we delete your files after an hour" actually means

This is the standard reassurance, and it's usually offered in good faith. But it asks you to trust several things you cannot observe:

  • That deletion happens as described. You have no way to verify it. You're trusting a policy statement about a system you can't see.
  • That backups are covered too. Deleting a file from primary storage doesn't necessarily remove it from snapshots taken in the interim.
  • That the window doesn't matter. A file that exists for one hour is a file that can be read, logged, or exposed by a breach during that hour.
  • That the policy will hold. Companies get acquired, change terms, and change hands. The promise you read today was made by whoever ran the site today.
  • That transit and intermediaries are clean. HTTPS protects the wire, but the file is decrypted at the CDN or load balancer before processing, and request logging is on by default in most stacks.

None of that means these tools are acting badly. It means the guarantee is a promise, and a promise is a different category of thing from an architecture where the file never leaves in the first place. If your photo is never transmitted, there is no retention policy to trust, no breach that can expose it, and no jurisdiction question to think about.

How to verify any image tool yourself

You don't have to take anyone's word for this, including ours. Browsers ship with the tooling to check, and it takes under a minute. Here's the procedure:

  1. Open the tool's page, but don't add an image yet.
  2. Open developer tools — F12 on Windows and Linux, ⌥⌘I on macOS — and select the Network tab.
  3. Clear the request list, so you're starting from a clean slate.
  4. Now add your image and run the resize or conversion.
  5. Watch the request list. Sort by size if it's noisy.

What you're looking for is a request whose size is comparable to your image, using the POST or PUT method. A 3 MB photo leaving the browser produces an unmistakable ~3 MB outbound request — you cannot hide that. If the only requests are the page's own scripts, styles and fonts, and nothing large goes out at the moment you process the file, the work happened locally.

A couple of things that can look alarming but aren't: analytics pings and font requests are small and unrelated to your file. And on our background-removal page you'll see a large download the first time you use it — that's the AI model coming to your device, which is the opposite direction from your photo going out. Check the direction and the method, not just the size.

Try it on this site. Open the network tab, resize something, and confirm no image data leaves your machine. We'd rather you verify it than believe us — a claim you can test is worth more than one you can't.

The honest trade-offs of client-side processing

Local processing isn't free of downsides, and a page that pretended otherwise wouldn't be worth much. The real constraints:

  • Your device does the work. A large batch on an old phone is slower than the same job on a server farm, and very large files can exhaust available memory. This is why our size guidance says "around 50 MB, limited by your device's memory" rather than quoting a hard number — the real ceiling depends on your hardware.
  • Format support follows your browser. Formats the browser can't decode need a JavaScript decoder shipped alongside, which is why HEIC support loads an extra library on demand.
  • Heavy models mean a first-use download. Background removal fetches roughly 40 MB of model the first time. After that it's cached, but the first run isn't instant, and calling that "offline" would be misleading.
  • No cross-device handoff. Nothing is stored anywhere, so you can't start on your phone and finish on your laptop. That's the direct cost of not having a server.

We think those trade-offs are clearly worth it for personal documents and photos. But they are trade-offs, and if you're batch-processing ten thousand product images, a server-side pipeline is genuinely the better tool for that job.

When you should care most

For a screenshot of a meme, none of this matters. The cases where it does:

  • Identity documents — passport photos, driving licenses, ID cards. These are exactly the files used for identity fraud, and they carry your face and often your document number.
  • Anything with a signature — a scanned signature is a reusable credential.
  • Medical or financial paperwork — prescriptions, test results, bank statements, tax documents.
  • Photos of children — worth being deliberate about where these travel.
  • Unpublished professional work — client photography or design work under embargo.
  • Anything with location metadata — photos straight from a phone often carry GPS coordinates in EXIF.

A useful habit: before uploading a file anywhere, ask what's actually in it. Not just the picture — the metadata too. If the answer includes your face, your address, or your signature, prefer a tool that doesn't need to see it.

Resize without your file going anywhere

Open the image resizer →

Verifiable in your browser's network tab, not just in our privacy policy.

Read more

Last updated: