What stays on your device
The full document content. The extracted text and layout. The detection results. Your manual redactions. The exported file. None of that has to leave your browser tab for the redaction workflow to work.
Security & Processing Details
How RedactVault processes sensitive documents
A walk-through of where your document actually goes when you redact it with RedactVault: what runs in your browser, what touches our servers, what this protects against, and how to verify it yourself.
The data flow
What happens when you redact a document
Five steps, in order. Each one happens inside the browser tab unless we explicitly say otherwise.
1. You select a file
When you choose a document, your browser reads it into memory on your own device. This is the same mechanism a web app uses to preview an image you drag in — the file is handed to the page, not posted to a server.
2. Text and layout are extracted in the browser
Parsing PDFs, DOCX files, and images into the underlying text and page geometry happens entirely inside your browser tab using JavaScript and WebAssembly libraries. No part of the document needs to leave the page for this to work.
3. Detection runs in the browser
The fast detection layer is regex-based and runs directly in the page. The optional accurate detection layer uses an AI model that loads into your browser and runs in a Web Worker on your device. Face detection for images works the same way. The model files are static assets — they download once and execute locally.
4. You review and adjust
Approving or rejecting detections, drawing manual redactions, and navigating pages all happen in the page state. Nothing about this step requires a network call carrying document content.
5. Export happens in the browser
When you export, the redacted file is built in the browser and handed to your operating system as a normal download. The file goes from your browser to your disk without a server round-trip.
What does touch our servers
Account creation, sign-in, password reset, subscription and billing, workspace metadata (names, member lists, plan tier), and product analytics all use a normal backend the way any SaaS app does. Support requests you send us obviously reach us too. The line we draw is around document contents — those stay in the browser.
Why this design choice
Most "the file got leaked" incidents involve a file sitting somewhere it did not need to be: a vendor cache, a processing queue, a backup, an email attachment. If the document never has to be sent anywhere to be redacted, that whole category of risk goes away. It also means a request for our logs cannot return contents we never received.
What this design does not protect against
In-browser processing protects the file in transit and at rest on our infrastructure, because it is never on our infrastructure. It does not protect against threats already on the device running the browser: malware, a compromised browser extension with permission to read page content, screen recording, or someone watching over your shoulder. Those are device-security problems and they apply to any redaction tool — including ones that run entirely offline. Treat your endpoint as part of the trust boundary.
Verify it yourself
You do not have to take our word for any of this. Three ways to check:
- Open the browser developer tools (F12) and switch to the Network tab before you select a file. As you redact and export, you can watch which requests are made. Document contents are not in any request body.
- Disconnect from the network after the page has loaded and the detection model has downloaded. The redaction workflow continues to work because the processing is happening locally.
- Compare the upload behavior to a server-side tool. A server-side tool will show a multi-megabyte POST request when you submit your file. RedactVault does not.
Read this alongside the limitations page
In-browser processing is one half of an honest picture. The other half is where automated detection can miss things, where export behavior differs by file type, and what you still need to review by hand. That is on the limitations page.