English

Images & photos · Image Metadata Privacy Tool

How to Verify a Metadata Stripper Never Uploads Your Photo

· How it works

image-privacy browser-processing privacy

A browser tab processing a photo locally while a crossed network arrow remains empty
Original ToolAcre vector illustration

'Runs in your browser' is a claim you can check. This post shows how to open the network panel, process a photo and read what did and did not leave the tab, and what a strict Content Security Policy adds to that assurance.

Why an upload risk deserves verification

The workbook asserted that free tools quietly upload, but no repository source establishes how unrelated services behave. The verifiable risk is simpler: a selected photograph is sensitive input, and a browser page can either process it locally or send it elsewhere. Inspecting requests and reading the actual code separates those designs without accusing a service on assumption.

Opening the network panel — where to find it in common browsers, clearing the log, and keeping it open while you work

Open developer tools before selecting a test image, choose the Network panel, clear old entries and preserve the log if navigation is possible. Then select, inspect, strip, verify and download. Requests for page assets or disclosed analytics are not the same as a request carrying the photograph, so examine method, initiator and payload rather than treating any network row as an upload.

What a genuine local tool looks like — page assets load once, then no request appears when you drop, inspect or strip a photo

A genuine local path obtains a File, awaits file.arrayBuffer(), constructs a Uint8Array and passes it to readMetadata or stripMetadata. The output becomes a Blob and downloadBlob creates the user’s copy. ToolAcre’s panel follows that sequence, and the core test installs a network guard while reading and stripping JPEG, PNG and WebP inputs.

Why execution context does not determine network behaviour

The workbook treated a Web Worker as proof of privacy, but workers can make requests and main-thread code can remain completely local. This tool’s shipped panel runs the metadata calls directly on the main thread. Network behaviour must therefore be established from calls and observations, not inferred from which JavaScript execution context performs the arithmetic.

What the implementation and tests prove

The repository does not provide a Content Security Policy claim for this article to quote. What it does provide is stronger evidence about the relevant path: config privacy statements limit the promise, panel source contains no request for file data, and a forbidNetwork test records zero attempts during core processing. Those facts support the file-handling claim without overstating the whole page.

Worked example: a full inspect-strip-download run — watching the panel from file drop to saved file and reading the empty request list

Run the complete cycle because an inspector can be local while a later download or verification step is not. In ToolAcre, inspection reads bytes, removal rewrites them in memory, verification re-parses the cleaned array and download uses a Blob. The network log should show no request whose body contains the source or result, matching the tested core behaviour.

What a network-panel check does not prove

A network-panel observation covers that session and configuration, not every future deployment or browser extension. It also cannot prove that unrelated page scripts collect nothing; the privacy statement explicitly separates disclosed analytics from file processing. Use a non-sensitive test file for verification and offline software for material whose handling cannot tolerate any page-level connection.

Takeaway: verify, then trust — the Image Metadata Privacy Tool is built to pass this test, and you can repeat it any time

Verify, then trust the narrow claim. ToolAcre can support its promise because source, tests and an observable browser run agree that image bytes stay in the tab’s processing path. Repeat the check after major site or browser changes, distinguish static resource requests from file transfer and avoid turning “local file processing” into the broader claim that a web page makes no connections at all.