Local vs cloud processing

Two common designs use different data paths. 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. Some services combine local and server-side steps; check the disclosure for the task you use.

• 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 opens the document with browser file APIs and processes it on the device. Required code or static assets may still be fetched over the network without transmitting the document.
• 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.

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 and check for requests carrying file content or chunks. Local processing may still fetch code or static assets; offline completion is an extra test only when that tool has been prepared for offline use.

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.

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.

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: check request bodies and chunks when you press convert, not only the total request size.
• Cut the connectionTest an explicit offline claim: prepare a tool marked for offline use while connected, then run a small sample after disconnecting. An offline failure alone does not show that the file was uploaded.