Why We Open-Source Our Privacy Claims
Anyone can write a privacy policy. We did. It took about an hour.
The thing is — a privacy policy is just text. It says what we intend. It doesn't prove what we do. The gap between intention and implementation is where most privacy failures live.
That's why we open-source our code.
## What "Verifiable" Actually Means
When we say your files never leave your device, we mean it. But you shouldn't take our word for it. You should check.
There are three ways to check:
**The WiFi test.** Disconnect from the internet and use any of our tools. They still work. If files were going to a server, they couldn't. This is the fastest, most obvious proof.
**The DevTools check.** Open your browser's developer tools, go to the Network tab, and watch what happens when you process a PDF. You'll see requests for static assets. You won't see your PDF being uploaded anywhere. The Network tab records every request your browser makes — there's nowhere to hide.
**The source code.** Our code is public. Anyone can read it, audit it, and verify that the processing logic runs locally. There's no hidden upload call. No telemetry sending file contents anywhere. You can see exactly what the code does.
Most PDF tools offer none of these. They offer a privacy policy. That's it.
## Why Open Source Is the Right Default for Privacy Tools
If your product's core claim is privacy, the burden of proof is on you to demonstrate it — not ask users to trust you.
Trust is fine for relationships. It's not the right foundation for security decisions. A privacy tool should be verifiable. Open source is what makes verification possible for anyone who wants to dig in, not just people who happen to have a packet sniffer running.
We think this should be the default for tools handling sensitive documents. It isn't. That's a problem with the industry, not an excuse for us to follow the pattern.
## What You'll Find If You Look
Our PDF processing is built on PDF.js — Mozilla's open-source PDF library. The operations we run on it execute in browser memory. Files are never serialised and sent over the network. The entire processing pipeline is contained in client-side code.
Check the source. Check the Network tab. Run the WiFi test.
If we're lying, those three checks will catch it. They won't — but you should verify that yourself, not because we told you to trust us.
## The Bigger Point
Verifiability is a property of systems, not companies. Good intentions don't survive staff changes, acquisitions, or business model pivots. A system that's verifiable stays verifiable regardless of what happens to the company.
That's why we built it this way. Not because we plan to go rogue — but because "trust us" isn't an acceptable privacy model for tools that handle sensitive documents.
[View our source on GitHub](https://github.com/whisperdocs) — or just open DevTools on any of our tools and check for yourself.
The thing is — a privacy policy is just text. It says what we intend. It doesn't prove what we do. The gap between intention and implementation is where most privacy failures live.
That's why we open-source our code.
## What "Verifiable" Actually Means
When we say your files never leave your device, we mean it. But you shouldn't take our word for it. You should check.
There are three ways to check:
**The WiFi test.** Disconnect from the internet and use any of our tools. They still work. If files were going to a server, they couldn't. This is the fastest, most obvious proof.
**The DevTools check.** Open your browser's developer tools, go to the Network tab, and watch what happens when you process a PDF. You'll see requests for static assets. You won't see your PDF being uploaded anywhere. The Network tab records every request your browser makes — there's nowhere to hide.
**The source code.** Our code is public. Anyone can read it, audit it, and verify that the processing logic runs locally. There's no hidden upload call. No telemetry sending file contents anywhere. You can see exactly what the code does.
Most PDF tools offer none of these. They offer a privacy policy. That's it.
## Why Open Source Is the Right Default for Privacy Tools
If your product's core claim is privacy, the burden of proof is on you to demonstrate it — not ask users to trust you.
Trust is fine for relationships. It's not the right foundation for security decisions. A privacy tool should be verifiable. Open source is what makes verification possible for anyone who wants to dig in, not just people who happen to have a packet sniffer running.
We think this should be the default for tools handling sensitive documents. It isn't. That's a problem with the industry, not an excuse for us to follow the pattern.
## What You'll Find If You Look
Our PDF processing is built on PDF.js — Mozilla's open-source PDF library. The operations we run on it execute in browser memory. Files are never serialised and sent over the network. The entire processing pipeline is contained in client-side code.
Check the source. Check the Network tab. Run the WiFi test.
If we're lying, those three checks will catch it. They won't — but you should verify that yourself, not because we told you to trust us.
## The Bigger Point
Verifiability is a property of systems, not companies. Good intentions don't survive staff changes, acquisitions, or business model pivots. A system that's verifiable stays verifiable regardless of what happens to the company.
That's why we built it this way. Not because we plan to go rogue — but because "trust us" isn't an acceptable privacy model for tools that handle sensitive documents.
[View our source on GitHub](https://github.com/whisperdocs) — or just open DevTools on any of our tools and check for yourself.