“Your files stay private” is an easy promise to display. Your browser’s Network tab lets you verify it, with no special skill and in five minutes. Here is the protocol to apply before entrusting a contract, a statement or an administrative file to an online PDF tool.
The test: watch what leaves when you drop the file
- Open the developer tools:
F12, orCmd+Alt+Ion Mac. - Go to the Network tab.
- Check Preserve log to keep the trace between screens.
- Drop a PDF whose size you know — say 4 MB.
- Run the operation and sort requests by size or method.
What should catch your eye: a POST or PUT request whose body carries roughly the file’s weight. In the details, you will often see multipart/form-data, the document name, or an endpoint like /upload, /task or /api.
Reading the Network tab without mixing up the flows
Start by clearing the log, then filter on Fetch/XHR: those are usually the requests triggered by the application. The Method, Type and Size columns separate a multi-MB POST from a script or a font. Then open the request and look at Headers and Payload; the Initiator column shows which script triggered it.
The important point is therefore not “zero traffic” but zero traffic carrying the document. A web application normally loads its HTML, JavaScript files, styles and fonts. It may also receive a computation model. On Document Flare, the multilingual Transformers.js model is about 115 MB and arrives from Hugging Face on first explicit use; inference then stays local. On public pages, analytics scripts and, on eligible pages, AdSense also produce their own lines. These application flows are not an upload of the PDF.
To clear any doubt, compare timing, direction and volume: a model is a response received by the browser, while a sent document appears in the body of an outgoing request. Re-running the test with a PDF of a different size also helps: if the POST size varies with the document, the evidence becomes much stronger.
How to interpret the result
- A large request at drop time: the file leaves to be processed on a server. That is not necessarily dishonest — it is how a cloud service normally works — but the document leaves your technical control.
- No request containing the document: processing is done by the browser. Requests may exist to load the page, its fonts or an AI model resource; they do not carry the PDF.
- A final download from a service domain: the result was generated server-side and sent back — another sign of remote processing.
The complementary test: re-run the operation offline
Offline mode provides a different kind of proof: it checks that the computation does not depend on a server round-trip. First run a full operation online so the application and, if the feature needs it, its OCR or AI model get loaded. In DevTools, open Network, pick Offline in the throttling dropdown, then re-run the same operation with another file. Do not close the tab between attempts.
If the operation succeeds and the result is generated, its engine was available locally. If it fails, that does not automatically prove the PDF would have been sent: an on-demand module or a model missing from cache may simply be absent. Turn the network back on, run the feature once, then retry offline. For a fair benchmark, record “works after first load” and “works offline on first visit” separately — the second property is far more demanding.
In Document Flare, the service worker caches the minimal shell — entry page, manifest and icons — and can re-serve the entry page during offline navigation. The other JavaScript, CSS and resource files depend on the browser’s HTTP cache. Tesseract.js keeps the OCR language models in IndexedDB after their first download; Transformers.js serves the embeddings model from the Cache API after first use. Without that first caching, an OCR or AI feature may therefore be unavailable offline, even though no document is ever uploaded.
What Document Flare shows
Document Flare is built as a static application: after the site loads, processing runs in the browser. Dropping a PDF into the merge tool triggers no request carrying the document; the computation shows up as local activity (parsing, file writing) rather than a network send.
Two honest exceptions to know: AI features may download a model once — data flows server-to-browser, never the reverse — and public pages displaying ads use the usual advertising requests, kept separate from the tool routes.
Why this verification matters
A privacy policy states intent; the Network tab shows fact. For a mundane document, a transient upload may be acceptable. For accounting, medical or legal records, the difference is structural: a file that never leaves cannot be retained, logged or exposed server-side.
Limits of the test
- An encrypted HTTPS request hides content, but not size or timing: a multi-MB body at drop time remains telling.
- A tool may send the file later, on clicking “Process” rather than at drop: observe the whole chain.
- The test proves absence of upload at the observed moment; it does not document what the service would do in another version. Re-run it before a truly sensitive document.
The reflex to keep
Before using an online PDF tool for an important document: F12, Network, drop the file, observe. If the PDF leaves in a POST to a third-party domain, you know where it goes. If no request carries it and the tool still works offline, the “local” promise is verifiable — and it is the only one that does not rest on trust.
