How to check whether a browser file tool uploads your file

1. Open a clean browser session and the tool you want to investigate.
2. Open Developer Tools, choose Network, and enable request recording. Preserve the log if a reload is needed.
3. Clear old requests, then select a synthetic file with a distinctive harmless marker.
4. Perform exactly one processing operation.
5. Inspect requests generated during the operation, especially Fetch/XHR and requests with a body.
6. Check the URL, method, content type, payload or form data, request size, initiator, and response.
7. Repeat after a fresh reload if the first run is ambiguous.

A browser may download JavaScript, CSS, fonts, images, a Web Worker, WebAssembly, or an OCR language file. It may also make a configuration, entitlement, session, or analytics request. Those are network activities, but they do not automatically contain the bytes of the file you selected.

The question is whether the application sends the file itself, or a transformed representation of its contents, to a server. That requires inspecting the relevant request rather than inferring from timing alone.

Open Developer Tools before selecting the file, then open the Network panel. Chrome records requests while DevTools is open; the panel can clear the request list, filter by resource type, and show request headers, payload, response, initiator, and timing details. See the official Chrome Network panel documentation.

1. Reload the tool with the Network panel already open.
2. Clear the log after the page has settled, or mark the initial-load requests mentally.
3. Select the synthetic test file and run one operation.
4. Filter to Fetch/XHR when useful, but also inspect other request types if the workflow loads a worker or model.
5. Open suspicious requests and inspect Headers, Payload, Initiator, and Timing.
6. Look for multipart form data, a binary body, a file name, a recognizable marker, or a request size consistent with the selected file.

Firefox calls its equivalent the Network Monitor. Open it from Web Developer Tools, start recording before the workflow, and select a request to inspect its details. The Firefox Network Monitor documentation describes the request list and detail view.

Microsoft Edge provides a Network tool in its Chromium-based DevTools. Its controls and request details are similar to Chrome, but labels can vary by browser version. Use the Microsoft Edge Network tool documentation for the current interface.

Create a harmless test file containing a distinctive string, such as ZANCTA-NETWORK-CHECK-2026 , where the format allows it. Searching request payloads for that marker can help distinguish ordinary application traffic from the contents of your test file.

This is a useful signal, not a perfect detector. The file could be compressed, encrypted, encoded, rendered to pixels, or transformed before transmission. Inspect the request structure and body characteristics as well, and avoid placing real private information in a test fixture.

A network inspection is evidence about a particular browser, deployment, fixture, workflow, and test time. It can show that a request with file-like data was observed, or that no request body was observed in the captured run. It cannot establish that every future version, browser extension, device, account state, or network condition will behave identically.

In particular, the absence of a literal marker or request body is not a mathematical proof that a file can never be transmitted. If the result matters, repeat the test in the browser and account state you actually plan to use.

The Phase 8F research harness captured four workflows against zancta.tech in Chromium via Playwright. The final run was timestamped 2026-09-14T18:29:17.883Z and recorded production commit 256d1ba022c87f15b353ed4410cb89ae9563e5b6. The harness used synthetic fixtures and recorded request metadata rather than storing complete request bodies. The Chromium version was not captured in the artifact.

In those captured runs, no request body was recorded after file selection and processing. That is a scoped observation, not a universal guarantee. The harness also saw ordinary application resources. For OCR, observed resource paths included /ocr/worker.min.js,/ocr/tesseract-core-relaxedsimd-lstm.wasm.js, and /ocr/eng.traineddata.gz. These are worker, WebAssembly, and language-model resources; their download does not by itself show that the selected image or PDF was uploaded.

The local processing guide explains the broader application boundary. For OCR-specific behavior, see browser OCR without uploading. For a PDF choice between embedded-text extraction and OCR, see PDF text extraction vs OCR.

You can apply the method to PDF Text Extractor, OCR, EXIF Cleaner, and PDF Compression.

• Use a synthetic fixture, not a real private document or photograph.
• Start recording before selecting the file.
• Inspect request bodies and destinations, not just the request count.
• Repeat after reload and note the browser, version, deployment, and workflow.
• Remember that extensions, the receiving service, and later sharing steps are outside this one test.