Redacting a PDF without uploading it

The document you are about to redact is, by definition, the one you least want to send anywhere.

There is a circularity at the heart of most online redaction tools. You have a document containing something sensitive enough that it must be removed before anyone sees it — and the first thing the tool does is transmit that document, unredacted, to a stranger's server.

For a lot of files that is a perfectly acceptable risk. For a privileged legal document, a patient record, an HR investigation file or a source's identity, it may not be, and in some cases it is the specific thing your professional obligations forbid.

What uploading actually commits you to

Once the file leaves your machine, you are relying entirely on assurances you cannot check:

Retention. “Files deleted after one hour” is a policy, not a mechanism. You cannot verify it happened.
Backups. Deletion from the application does not imply deletion from snapshots, replicas, or object-storage versioning.
Sub-processors. The service may run on infrastructure in a jurisdiction you have not assessed, with support staff who can read what you sent.
Breach exposure. Your unredacted document is now part of somebody else's attack surface for as long as it exists.
Disclosure obligations. If you are subject to professional confidence rules, sending client material to an unassessed third party may itself be the breach — before anything goes wrong.

None of this requires the service to be dishonest. It only requires them to be a normal company with normal infrastructure.

Client-side processing, and how to check the claim

A browser is a capable computer. Reading a PDF, rendering pages, running OCR and writing a new file can all happen locally, with the document never crossing the network. That is how BLACKOUT works: the file is opened by your browser, and no request carrying it is ever made.

You do not have to take that on faith, and you should not — plenty of services claim it. Two checks anyone can run:

Watch the network. Open your browser's developer tools, go to the Network tab, then load a document and redact it. You will see the page's own assets load, and no request carrying your file.
Disconnect. Load the tool, turn off your Wi-Fi, then open a document and redact it. If it still works offline, the processing is genuinely local. Anything that needed a server would fail.

The second test is the honest one, and it works on any tool making this claim, including ours. The tool page also shows a live count of every network request the page has made since you opened it, so you can see the number stay put while you work.

What still touches a server, stated plainly

Being accurate about this matters more than sounding absolute. Three things do involve the network, none of them your document:

The page itself. Loading the site downloads the application code, as any website does.
The download check. Exporting asks our server whether this browser is entitled to a download. It sends no part of the document — only a signed cookie.
Payment. Handled by Stripe if you subscribe. We never see card details, and Stripe never sees your documents.

Analytics is off unless you opt in, and even then it records only which steps of the tool were reached — never a filename, a search term, or anything detected. The privacy policy spells this out.

The trade-offs of doing it locally

Client-side is not strictly better. It costs you three things:

Your machine does the work. A long document takes longer on an old laptop than it would on a server, and a very large one can exhaust a browser tab's memory.
First load is heavier. The rendering and OCR code has to reach your browser before anything can happen.
No cross-device state. Nothing is stored for you, so nothing follows you to another machine — including, by design, your saved profiles.

For documents whose contents are the whole problem, that is a trade worth making. For a 500-page bundle of nothing sensitive, a server-side tool may genuinely serve you better.