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".