What "processed locally" actually means for a browser extension

"All processing happens locally" appears in a lot of extension descriptions. It is a meaningful claim, but it is also unverifiable from the sentence itself, and it gets used loosely.

Here is what it can mean, and how to tell which one you have.

Three architectures, one phrase

Everything on device. The extension does its work in the browser process. Nothing about your page is transmitted. There is no server that could receive it, because the product does not have one for that purpose.

Local processing, remote storage. The work happens on your machine, but the result is uploaded - for sync, for share links, for history across devices. This is a normal, useful design. It is also not what most people hear in the phrase.

Local-ish. The core operation happens on device, but some path sends data out: telemetry that includes page URLs, error reporting that attaches context, an "improve our product" toggle that is on by default.

All three can honestly be described as local processing by someone who means it. Only the first is what a privacy-conscious reader assumes.

How to tell, without reading source

Does it require an account for the basic function? If you cannot use the core feature without signing in, something is happening server-side. Sign-in for a paid tier is different - check whether the free path needs it.

Does it work offline? Disconnect and try. Purely local operations keep working. This is a crude test but a fast one, and it catches a lot.

What does the store listing declare? Chrome and Firefox both require a data-collection declaration. "This developer declares that this extension does not collect user data" is a specific, checkable statement someone signed their name to.

What does the network tab say? Open DevTools, go to Network, perform the operation, and look at what leaves. This is the direct answer and it takes thirty seconds.

Why open source changes the question

Open source does not make software trustworthy. Plenty of open projects have bugs, abandoned maintenance, or dependencies nobody has read.

What it changes is who can check. A closed tool's privacy claim rests on the vendor's word and on whatever the store's review process caught. An open one can be checked by anyone who cares to - and more usefully, by anyone the claim would embarrass if it were false.

That is a weaker guarantee than "I read the code myself" and a much stronger one than "they said so."

The uncomfortable case

There is a common pattern worth naming: an extension processes your data locally and also has an account system for a paid feature. Both things are true, and the combination reads as contradictory.

The honest version of that answer specifies what the account touches. "Billing and entitlement are handled by a separate service; the content you capture is never sent to it" is a claim you can test with the network tab. "We take privacy seriously" is not.

Disclosure

I work on OpenCapture, an open-source screenshot extension. It has exactly the arrangement described above - a credit balance handled by a separate service, and capture data that never reaches it. Which is why I would rather you test that claim than believe it. Source is on GitHub under AGPL-3.0.