05
Some files you cannot put on a stranger’s computer. A patient record. A client file covered by privilege. An HR investigation naming three people. Something under an NDA that lists exactly who may see it. The job is ordinary — take out four names and a salary figure — but the obvious way to do it starts by handing the whole document to a company you have never heard of.
01
What uploading actually does
Dragging a file onto a web page feels like nothing happened. Mechanically it is a transfer. The bytes leave your machine, cross the network, and land on a server you have no access to. Something there opens the PDF, does the work, and gives you a download link.
By then your document has existed in several places at once: the server’s memory, almost certainly a temporary file on disk, possibly an object store behind it, and at least one access log noting that a file of that size arrived from your address. Some of that is deliberate. Some is just how servers get built.
The service will tell you files are deleted after an hour, or straight after processing. That may well be true. You cannot check it. Nothing you can run from outside separates a service that deletes on schedule from one that means to and has a broken cleanup job, or one whose nightly backups keep a copy for a month. You are trusting a claim about the inside of a machine you cannot see. That is not verification.
02
When that gap actually matters
For a poster with a phone number on it, trust is fine. Use whatever is quickest. For other documents the transfer is itself the event, before anything goes wrong.
A privileged document sent to a third-party processor has been shown to a third party. Whether that waives privilege is for your counsel, but you have created the question. Medical confidentiality does not pause because a vendor has a good reputation. Under GDPR, sending personal data to a service to be processed makes that service a processor: a contract under Article 28, an entry in your Article 30 record, a view on where the servers sit. All to delete one salary figure. And a standard NDA restricts disclosure to named parties or approved subcontractors. An online tool is neither.
None of this needs the vendor to be careless. The exposure exists the moment the file lands.
03
The three things you can actually use
There are three technical shapes.
Desktop software. A PDF application installed on your machine, working locally. Often the right answer: it works with no network at all, and the serious ones have had proper redaction features for years. The costs are real too — a licence, permission to install anything on a managed machine, and whatever old version your IT fleet is standardised on.
A browser tool that processes locally. Browsers can run PDF and OCR code in the page itself, so the file is read by JavaScript in your tab and never posted anywhere. Nothing to install. The catch is that from the outside it looks identical to the third option.
A server-side web tool. Upload, process, download. The most common shape by far, with real advantages: it runs on anything, and it handles files that would choke a tab.
All three describe themselves with the same words. Secure. Private. Your files are safe with us. That last one is a sentence only a server-side tool needs to say.
04
Two checks that settle it
You do not have to take anyone’s word for this.
Make a test PDF first — harmless, but a distinctive size, a few megabytes, so it is easy to spot in the list. Never run these checks with the real document.
The network check. Open the tool’s page, then open the browser’s developer tools (F12 on Windows and Linux, Cmd+Option+I on a Mac) and go to the Network tab. Tick “Preserve log” so a page navigation does not wipe the list. Load your test file and run the tool normally. You are looking for a request going out with a POST or PUT method and a size close to your file’s — click it and check the Payload or Request tab. That is your document leaving. Incoming responses of similar size are the opposite thing, a result coming back, which a local tool also produces. Direction is the whole signal.
The disconnect check. Load the page and let it finish completely. Then turn off Wi-Fi or unplug the cable. With the network down, load your document, do the redactions, and export. If the job completes, the processing happened on your machine, because there was nowhere else for it to happen.
Both have edges. A genuinely local tool can fail the disconnect test on a first visit, before it has finished downloading its own code and language assets, so try again on a second visit. And a tool could in principle hold an upload until you reconnect, which is why you run both.
05
The part nobody likes admitting
Local processing does not mean zero network traffic. The page has to come from somewhere, and OCR tools usually pull a language’s recognition model on first use, because shipping every language to every visitor would be absurd. Those requests show in your network tab. They carry no document content, but they are real, and a tool claiming total offline operation on a cold first run is overstating it.
hddn works this way, caveat included: document bytes are never sent to an app server, and OCR and detection assets are fetched the first time they are needed, then cached. Automatic detection finds candidates. It does not find everything, and you review each one before it is applied. Do not take that from me. Run the network check on it.
Tools get rewritten. A page that did everything locally in March can quietly grow a server-side path by September, and nothing in the interface has to change to tell you. The checks take four minutes and they test the version sitting in front of you.