Local vs. cloud PDF tools: an honest comparison
iLovePDF, Smallpdf, PDF24, Adobe Acrobat online and ZasPDF do similar things with one fundamental difference: where the work runs. This page explains what that difference means without overstating it in either direction.
What a cloud PDF service actually does with your file
The flow is always the same. You pick the file, your browser uploads it to the provider's server, that server runs the operation (merge, compress, convert) and hands you back a download link. Along the way the document exists in at least three places: your machine, the processing server and the temporary storage the download is served from.
Reputable providers are open about this. Their privacy policies typically state that files are deleted automatically after a set period (usually somewhere between one and twenty-four hours), that transfers are encrypted with TLS, and that staff do not access files except under legal obligation. None of that is bad practice; it is how a well-run cloud service works.
The issue is not bad faith but chain of custody. Once the file leaves your machine, its confidentiality depends on the provider's retention policy, on their infrastructure (often rented from a third party such as AWS or Google Cloud), on the jurisdiction those servers sit in, and on none of those pieces failing. For a marketing brochure that is irrelevant. For a contract with a confidentiality clause, a medical record or a client's accounts, it is exactly what a legal department would ask you to avoid.
What ZasPDF does instead
ZasPDF has no processing server. The PDF engine (a library written in Go and compiled to WebAssembly) is downloaded to the browser once, cached, and runs the operation in the tab's memory. The file you choose is never sent anywhere; the result is produced on your machine and downloaded from your own browser. The security page walks through the architecture piece by piece and explains how to verify it with your browser's developer tools.
That turns "what do you do with my file?" into a question with no object: there is nobody on the other end who could do anything. It is not a contractual promise but a consequence of where the code runs. It also has a practical corollary: most tools keep working if you disconnect from the network after the page has loaded.
Point-by-point comparison
No adjectives: what genuinely changes between processing on your machine and processing on someone else's server.
| Aspect | Local (ZasPDF) | Cloud (iLovePDF, Smallpdf, Adobe online…) |
|---|---|---|
| Where the file is during processing | Only in your browser's memory. | On your machine, on the processing server and in temporary download storage. |
| Retention | None: close the tab and nothing remains. | Automatic deletion after a provider-defined period (usually hours). |
| Total time | No upload or download. A 50 MB PDF merges in seconds; compression or OCR depends on your CPU. | Uploading and downloading usually dominate; the processing itself is fast on powerful servers. |
| Very large files | Bounded by your device's RAM; several hundred MB can exhaust the tab, especially on mobile. | Bounded by your plan: free tiers usually cap at 50–100 MB, paid plans reach several GB. |
| OCR on long documents | Works, but a 200-page scan can take several minutes on a laptop. | Clearly faster; one of the tasks where the cloud has a real advantage. |
| Offline | Yes, once the page has loaded. | No. |
| Account and price | Free, no account required; funded by advertising. | Free with size and daily-operation limits; subscription for heavy use. |
| Collaboration and multi-party signing | No: everything happens on one device. | Yes: shared links, multi-party signatures, history in your account. |
When the cloud is, honestly, the better choice
It would be easy to write this page as if local processing always won. It does not. There are cases where a cloud service is the right call:
Bulk OCR
Recognising text across hundreds of scanned pages is CPU-heavy. A dedicated server does it in a fraction of the time a laptop needs, and the output is often better because they can afford heavier models.
Multi-gigabyte files
A browser has a per-tab memory ceiling. If you work with blueprints, catalogues full of high-resolution photography or entire archive scans, a service with paid large-file plans is more reliable.
Workflows involving several people
Getting a document signed by three parties, with reminders, signing order and a certified timestamp, needs a server to coordinate. Our sign tool places a visual signature on a PDF; it does not replace an e-signature platform.
Highest-fidelity conversions
Turning a heavily designed PDF into editable Word is a hard problem. Adobe's and other commercial engines have years of dedicated work behind them and return better results on complex documents than any conversion rebuilt in the browser.
How to decide
The practical rule is simple: if the document is something you would not email to a stranger, process it locally. Contracts, payroll, medical records, identity documents, clients' financial information and anything under a non-disclosure agreement fall into that category. For those, merging, splitting, compressing or password-protecting in the browser removes an entire class of risk rather than managing it.
If the document is public or inconsequential and the task is heavy (OCR of a book, a complex conversion, a huge file), use the cloud without guilt. And if you are unsure what ZasPDF does with your data beyond the file itself (analytics, advertising, accounts), the privacy policy spells it out; the FAQ covers the limits of each tool.