The privacy comparison between local and cloud AI usually gets argued as though it were about trust — do you believe the provider's policy. That framing concedes the interesting point. The real distinction is between a commitment someone made and a property you can check yourself, and the second kind does not depend on believing anyone.
Promise versus property
Cloud: "we do not store your data" is a commitment. It may be entirely honest and it can still be changed, breached, misapplied, or overridden by a legal order.
Local: "the data never left your device" is a property. Nothing was transmitted, so there is nothing to retain, breach or disclose — and you can verify it in about thirty seconds.
Verifying it yourself
This is the part that makes the distinction meaningful rather than rhetorical. Claims of local processing are checkable, and almost nobody checks.
The offline test is the decisive one because it cannot be argued with. A tool that processes your file with the network unplugged is not sending it anywhere, and no policy document is required to establish that.
Two things to watch for that muddy the picture: analytics requests are normal and are not your file, so look at request size and payload rather than merely at whether requests exist. And some tools process locally but upload "for improvement" separately — the offline test catches the core operation, not an optional telemetry path, so check both.
What browser AI can actually do
The honest constraint is size. A model has to download before it runs and fit in browser memory, which puts a hard ceiling on capability.
| Task | Feasible in a browser? |
|---|---|
| Image classification, object detection | Yes — small models |
| Background removal | Yes |
| OCR | Yes |
| Text embeddings, semantic search | Yes |
| Speech transcription | Yes — smaller models |
| Sentiment, classification, NER | Yes |
| Small language models | Marginal — slow, large download |
| Frontier-quality reasoning | No |
The technical stack is real — WebAssembly and WebGPU give genuine acceleration, and ONNX Runtime Web executes standard models in the page. The limit is not the runtime, it is that a useful language model is tens of gigabytes and nobody is downloading that to visit a web page.
⚠️ The download is the real cost
A cloud API call sends a few kilobytes. A local model sends nothing — after downloading 5MB to 500MB of weights first, on every device that has not cached them.
For a tool used repeatedly this amortises well. For a one-off interaction, downloading 200MB to avoid uploading 200KB is a worse deal for the user on almost every axis except privacy — which may still be the axis that matters, but it should be a decision rather than an assumption.
Ask what you are protecting against
"More private" is not a single property. Different architectures defend against different things, and being specific changes the answer.
| Concern | Local helps? |
|---|---|
| Provider trains on your data | Yes — entirely |
| Provider suffers a breach | Yes — you are not in the dataset |
| Subpoena or legal disclosure | Yes — they hold nothing |
| Employee access at the provider | Yes |
| Cross-border transfer rules | Yes — no transfer occurs |
| Malware on your own device | No |
| You share the file later anyway | No |
| A colleague pasting it elsewhere | No |
The top five are exactly the concerns behind most organisational hesitancy about AI tools, and local processing removes them structurally rather than contractually. The bottom three are unaffected, and pretending otherwise is how "we process locally" becomes marketing rather than a security property.
The split that usually wins
Framing this as a choice is the mistake. The productive question is which stage runs where.
Almost all the exposure reduction comes from the first block, and none of it needs a large model. Extraction, redaction and metadata stripping are deterministic operations that ordinary code has done for decades — and doing them on the device means the sanitising step is not itself a disclosure, which is the circularity that catches people using an online tool to clean a file before uploading it.
The residual question is then much smaller and much easier to answer: is this specific extracted text acceptable to send. Frequently yes, where the whole document would have been no. The practical mechanics are in redacting a document before sending it to an AI.
💡 Sending less beats sending nothing, in practice
Absolutism here tends to fail. A policy of "never use cloud AI" gets circumvented by people with deadlines, usually via personal accounts on consumer tiers — the worst possible outcome, and invisible to the organisation.
A workable position: local preprocessing as the default path, a sanctioned cloud tier for the reasoning, and a clear rule about what may never leave. That is followed, which makes it more protective than a stricter rule that is not.
Local models outside the browser
Between the two extremes sits running a model on your own machine — same privacy property, no download-per-visit constraint, and access to far more capable models than a web page can host.
The trade is setup and hardware: you need enough fast memory to hold the model, and throughput is governed by memory bandwidth rather than anything on the spec sheet. That is covered in running an LLM locally. For an organisation with genuine data-residency constraints and sustained volume, it is frequently the right answer — and for occasional use it is more effort than the problem warrants.
Want tools that provably never upload?
Every tool here runs entirely in your browser — check the network tab, or unplug and try it.
Browse all tools →Summary
- Cloud privacy is a promise; local privacy is a property.
- Verify with the network tab, or decisively by going offline.
- Browser AI handles classification, embeddings, OCR, transcription — not frontier reasoning.
- The model download is the real cost, and it is paid per device.
- Name the threat. Local defeats training, breach, subpoena and transfer rules; not malware or later sharing.
- Split the pipeline: sanitise locally, reason in the cloud.
- Do the sanitising step locally, or it becomes the disclosure.
- Sending less beats a ban that people route around.
Frequently Asked Questions
Is browser-based AI actually more private than cloud AI?
Yes, in a specific and verifiable sense: if the processing happens on your device, the data never leaves it, so there is no transmission, no storage and no retention policy to rely on. That is a structural property rather than a commitment, and you can confirm it yourself by watching network activity.
How can I verify a tool really runs locally?
Open your browser's developer tools, go to the network tab, and use the feature. If your file is being sent, you will see an upload request carrying it. A stronger test is to disconnect from the network entirely — a genuinely local tool keeps working once its code has loaded.
What can browser-based AI actually do?
Classification, embeddings, transcription, background removal, OCR, object detection and small language models — tasks served by models in the few-megabyte to few-hundred-megabyte range. It cannot run frontier-scale language models, because those would have to be downloaded and would not fit in browser memory.
Is a hybrid approach better than choosing one?
Usually. Doing extraction, redaction and metadata stripping locally means only the minimum necessary text reaches a cloud model, which reduces exposure substantially while keeping frontier-quality reasoning. Most of the privacy benefit comes from sending less, not from never sending anything.
Does local processing mean the data is completely safe?
It means the data was not transmitted to a service. It does not protect against malware on the device, another site's code in a compromised page, or the file being shared later by other means. Local processing removes one specific risk category rather than all of them.