"Is this safe?" is the wrong question, because it has no single answer. The useful question is narrower: what does this specific tool do with my file, and does that matter for this specific document? Uploading a restaurant menu and uploading a client's medical records are not the same act, even through the same website.
Here is how to tell what a tool is doing, and how to decide when it matters.
The two architectures
Server-side. You upload the file. It is stored on the provider's infrastructure, processed there, and returned to you. This is how most online PDF tools work, and it is not sinister — it is the only practical way to offer OCR, format conversion, and other compute-heavy operations. But your document exists, at least briefly, on hardware you do not control.
Client-side (in-browser). The tool's code loads in your browser, and your file is opened and processed by your own machine. Nothing is transmitted. Capabilities are narrower — anything needing serious compute or licensed engines is impractical — but the file never leaves your device.
Most sites do not tell you which they are, so you have to find out.
How to tell, in thirty seconds
Do not rely on marketing copy. Two tests answer it definitively.
The offline test. Load the tool's page, then disconnect from the internet — airplane mode, Wi-Fi off, cable out. Now open a PDF and try to edit and export it. A client-side tool keeps working, because nothing needed the network. A server-side tool fails immediately at the upload step. This is the most convincing check available and it requires no technical knowledge at all.
The network test. Open your browser's developer tools (F12, or right-click → Inspect), go to the Network tab, and process a file. A server-side tool shows a request whose size matches your document. A client-side tool shows page assets and nothing else.
Weaker signals, useful but not conclusive: a progress bar reading "Uploading…" is a giveaway; near-instant handling of a large file suggests local processing; and a privacy policy that says "client-side" or "your files are never uploaded" is worth reading, though a claim is not a proof.
If a tool does upload, what to look for
Server-side is often the right choice — you cannot do OCR any other way. Judge the provider:
- A stated retention period, in writing, with a specific number. "We delete files after one hour" is a commitment. "We take security seriously" is not.
- Where the servers are. A file processed in another jurisdiction may be reachable by legal processes that do not apply where you live. This matters for client and patient data.
- What the terms of service claim. Some free services reserve broad licences over uploaded content. This is where the actual answer lives, and almost nobody reads it.
- Named subprocessors. A serious privacy policy says who else touches the data.
- HTTPS throughout, which is table stakes rather than a distinguishing feature.
- Whether an account is required. Uploading a document and handing over an identity is a bigger disclosure than either alone.
Signals to walk away from: no privacy policy at all, no company identity anywhere on the site, or a tool that emails you a download link — which usually means the file sits at a guessable URL with no access control.
Matching the tool to the document
Low stakes — a public brochure, a form with no personal data, a scanned recipe. Any reputable tool. Use whatever is convenient.
Moderate — internal business documents, drafts, non-sensitive contracts. Server-side is acceptable from a provider with a clear retention policy. Prefer local tools when equally easy.
High — identity documents, medical records, financial statements, payroll, legal files, anything covered by GDPR, HIPAA, or a professional confidentiality duty. Do not upload. Use a client-side tool, or software installed on your own machine. For regulated data, "we delete after an hour" may not satisfy your obligations regardless of how trustworthy the provider is, and if you handle client data professionally, the choice may not be yours to make casually.
A practical rule: if you would hesitate to email the document to a stranger, do not upload it to one.
Where we sit, including the limits
Docento.app is client-side. Your file is read into memory by your browser, rendered by Mozilla's PDF.js, edited by pdf-lib, and written back out locally. There is no upload endpoint, so there is nothing to transmit. Run the offline test on us — it works, and that is the point of mentioning it rather than asking you to trust a claim.
The honest limits, because a security claim without its boundaries is marketing:
- We do not offer OCR or format conversion. Those genuinely need server-side compute. For those jobs you will use a tool that uploads, and that is fine — just choose it deliberately.
- Client-side says nothing about analytics or advertising. We run both, and they are described in our Privacy Policy. They see that a page was visited; they do not see your document, because your document never enters the request path.
- Large files are limited by your device's memory, not by a server farm. A several-hundred-page scan may be slow on a phone.
- We cannot recover anything. We have no copy. That is the direct cost of the design.
- Your device is still yours to secure. Malware, a malicious browser extension with page access, or a shared computer are outside what any web tool can defend against.
The things that actually go wrong
In practice, documents are far more often exposed after the editing than during it: a file emailed to the wrong autocompleted address, a signed contract left in a shared Downloads folder, a "redacted" document whose black boxes hid nothing, or a public share link forwarded onward. Choosing a private editor and then emailing the result unencrypted to the wrong person is a solved security problem followed by an unsolved one.
See how to share a PDF securely and how to redact text in a PDF for the parts that come after the edit.
