Published 22 August 2026 · 9 min read
There is a specific moment most people recognise. You need to remove two pages from a PDF, or shrink it below an upload limit, or sign it. You search, you find a free online tool, you drag the file in — and somewhere between dropping it and clicking the button, you notice what the document actually is. A contract. A payslip. A scan of your passport. And you are about to hand a copy of it to a company you had not heard of ninety seconds ago.
Usually you do it anyway, because the alternative is buying Acrobat. This guide is about the third option: doing the same work without the file ever leaving your device.
When you use a typical online PDF tool, your file is transmitted over the network to that company's servers, written into memory or onto disk there, processed by software you cannot inspect, and then a result is sent back. Afterwards the original is deleted according to a policy — Smallpdf and PDF24 state roughly an hour, iLovePDF states two.
None of that is sinister. These are real companies with real security teams, and they publish those policies openly. But it is worth being precise about what the policy is: a promise about what happens to a copy of your document that now exists on infrastructure you do not control. Promises can be kept perfectly and still fail you, because a promise cannot protect against a misconfigured storage bucket, a compromised employee account, a subpoena, or an acquisition that changes who owns the servers.
The useful question is not "is this company trustworthy?" It is "does this task require a copy of my document to exist anywhere except my laptop?" For most PDF work, the answer is no.
For a long time server-side was the only practical option. Browsers were too slow to parse and rewrite a PDF, and JavaScript was the only language available. Both of those changed.
WebAssembly lets a browser run compiled code at close to native speed. Libraries that previously had to live on a server — PDF engines, image codecs, OCR — can now be compiled and shipped to the browser as part of a web page. The code is sandboxed: it cannot read your file system or reach other tabs, only the data you hand it.
The Canvas API handles pixel work — rendering a PDF page to an image, cropping, resizing, re-encoding — using your GPU. Web Workers run the heavy jobs on background threads so the page does not freeze while a 200-page document is rewritten.
Put together, that is enough to do most everyday PDF work entirely inside a browser tab, with the network uninvolved after the page has loaded.
These all work fully client-side, and each links to the tool that does it:
Anyone claiming a browser can do everything is overselling. Four things remain meaningfully better server-side, and it is worth knowing which:
If your task is on that list, use a server-based tool deliberately and knowingly. That is a reasonable trade — it is only a bad one when it is made for you by default.
Any site can write "100% secure" on its homepage. The claim is worth nothing unless you can test it, and the good news is that you can, in under a minute.
A second test is even simpler: load the page, disconnect from the internet, and try to use it. Genuinely local tools keep working because the code is already in your browser. Server-based ones cannot.
A third signal, for the technically inclined: check the response headers for a Content-Security-Policy. A site that sends connect-src 'self' has instructed your browser to refuse network requests to any other host — which means even a bug could not quietly ship your file somewhere.
Each of these takes one part of the problem and works through it properly.
Most PDF work does not require anyone else's computer. Where it genuinely does — huge files, serious OCR, Office conversion, certificate signing — use a server tool on purpose. Everywhere else, keep the document where it already is, and pick tools that let you verify that rather than asking you to believe it.
FilePilot's PDF tools and image tools all run locally. So does the explanation of how, including where they fall short.
Free Online PDF Tools — runs in your browser, nothing is uploaded.
Yes, for most tasks. Merging, splitting, compressing, converting, reordering, redacting, signing and watermarking can all run in a browser using WebAssembly and the Canvas API. Heavy OCR, very large files, faithful Office-format conversion and certificate-based digital signatures still work better server-side.
Open your browser's developer tools, go to the Network tab, and run the tool. An upload shows as a request roughly the size of your document. You can also load the page, disconnect from the internet, and see whether the tool still works — local ones do.
For everyday operations, no. For compliance work — PDF/A conformance, certified redaction, accessibility tagging, certificate-based signatures — Acrobat remains the correct tool and browser-based editors are not a substitute.
Yes, though the memory limits are tighter than on a laptop, so very large documents are more likely to fail. The processing still happens on the device rather than on a server.