Skip to content
All guides

PDF Privacy & Productivity

How to verify that a PDF tool does not upload your file

Quick answer

Load the tool first, open Developer Tools, clear the Network list, then add and process a harmless test PDF. Inspect requests made after file selection: application code may have loaded earlier, but there should be no POST, PUT or request payload containing the document. Repeat the test after a hard refresh and distinguish clearly labeled server-assisted features from local ones.

“Your files never leave your device” is a technical claim that can be tested. Modern browser developer tools show the network requests a page makes, including their timing, method, destination and—in many cases—the size or payload. You do not need to trust a badge when you can observe what happens after selecting a file.

Use a harmless test document rather than confidential material during the audit. Create a one-page PDF containing a unique phrase such as NETWORK-CHECK-7421. That makes it easier to recognize the content if a request payload is visible and avoids exposing real information while you learn the tools.

Establish a clean starting point

Open the PDF tool and wait for the page to finish loading. Press F12 or use the browser menu to open Developer Tools, then choose the Network panel. The panel will already contain requests for JavaScript, fonts, analytics and other page resources. Clear the list so the next entries correspond to file selection and processing. Keep recording enabled.

Some applications download a WebAssembly engine, worker script or language model only when a feature is first used. Those downloads come from the site to your browser; they are not uploads of your document. Direction, request method, domain and payload help distinguish them. A large GET for an OCR model is different from a POST carrying file bytes.

Select and process the test file

Add the harmless PDF but do not immediately click away from the Network panel. Note any new requests. Then run the transformation and watch again. Local processing can consume CPU and memory without creating a network row. If a request appears, select it and inspect the URL, method, request headers, payload and transferred size.

An upload normally uses POST, PUT or a similar method and sends a request body. The destination might be an API, storage service or conversion endpoint. Search visible payload text for the unique phrase when the browser exposes it. Binary documents may not be readable in the panel, so a large request body immediately after selection still deserves an explanation from the provider.

Account for analytics, ads and error reporting

A local document tool may still make unrelated requests for consent management, advertising, page analytics or error reports. “No file upload” does not mean “the website is completely offline from the moment it opens.” The relevant question is whether document content, extracted text, filenames or generated results are transmitted. Read the privacy policy to understand the non-document requests.

Be especially careful with error reporting. A well-designed tool should not attach document bytes or extracted text to an error report. Triggering an artificial error is not always practical, so review the provider's published architecture and, when source is available, the code path that sends diagnostics.

Recognize clearly disclosed exceptions

Some transformations require a server. FeelPDF labels Word, Excel and PowerPoint conversion as EU server-assisted because a full office rendering engine is not practical in the current browser implementation. Those routes should create a network request carrying the file; the important controls are clear notice before selection, transport encryption, minimal logging and a defined retention policy.

Repeat your local-tool test after a hard refresh and in a private window if extensions or cached resources create confusion. Record screenshots of the Network panel and the tested URL if the result supports a compliance decision. A single observation cannot prove future behaviour, but it is concrete evidence for the version and workflow you actually used.

Use the result to make a proportionate choice

For an ordinary public brochure, a reputable server converter may be perfectly acceptable. For medical, legal, financial or identity documents, local processing removes one unnecessary transfer and simplifies the trust boundary. Match the tool to the sensitivity rather than treating every PDF as identical.

Finally, remember the rest of the lifecycle. A local transformation can still leave sensitive files in browser downloads, cloud-synced folders or backups. Network verification answers where processing happened; safe storage and deliberate sharing answer what happens next.

Questions readers ask

Does any network request mean my PDF was uploaded?
No. Scripts, fonts, analytics and processing engines can be downloaded without carrying your document. Inspect method, destination and payload.
What request method usually indicates an upload?
POST and PUT commonly carry request bodies, but method alone is not proof; inspect the request details and timing.
Can a browser tool work fully offline?
Many local tools can after their code has loaded. Features with large on-demand models may need an initial download.

Tools used in this guide