A statement such as ‘processed in your browser’ is easy to write and difficult to trust without evidence. Chrome and Edge include a Network panel that lets you inspect the requests made after you choose and process a file.
This article is not a tool tutorial. It explains a repeatable way to test a local-processing claim, distinguish ordinary website traffic from file uploads, and avoid conclusions that the evidence cannot support.
Three distinctions to make first
Assets and analytics may load without containing the file you selected.
Look for transfers close to the selected file size or requests containing its name or data.
A result applies to the browser, tool, and workflow you actually observed—not every future version.
How to check it yourself
- 1
Open the file tool in Chrome or Edge, then press F12 to open Developer Tools.
- 2
Select the Network panel, clear the log, leave Preserve log off, and show the Size and Method columns if possible.
- 3
Choose a test file, complete the actual conversion or editing operation, and download the result.
- 4
Review requests created during the operation by Method, Type, and Size. Check POST, PUT, PATCH, and unusually large requests first.
- 5
Open any suspicious request and inspect Payload or Request for multipart/form-data, the file name, or recognizable content.
- 6
For an additional check, switch Network throttling to Offline after the page and its engine have loaded, then repeat the operation.
What local browser processing means
A web page can read a user-selected File object—the browser's representation of that file—and create a result with features such as Canvas, WebAssembly, or a PDF library. In plain terms, the current device can perform the computation without handing the file to a processing server. Source and intermediate data remain in browser memory, while the finished file is downloaded from a temporary object URL.
This removes the upload wait and avoids storing file contents on the operator’s server. The tradeoff is that large files consume the visitor’s memory and CPU, so a tab can slow down or close on lower-memory devices.
Does every Network entry mean an upload?
No. A page may fetch CSS, fonts, processing engines, anonymous usage analytics, or enabled advertising. The useful question is not whether any connection occurred, but whether the selected file content was included in a request.
Uploads often leave clues such as POST or PUT methods (ways for the browser to send data), multipart/form-data bodies (a common file-upload format), and transferred sizes close to the source file. Implementations vary, so inspect both the request contents and its size rather than relying on one clue.
- Check whether the method is POST, PUT, or PATCH.
- Compare Transferred and Resource Size with the selected file size.
- Look for a file name, multipart/form-data, or recognizable file content in Payload.
- Compare requests created at operation start with those created just before download.
What an offline test can and cannot prove
If an operation still finishes after the page and processing engine have loaded and Network is switched to Offline, that is strong evidence that the core computation does not depend on a remote response. Do not refresh after going offline, because the browser may then be unable to reload the page assets themselves.
Offline success does not verify an entire privacy policy. When online, a site may still send anonymous analytics, advertising requests, or error reports that do not contain file contents. Review both the offline behavior and the online Network log.
Live browser check on August 20, 2026
In Chrome, we selected a 1,741,024-byte PNG at 1536×1024 and ran a 500KB-target WEBP compression. The result was 172.9KB at the original 1536×1024 dimensions and a reported quality of 95%.
From file selection through result generation, the local development server log showed only the initial page GET and no file-upload request. The implementation also reads the file with createImageBitmap, re-encodes it on a Canvas, and creates the result URL with URL.createObjectURL rather than sending the file or output Blob to a server.
This check is scoped to Chrome and the image-compression workflow observed on August 20, 2026. Anonymous production analytics may create a separate request, but its payload is limited to the tool, outcome, file count, and bucketed processing time—not a file name or file contents.
Common verification mistakes
Seeing a file name in the interface does not prove an upload. Browsers make the selected name and size available to the page locally. The reverse is also true: binary data may be sent without showing a file name in the interface, which is why the Network log matters.
You do not need a sensitive document for the test. Use a small image you created or a public sample, and give it a distinctive temporary name so traces are easier to spot in a request body.
Verifiable claims matter more
A privacy claim for a browser file tool should describe observable behavior. Checking for upload requests in the Network panel and repeating the operation offline after page load provides practical evidence about whether the core work is local.
Remember that ‘the file is not uploaded’ is different from ‘the website makes no external requests.’ Transparent services explain file processing, analytics, advertising, and external assets separately.