What “local browser processing” really means

“Browser-based” does not automatically mean “uploaded”

A web page can process files in several ways. It may upload them to a server, send them to a third-party API, or operate on the browser’s local File objects. The File Audit Lab uses the third model. Selecting a folder gives the page temporary access to the selected objects inside that tab. The application builds the inventory from metadata and reads bytes only for an explicit hash request.

The distinction should be stated precisely. The site itself still uses a network: your browser requests HTML, CSS, JavaScript, and the synthetic demo from the hosting provider. Normal server logs may contain an IP address, user agent, request path, and timestamp. “No upload” refers to selected file content, not to the absence of all network traffic.

What happens after selection

1. The browser creates File objects for the selected files.
2. The application reads filename, relative path, size, MIME hint, and last-modified value.
3. Those records are kept in JavaScript memory for the life of the page.
4. If you request SHA-256, the application reads candidate bytes into memory and sends them to the browser’s Web Crypto implementation.
5. Exports are created as browser Blob objects and downloaded locally.

There is no account, database, upload endpoint, analytics SDK, or remote processing API in this release. You can inspect the page’s network panel while selecting a local folder: the selection and hash actions should not create requests containing the file data.

Why the tool does not request write access

Some modern browsers expose writable filesystem handles. They can support convenient rename and delete operations, but they also increase the consequence of a bug. This release avoids that capability. A report-only design works in more contexts and forces an explicit handoff between analysis and destructive action.

Threats this design reduces

• Accidental upload of confidential documents to an unknown processor.
• Server-side retention of selected files after the session.
• Automated deletion caused by a misclassified duplicate group.
• Silent overwrite during a bulk rename.
• Account compromise exposing an archive of prior uploads, because no such archive exists in the application.

Threats it does not eliminate

• A compromised browser, malicious extension, or device malware can still inspect local data.
• A compromised static site could serve altered JavaScript. Use HTTPS and verify the visible release information.
• The hosting provider still handles ordinary web requests.
• Exported inventories can reveal filenames and folder structure. Store them as carefully as the original folder.
• Hash values can be sensitive in some investigative contexts even though they do not contain the file bytes.

How to verify the boundary yourself

Open developer tools, select the Network panel, clear existing requests, then choose a test folder. Filter for fetch or xhr. The inventory and rename preview should update without a new upload request. The demo does fetch a public JSON asset, so perform the check with a local folder after the page has finished loading.

For confidential work, use a non-sensitive test folder first, review the source and network behavior, and consider disconnecting from the network after the page assets load. A local-only architecture reduces exposure, but the final trust decision belongs to you.