You hold an employment contract, a medical report or a bank statement that needs splitting — and the idea of dropping it on the first website that offers gives you pause. That hesitation is healthy: once the file is uploaded, you no longer control how long it is kept or who can access it. A local PDF tool running in the browser answers exactly that problem — provided you understand what “local” technically covers, and what it does not.
What “local” concretely means
In a web application, code executes in your browser, on your machine. When you drop a PDF into a tool built this way, the file is read into memory as a binary buffer (ArrayBuffer), then manipulated by JavaScript libraries. Document Flare uses pdf-lib (@cantoo/pdf-lib fork) for merging, extraction and rotation, and pdfjs for page rendering.
Heavy computation is offloaded to Web Workers: separate execution threads that receive the document’s bytes, produce the result and hand it back to the main thread — all without leaving the page. At no point in this chain does a network request carry your file. The result is assembled in memory and offered for download via a local Blob object.
The practical consequence: a file that never leaves cannot be retained, logged or exposed on a server. Privacy no longer rests on a written policy but on the technical absence of transmission.
Trodat ID Protector — privacy stampInk roller that masks addresses and identifiers on paper before disposal.affiliate
What still travels over the network
“Local” does not mean “zero requests”. Marketing happily blurs two things worth separating: the document, which stays on your device, and the application, which necessarily arrives over the network.
- Page load: HTML, JavaScript, fonts and images transit from the hosting (Cloudflare, here) on each visit. A service worker caches the application shell for offline use — without caching your documents.
- AI and OCR models: some features download a model on first use. OCR relies on tesseract.js, whose language models are self-hosted then cached in IndexedDB; text embeddings download an ONNX model of about 115 MB from Hugging Face, then serve it from the browser cache. Traffic flows server-to-browser — the model comes down, your text does not go up. Inference itself runs on your device.
- Ads and analytics: on public pages only (home, guides, legal pages), the site loads the AdSense script — ad requests gated by consent — and Plausible, a cookieless analytics tool. The
/tools/routes are isolated: no AdSense, and the pageview tracker is a no-op that transmits no file name, size or content.
The threat model, honestly
Local processing removes one trust boundary: the remote server. That is real — and bounded.
What it protects against: interception in transit to a third-party service, operator-side storage, database leaks, commercial reuse of your documents, internal access at the provider.
What it does not protect against: an already compromised device (malware, keylogger), a browser extension that reads page content, a system administrator on a managed machine — or the application itself if its code were malicious; you still trust the code the site serves you, at every load. Local processing moves trust; it does not abolish it.
For an ordinary document, a transient upload to a serious service may be acceptable. For legal, medical or accounting records, the difference is structural: there is simply no server in the document’s loop to compromise.
How to verify it yourself
The promise “your files stay private” is testable in five minutes in the developer tools’ Network tab: drop a PDF, run the operation, and look for a POST or PUT request carrying roughly the file’s weight. Its absence is the expected signal; the remaining requests load the application or its models. The same protocol applied to the major cloud tools is in where do your files go.
A simple complement: reload the page, then cut the connection. A genuinely local tool keeps working; a server tool stalls the moment it must send the file.
Limits worth knowing
- Network inspection proves the absence of upload at the observed moment; it documents nothing about a future version. Re-run the test before a truly sensitive document.
- AI/OCR features need the initial model download: offline with no prior cache, they are unavailable.
- The capabilities declared as remote (Office conversions, server-side AI summary) are marked
REMOTE_OPTIONALin the catalog, require explicit consent and are currently excluded from public builds — the rest of the catalog is local. - In-memory processing imposes per-tool size limits (for instance 50 MB for most tools, 20 files and 50 MB total for merging; free OCR covers the first 100 pages).
For everyday use — merge, extract, rotate — the local approach of the merge tool and its neighbors in the catalog is directly verifiable, without taking anyone’s word for it. And if you are weighing a cloud suite against this approach, see a local alternative to iLovePDF.
The right hardware
Trodat ID Protector — privacy stampInk roller that masks addresses and identifiers on paper before disposal.affiliate
Amazon Basics — cross-cut shredderCross-cut sufficient for everyday documents; budget-friendly.affiliate
YubiKey 5 NFC — FIDO2 security keyHardware two-factor authentication: phishing-proof sign-in for sensitive accounts.affiliate
