Why in-browser processing actually matters (and how to verify it)

A lot of privacy-flavored tools say "we don't keep your files." The honest ones mean it. The dishonest ones add "...for very long." The genuinely different ones don't ever have your file in the first place.

CleanImages is in the third bucket — the cleaning happens entirely in your browser, on your device. There is no upload. Here's what that actually means and how to verify the claim yourself, because "trust us" isn't a great privacy posture.

What "in your browser" means technically

When you drop an image into CleanImages, here's what happens:

1. Your browser reads the file bytes into memory using the File API. This is a local operation — no network request is made with the image.
2. Our code, running as JavaScript that your browser already downloaded, parses the file format (JPEG, PNG, WebP) and identifies the metadata segments.
3. We surgically remove those segments from the byte stream, producing a new file with the pixels untouched.
4. We hand you back a download link pointing at the cleaned bytes in your browser's memory.

At no point does your image file travel across the internet. The only network requests we make are for the page itself (HTML, CSS, JavaScript, fonts) — and those happen before you drop a file.

How to verify it

You don't have to take our word for any of this. There are three ways to check.

1. Open the network tab

In Chrome/Firefox/Safari, open DevTools (right-click → Inspect, or Cmd+Option+I), go to the Network tab, and clear it. Now drop an image into the tool. Click "Strip everything" and download the result.

You'll see exactly zero requests with the image data. The tool emits no POST, no PUT, no upload of any kind. The only network activity should be unrelated (analytics ping, font load, etc.) — none of it carries your image bytes.

2. Turn off your internet

This is the most fun way. Load the page, then disconnect from WiFi (or pull your ethernet cable). Drop an image. Clean it. Download it.

It works. Because cleaning is done locally, there's nothing for your offline state to interfere with. If we needed your image on a server, the operation would fail — but it doesn't.

This is the strongest possible privacy proof. You can't accidentally exfiltrate data through a connection that doesn't exist.

3. Read the code

The metadata cleaning engine is open and inspectable. The format parsers (JPEG marker walk, PNG chunk parser, WebP RIFF walker, EXIF TIFF reader) are all in app/_lib/metadata-engine.ts. There's no obfuscation, no minification of the privacy-critical parts you should be able to audit, and no place where image bytes get sent over a network — by construction, not by promise.

If you spot a network call from the engine module, that's a bug; please report it.

Why most tools don't work this way

Building a real client-side image processor is harder than building one that uploads to a server. You have to:

• Implement format parsing in JavaScript (browsers don't expose JPEG/PNG/WebP segment parsing natively)
• Handle large files in browser memory without locking the UI
• Build the metadata report logic to run in the constrained JS environment
• Lose the "we'll just use ImageMagick" shortcut that most server-side tools take

The reason most tools upload is that it's easier. The reason we don't is that the privacy story is the product.

What "in your browser" doesn't mean

A few honest disclaimers, because we'd rather be specific than vague:

• Your browser is still your browser. If your browser is compromised (malicious extension, infected device), nothing we do helps.
• Other tabs are other tabs. CleanImages can't see them and they can't see your image, but they're not isolated from each other unless you isolate them.
• HTTPS is still important. The page itself is delivered over HTTPS so it can't be tampered with in transit. If you're loading CleanImages over an open WiFi network on http://, that's a different problem.

But the actual claim — your file doesn't get uploaded — is provable, and you can verify it in two clicks. That's the whole point of doing it this way.

The upshot

"In-browser" isn't a marketing label, it's an architecture. The difference matters because the claim is verifiable: no inspection of our backend logs required, no DPA to read, no policy to trust. You can prove it yourself in 30 seconds by turning off your WiFi.

That's the bar we're trying to meet. If a privacy tool can't pass the offline test, ask why.