Turn Off Your WiFi and Try Our PDF Tools
Here's a test. Close this tab, go to ILovePDF, upload a PDF, and disconnect your WiFi halfway through. Watch what happens.
Now come back and try the same thing with any of our tools.
We'll wait.
## Why This Test Matters
Privacy policies are words. Promises are words. "We delete your files after one hour" — that's a sentence someone wrote. You can't verify it.
But the WiFi test isn't a promise. It's a technical fact. If a tool works without an internet connection, your files are being processed on your device. There's no server involved. Your file never traveled anywhere.
If it breaks without WiFi — loading spinner, error message, nothing happens — your file was going to a server. That's where the processing was happening. That's where your document existed, briefly, outside your control.
Most PDF tools fail the WiFi test. That's not a criticism of their intentions. It's just the architecture they chose.
## Why We Pass It
We built our tools on PDF.js and client-side JavaScript. The processing engine runs in your browser. Merge, split, compress, encrypt, redact — all of it executes on your device, using your device's memory and CPU.
We have servers. They serve the HTML, CSS, and JavaScript files that make up our interface. But the moment those files load in your browser, the processing capability is on your device. Your PDF never touches our servers.
Turn off WiFi after the page loads. Everything still works. The tool already has what it needs.
## What the Test Actually Proves
When a tool works offline, it proves:
- Your file isn't being transmitted over the network
- No server is involved in the processing
- No third party has access to your document's contents
- There's no retention period to worry about — nothing was retained
When a tool fails offline, it proves the opposite. Whatever the privacy policy says, the file went somewhere.
We'd rather prove it than say it.
## Open DevTools While You're At It
If the WiFi test convinces you, the DevTools test will over-convince you.
Open your browser's developer tools (F12 in most browsers), click the Network tab, then use one of our tools. Watch the requests.
You'll see requests for our static assets — the JavaScript files, maybe a font or two. You will not see a POST request carrying your PDF to a server. You will not see any outbound file transfer at all.
The Network tab records everything that leaves your browser. There's nowhere for us to hide uploads. The test is unambiguous.
## Why We Made It This Way
Partly because we were building the tool we'd want to use ourselves. We handle sensitive documents sometimes. We didn't want to think about which PDF tool was trustworthy on a given day.
Partly because it's just better engineering. Processing on your device means we don't pay for server compute per-file. We don't need to manage file queues or retention jobs. The architecture is simpler because we're not handling your files at all.
Privacy-by-design isn't just a principle. It's also good software architecture.
Turn off your WiFi. [Try any of our tools](/merge-pdf). We'll still be here when you reconnect.
Now come back and try the same thing with any of our tools.
We'll wait.
## Why This Test Matters
Privacy policies are words. Promises are words. "We delete your files after one hour" — that's a sentence someone wrote. You can't verify it.
But the WiFi test isn't a promise. It's a technical fact. If a tool works without an internet connection, your files are being processed on your device. There's no server involved. Your file never traveled anywhere.
If it breaks without WiFi — loading spinner, error message, nothing happens — your file was going to a server. That's where the processing was happening. That's where your document existed, briefly, outside your control.
Most PDF tools fail the WiFi test. That's not a criticism of their intentions. It's just the architecture they chose.
## Why We Pass It
We built our tools on PDF.js and client-side JavaScript. The processing engine runs in your browser. Merge, split, compress, encrypt, redact — all of it executes on your device, using your device's memory and CPU.
We have servers. They serve the HTML, CSS, and JavaScript files that make up our interface. But the moment those files load in your browser, the processing capability is on your device. Your PDF never touches our servers.
Turn off WiFi after the page loads. Everything still works. The tool already has what it needs.
## What the Test Actually Proves
When a tool works offline, it proves:
- Your file isn't being transmitted over the network
- No server is involved in the processing
- No third party has access to your document's contents
- There's no retention period to worry about — nothing was retained
When a tool fails offline, it proves the opposite. Whatever the privacy policy says, the file went somewhere.
We'd rather prove it than say it.
## Open DevTools While You're At It
If the WiFi test convinces you, the DevTools test will over-convince you.
Open your browser's developer tools (F12 in most browsers), click the Network tab, then use one of our tools. Watch the requests.
You'll see requests for our static assets — the JavaScript files, maybe a font or two. You will not see a POST request carrying your PDF to a server. You will not see any outbound file transfer at all.
The Network tab records everything that leaves your browser. There's nowhere for us to hide uploads. The test is unambiguous.
## Why We Made It This Way
Partly because we were building the tool we'd want to use ourselves. We handle sensitive documents sometimes. We didn't want to think about which PDF tool was trustworthy on a given day.
Partly because it's just better engineering. Processing on your device means we don't pay for server compute per-file. We don't need to manage file queues or retention jobs. The architecture is simpler because we're not handling your files at all.
Privacy-by-design isn't just a principle. It's also good software architecture.
Turn off your WiFi. [Try any of our tools](/merge-pdf). We'll still be here when you reconnect.