How to Verify a PDF Tool Does Not Upload Your Files (DevTools Guide)

Published July 16, 2026 · 7 min read

"Your files stay on your device." "100% private — no upload." "Processed locally in your browser." Marketing copy is cheap. Verification is free. In this guide you will learn the exact DevTools workflow to confirm whether any PDF tool uploads your files — no guessing, no trusting, no reading privacy policies. Just open F12 and watch the network.

What you need before you start

• A non-sensitive test PDF. Create a one-page document with dummy text. Do not use real contracts, tax forms, or anything confidential.
• Any modern browser — Chrome, Edge, Firefox, or Brave. The Network tab works the same way in all of them.
• Five minutes. The actual check takes 30 seconds once you know the steps.

Step 1: Open DevTools and prepare the Network tab

Navigate to the PDF tool you want to test. Before you drop any file, open DevTools:

• Press F12 (Windows/Linux) or Cmd+Option+I (Mac).
• Alternatively: right-click anywhere on the page, select Inspect or Inspect Element.

Once DevTools is open, click the Network tab at the top. Check the following settings:

• Preserve log — check this box. Without it, the log clears when the page navigates or reloads, and you may miss a delayed upload.
• Disable cache — check this too. It forces every request to hit the network, preventing cached responses from hiding real uploads.
• Click the 🗙 Clear button to wipe any existing entries so you start with a completely clean slate.

Your Network tab should now be empty and ready. The "Record" button (a red circle at the top-left of the Network panel) should be active — if it is gray, click it to start recording.

Step 2: Filter to the requests that matter

The Network tab logs everything — images, fonts, scripts, analytics beacons, ad trackers. Most of this is noise for our purpose. Use these filters to cut through it:

The most effective filter combination: click the Fetch/XHR button in the filter bar, then type method:POST in the filter text box. This shows you only JavaScript POST requests — the exact category an upload would fall into.

Step 3: Process a file and watch

Now drop your test PDF into the tool and initiate whatever action it offers — merge, compress, convert, sign. Keep your eyes on the Network tab as it happens. Here is what you should see:

Scenario A: No POST with your file — the tool is local

The Network list stays mostly empty (in the Fetch/XHR filter), or shows only a few small requests. None of them contain PDF data. This is the client-side architecture — the tool loaded your file into browser memory, processed it there, and offered a download link without ever sending your document to a server. You can confirm this further by clicking any POST request that does appear and checking the Payload tab — if it contains analytics data or a tiny JSON object rather than binary file data, your document is safe.

Scenario B: A large POST appears — the tool uploaded your file

A new entry appears in the Network list, typically with a name like upload, process, convert, or api/v1/merge. The Size column shows tens of kilobytes to megabytes — roughly matching your PDF size. The Type column shows xhr or fetch.

Click that entry and look at the Headers tab. Find Request Headers and look for:

• Content-Type: multipart/form-data — this is the standard way browsers upload files. A dead giveaway.
• Content-Type: application/pdf — the raw PDF bytes are being sent directly as the request body.
• Content-Type: application/octet-stream — binary data upload, likely your file.

Then switch to the Payload tab. You will see the raw form data — file name, file size, and sometimes a preview of the binary content — confirming your PDF was transmitted to a remote server.

Step 4: Check the response for suspicious downloads

An upload-based tool will often send your file up, process it, and send the result back as a download. In the Network tab, look for a response with:

• Content-Type: application/pdf in the Response Headers — the processed PDF coming back from the server.
• Content-Disposition: attachment — the server is pushing a file download.
• A response Size that is similar to or smaller than your original PDF — the processed version returning.

In a client-side tool, the download is triggered by JavaScript calling URL.createObjectURL() on a blob created in memory — no server round-trip. You will see no download-related network request for the output PDF.

Common false positives — what is NOT an upload

Not every network request you see is a file upload. The following are normal and do not indicate your PDF left your device:

• GET requests for JS, CSS, fonts, images. These are page assets the browser needs to render the tool interface. They are small and obviously not your PDF body.
• WebSocket connections. Some tools use WebSockets for real-time features. A WebSocket open does not mean your file was sent — inspect the messages tab to confirm.
• Analytics beacons (gtag, analytics, pixel). These fire tiny POST requests with tracking data. Their payload is JSON with page-view data, not PDF binary. Size is usually under 1 KB.
• Service worker or cache storage. These may show entries in the Application tab, not the Network tab. They are local browser storage.

What if the tool uses a Web Worker?

Some client-side PDF tools offload heavy processing to a Web Worker — a background thread that runs JavaScript separately from the main page. Web Workers execute locally in your browser and do not have direct network access unless explicitly programmed to use fetch(). A tool using Web Workers is not uploading your file; it is parallelizing the work across your device's CPU cores.

You can verify this too: in the Network tab, you will see a request to load the worker script (a GET for a .js file) — but no POST of your PDF data. The worker code is downloaded once and runs locally thereafter.

Testing multiple tools: a comparison table

Run this 30-second check on every PDF tool you evaluate. Here is what you can expect for common operations:

Privacy-first tools you can verify right now

LoveMyFile's PDF tools are designed to pass the Network-tab test transparently. Every tool listed on the private PDF tools page runs entirely in your browser. You can verify this yourself — open DevTools, load Merge PDF, Compress PDF, or Protect PDF and follow the steps above. The Network log will confirm: no upload.

Related reading

• Are Online PDF Tools Safe? — a broader decision framework for document sensitivity levels.
• Merge PDF Without Uploading — practical walkthrough with DevTools verification included.
• Is It Safe to Upload PDFs Online? — retention claims, risks, and the architectural difference that matters.