← All posts

ClearPix engineering series · Part 16

Local First: What "Your Files Never Leave Your Device" Actually Costs Us

By the ClearPix team · Oct 23, 2026 · 5 min read

"Local First" is printed on a lot of landing pages, usually next to a shield icon. It rarely comes with a definition you can check, and almost never with an honest list of what the choice costs. This post is our version of both: the exact contract we mean when we say your files never leave your device, what we can and cannot see while you use ClearPix, what the architecture gives up compared to a server, and a two-minute way to verify all of it yourself in your browser's DevTools. If you want the full engineering tour instead — the ONNX Runtime Web stack, the model distribution pipeline, the cache — read the architecture overview; this post stays on the product side of that line.

The contract, in one sentence

When we say Local First, we mean something narrow and checkable: your pixels are never serialized into a network request. Not "we don't store them", not "we delete within 24 hours" — those are promises about behavior after your data has already crossed the wire. Our claim is about the wire itself. Your image or video is decoded in your tab, processed on your CPU or GPU, re-encoded locally, and written back to your disk. The only bytes that travel are model weights coming down to you, once, then cached.

That is a structural claim, not a policy claim. A privacy policy can change; an architecture has to be re-engineered to leak.

Why watermark removal, of all tools, makes this personal

The files people bring to a watermark remover are rarely just "photos with a logo". They are screenshots of private conversations, scanned documents with stamps and identifiers, family pictures, client work before sign-off, medical or legal paperwork someone photographed. The watermark is usually the least sensitive thing in the file.

A server-based remover asks you to hand exactly that file to a stranger's GPU first and ask questions later. "We delete it after processing" is unverifiable from the outside — you cannot audit their disks, their logs, their backups, or their subcontractors. We think the right answer for this category is not a better deletion policy. It is no crossing of the wire to audit in the first place.

What we can see, and what we cannot

We will not pretend the site is invisible to us. Here is the honest inventory.

What reaches our infrastructure: page requests like any website, model downloads (a CDN sees IP address, user agent, and how many bytes of MI-GAN, LaMa, Real-ESRGAN, YOLO or PP-OCR it served you), and a small set of aggregate analytics events that contractually cannot contain your media — no pixels, no file contents, no masks.

What structurally cannot reach us: your file, the mask you painted, the detection boxes, the cleaned result. There is no processing backend to receive them, no account to attach them to, and no storage bucket they were ever written to. This is the difference between "we don't look" and "we can't".

What Local First costs us — and you

This is the part most Local First landing pages skip, and it is the part that makes the claim credible, so here is our bill.

Download weight. A server tool streams nothing to you but pixels over a websocket. We ship you the model. The fast path costs roughly 13 MB on first run — down from 72 MB before we switched model delivery to Brotli on R2 — and the high-quality LaMa inpainting model is about 100 MB more, fetched only if you choose the HQ engine. That is a real cost on a metered connection, and it is the price of the architecture. (We wrote the whole ugly story of that optimization in our model-delivery post.)

Hardware variance. A data center gives every user the same GPU. Local First gives each user their own: fast on a recent laptop with WebGPU, slower on an old machine falling back to WASM. We spend a disproportionate amount of engineering on that gap — execution-provider fallbacks behind a watchdog so a broken WebGPU session degrades instead of hanging your tab — but we cannot make a 2015 laptop behave like a T4.

No server-side conveniences. There is no queue we can prioritize, no batch endpoint, no "we'll email you when the 8K render is done". Video is capped at short clips partly because your device's RAM, not our data center, is the budget. When someone asks for a 500-photo batch job, the honest answer is that a server tool is genuinely the better shape for that workload.

Support surface. We cannot reproduce every bug by logging into one machine. Our inference runs on thousands of hardware and driver combinations, which is why posts like the one about a mask bug that metrics missed exist.

Verify it yourself, in two minutes

This is our favorite section, because it is the one that does not require trusting us.

  1. Open any tool page — say, remove a watermark from a photo.
  2. Open DevTools → Network. Clear the log.
  3. Load a sample or drop in a file. Run detection, paint a mask, hit export.
  4. Now look for a single request whose payload contains your image or video bytes. Filter by Fetch/XHR, by Media, sort by size — it is not there. You will see page assets, one-time model downloads, and small aggregate event pings. Nothing that carries your file.

If a competitor shows you a shield icon, ask for this demo. If they cannot pass it, the shield is decoration.

When a server would honestly be better

We want to be the last people to pretend Local First is free. Bulk jobs of hundreds of images, 4K or 8K video on old hardware, users on tiny data plans — a data-center GPU wins those, full stop. If your workload looks like that, use a server tool, with clear eyes about what crosses the wire and who holds it afterward.

Our bet is narrower: for the sensitive, one-off job — the screenshot from this morning, the scan on your desktop, the client draft — processing on your own device wins on privacy, on latency, and on price. That is the job ClearPix is built for, and the one where "Local First" is not a slogan but the whole point.

Try it in your browser

ClearPix is free, unlimited and runs entirely in your browser. If this post saved you a debugging session, a coffee keeps the model hosting and bandwidth paid for — nothing here is locked behind it.

Buy me a coffee