03 / GUIDES
Local vs cloud processing
Where a file actually travels in upload-based and browser-based tools, how to tell the two designs apart, and which documents should never leave your device.
Two architectures, two data paths
Every online tool follows one of two designs. Upload-based tools send the file to a server that parses, converts, and returns it. Local-first tools ship the engine to your browser, so the file is read into tab memory and processed on your device.
- Upload pathAn upload-based tool receives a copy of the file over the network, queues it on a server, and usually stores it at least briefly before deletion policies apply.
- Local pathA local-first tool downloads its code once; the document is opened with browser file APIs and is never transmitted as part of the operation.
- Honest labelingBoth designs can be legitimate. What matters is that the site tells you which one you are using, in plain language, before you add a file.
Local processing is a verifiable claim
Browser-based conversion is not a promise you have to take on faith. The technologies behind it are standard, and you can watch them work.
- Standard enginesThe File API reads bytes from the document you pick; Web Workers and WebAssembly run heavy engines such as PDF parsers at near-native speed without freezing the tab.
- On-device outputCanvas and object URLs produce previews and downloads on the device, so the finished file is assembled in memory and saved straight to disk.
- Check it yourselfOpen the browser’s network monitor before you run a task: a genuinely local tool shows no request carrying your document, and the task still completes with the connection cut after load.
When server-side processing is reasonable
Some jobs honestly benefit from a server. The difference between a careful service and a careless one is disclosure, not the architecture itself.
- Legitimate casesVery large files, compute-heavy work such as OCR on long scans, and shared team workspaces can exceed what a browser tab should handle.
- Disclosure standardA trustworthy service states its retention window, deletion behavior, and subprocessors before you upload, and keeps files out of advertising and training pipelines.
- Silence is an answerIf a site cannot explain where your file goes and for how long, treat that silence as the answer and keep sensitive material elsewhere.
Files that should not travel
Convenience is a poor reason to hand over a document you would not email to a stranger. These categories deserve local processing or a managed company channel.
- IdentityIdentity and civil documents: passports, ID cards, driver’s licences, residence papers, and signed forms that carry your personal data.
- LegalContracts and legal material: NDAs, employment terms, court filings, and anything covered by privilege or a client’s confidentiality expectations.
- Financial and medicalFinancial and medical records: tax returns, bank statements, payslips, insurance claims, lab results—plus unpublished manuscripts and internal company decks.
A sixty-second check before you convert
Run this sequence on any unfamiliar tool, including this one, before you trust it with real documents.
- Read the labelFind the processing statement: a serious tool labels where work happens, the way Toolars marks every workspace local-first with input that stays on the device.
- Watch the networkWatch the network: your browser’s developer tools show whether a file-sized request leaves when you press convert.
- Cut the connectionTest the offline claim: load the page, disable the connection, and run a small sample file. A local engine finishes the task; an upload silently fails.
Put the local path to work.
Ten everyday PDF jobs—merge, split, rotate, compress, and more—that run entirely inside your browser.