MinoPDFDon't take our word for it — check the Network tab
Every "we delete your files" promise asks you to trust a server you cannot see. A browser-based tool asks nothing of the sort: you can watch the traffic yourself, in about 30 seconds, on any site — including this one.
Quick answer
Open DevTools → Network before you touch the tool, then drop in a file and run it. A server-side tool sends a request whose payload is roughly the size of your file — usually a POST to an upload endpoint. A browser-based tool sends nothing but the page's own assets. If you can unplug your network after the page loads and the tool still finishes, the file never left your device.
The 30-second test
Run this on MinoPDF, or on any other online PDF tool. The steps are identical — that is the point.
- 1Open a tool page and wait for it to finish loading.
- 2Press F12 (or Ctrl+Shift+I / Cmd+Option+I) and open the Network tab. Tick “Preserve log”.
- 3Drop in a PDF — ideally a large one, 5 MB or more — and run the tool.
- 4Read the request list: look for anything whose payload size is close to your file size, or any upload / POST request. On this site you should see none.
The offline variant
Load the page, then switch off Wi-Fi (or set DevTools to Offline) and run the tool again. If it still produces a result, the processing was never dependent on a server. This is the one claim you cannot fake.
What to look for in the request list
You are not looking for “no requests at all” — a web page always loads its own HTML, CSS, JS and fonts. You are looking for these three signals:
A request roughly the size of your file
Sort by size, or just compare: if you uploaded 8 MB and one request is 8 MB, that request carried your file.
An upload endpoint
Names containing upload, convert, process, api, or a file-storage domain are the giveaway — regardless of what the privacy page says.
A gap between “uploading” and “processing”
If the UI shows a progress bar before work begins, the file is in transit. Local tools start instantly because there is nothing to send.
Why “we delete your files in 2 hours” is not verifiable
This is not an accusation against any particular service. It is a limit of what an outside user can check. A deletion promise concerns a machine you do not control: how long the file sits in memory, whether it is written to disk or a temporary bucket, whether backups or logs retain a copy, which subprocessors touch it, and which jurisdiction it lands in. None of that is observable from the outside, and all of it can change without notice.
Encryption in transit does not solve this either. HTTPS protects the file on its way to the server — it says nothing about what happens after it arrives. That is why r/pdf's moderators put it plainly: the security claims cannot be verified, so don't upload sensitive information.
A browser-based tool removes the question instead of answering it. There is no server hop to audit, so there is nothing to promise.
What this site still can't do
A tool that claims to be perfect is usually hiding something. Here is where MinoPDF falls short — check this list before you rely on it for anything that matters.
- 100 MB per file and 50 files per batch. That limit is your device's memory, not a quota we impose — but it is real, and very large jobs will fail.
- No OCR. Scanned pages stay unsearchable, and text extraction on a scan returns nothing.
- No complex editing. Multi-column reflow, table reconstruction and font-level layout changes are out of scope.
- No CLI and no API. Browser-only processing is the reason your files stay local, and it is also the reason there is nothing to script against.
- Heavy batch work is still better on qpdf, OCRmyPDF or a self-hosted Stirling-PDF.
Try it on a real file
Open any tool, run the test above, and keep the DevTools tab open. We would rather you verified it than believed it.