The fundamental difference
Upload model: your file leaves the device, crosses the network to someone's server, is written to disk (often logs and backups too), then the result comes back. Local model: JavaScript or WebAssembly inside the page performs the computation on your machine — only the page code travels over the network; your data does not.
Three risks of the upload model
- Transit and storage: HTTPS protects transport only; whether the file is encrypted at rest and how long it is kept is up to the operator;
- Retention and backups: files often land in object storage or logs "for debugging", and deletion promises are hard to verify;
- Compliance: handing files with personal data to a third party may count as data transfer or processing on your behalf.
Boundaries of the local model (do not over-trust it)
- Code can be tampered with: if the site is compromised, the "local" code itself can be replaced — so judge the source and prefer open implementations;
- Browser extensions: an extension with the right permissions can read page content regardless of how the tool works;
- Device security: once malware controls your machine, no architecture saves you.
How to tell whether a tool is really local
- Go offline: after the page loads, disconnect the network — if it still works, the computation is local;
- Watch the network: open DevTools, switch to the Network panel and import a file; any upload request means it is not local;
- Read the privacy note and implementation: does it state "never uploaded"? Is it open source? Does the CSP restrict outbound connections?
- Look for technical hints: credible tools name the technology (Web Crypto, WASM).
Practical advice
For sensitive files — ID documents, contracts, source code, chat screenshots — prefer local tools. When a file is too large for browser memory, consider a server option, but check its retention policy first and redact what you can.
Where local processing fits
| Task | Local processing | Notes |
|---|---|---|
| File hash verification | Excellent fit | Web Crypto computes it, streaming large files |
| Image watermark / compression | Excellent fit | Canvas output is the finished file |
| OCR text recognition | Good fit | WASM models are large; first load is slower |
| Video transcoding | Fair | Limited by device performance; long clips take time |
| Bulk processing of huge files | Unsuitable | Browser memory is limited — use a server |
Adopting this in a team
- Classify the data first: public, internal, sensitive — only sensitive data strictly requires local processing;
- Then publish a tool list: which online tools are allowed, and which scenarios are banned, written into team policy rather than left to memory;
- Back it with technique: go offline and retest, watch the network panel, or use an isolated or air-gapped machine when needed;
- Re-check periodically: tools change — a "local processing" conclusion from six months ago may no longer hold.
Try them: file hash, image watermark
Proving "nothing is uploaded"
- Works offline: core features should keep working with the network disconnected — the clearest possible proof;
- Watch the network panel: exercise the tool with devtools open and confirm no request carries your input;
- CSP as evidence: restricting
connect-srcto the domains you need is a published boundary; - Open and auditable: publishing source lets anyone verify the claim rather than trusting it.
Where local-first stops
Local processing is not universal: cross-device sync, shareable links and centralised billing still need a server. A pragmatic split is raw data stays local while only necessary results or aggregates are uploaded — and state plainly which data leaves the device and in what form. That is more credible than a blanket "never uploads".