Why AegisPDF never uploads your file
“I can't send client documents to some website just to redact them.”
Most online PDF tools work the same way. You upload a file, a server does the work, you download the result.
That is fine for a restaurant menu. It is a problem for a contract, a medical record, or anything you have a professional duty to keep confidential. Somewhere in that flow, your document sat on a machine you do not control.
AegisPDF works the other way round. There is no upload. Redaction, OCR, signing, merging and splitting all happen on your own computer, inside the browser tab you already have open.
Document binaries never travel over the network.
A constraint, not a promise
"We don't store your files" is a policy. Policies change, and you have no way to check one from the outside.
What is different here is that there is no upload step to trust in the first place. The code that opens your PDF is running on your machine.
That is possible because the engine is compiled to WebAssembly, a format that lets compiled programs run inside a browser at close to native speed. It is the same technology that lets browsers run video editors and CAD tools without a server doing the work.
If you want to confirm it, open your browser's network tab and watch while a document processes. Nothing goes out.
Some traffic does reach our servers, and it is a short list:
- activating, refreshing or deactivating a license
- whatever you type into the feedback form, if you choose to use it
That is all of it. The app also downloads its OCR model files when you first use text recognition, which is a download rather than an upload, and no part of your document goes with the request.
The license check itself runs inside the WebAssembly sandbox. Your document is never part of it.
What this approach costs
There are real trade-offs here, and you should know them before relying on any of it.
Desktop browsers only. Mobile and tablet browsers are not supported, and that is a deliberate decision rather than an oversight. A phone browser cannot reliably give the engine the memory a large PDF needs, and shipping something that falls over on a 200 page file would be worse than not shipping it at all.
Your machine does the work. A big document takes as long as your laptop takes. There is no server farm quietly doing the heavy lifting, which keeps us honest about how fast the engine really is.
We cannot look at your file. If something behaves strangely, we cannot inspect the document, because we never had it. That makes support harder. We accepted the cost when we chose the architecture.
Why the engineering choices matter here
A PDF is not a friendly file format. It is a container that can hold fonts, embedded programs, compressed streams and layers of text you cannot see, and a fair proportion of the PDFs in the world are subtly malformed. Anything that opens one is dealing with input it cannot trust.
Running that work in WebAssembly gives you a hard boundary. Code inside the sandbox can only reach memory the browser handed it, and cannot touch the rest of your machine. That containment comes from where the code runs, not from how carefully it was written, which is what makes it worth relying on.
The engine is also built without any network bindings. The only browser features it can reach are the ones for images, files and the developer console. There is no code path from the engine to a network request, so the document has nowhere to go even if something inside it went wrong.
The engine itself is written in Rust. That is a correctness decision rather than a privacy one. This product lives or dies on edge cases, the strange documents that break assumptions, and we would rather have a compiler reject a whole class of mistakes than rely on someone spotting them in review.
Redaction is where this matters most
Most tools get redaction wrong in the same way.
Drawing a black rectangle over a name changes how the page looks. It does not remove anything. The text sits underneath, still selectable, still searchable, one copy and paste away from whoever you send the file to.
Real redaction has to delete the content itself. It also has to look in more than one place, because a PDF carries the same information in several forms at once.
Applying a redaction in AegisPDF is a single operation across six of them:
- the visible text
- hidden and OCR text layers, the invisible copy a scanner leaves behind
- annotations, which include comments and highlights
- document metadata, where the title and author routinely repeat the name you just removed
- embedded files, which travel inside the PDF as independent copies
- prior revisions, because a PDF keeps earlier saves inside itself and the pre-redaction version can still be sitting in the bytes
That last one catches people out. Save a document, redact it, save again, and the original text can still be recoverable from the same file.
This is the reason the engine exists at all. Redaction is a class of problem where nearly right and wrong are the same thing.