How to verify an online tool doesn't upload your files

A processing claim is testable. Any tool can say your files never leave your device; the claim becomes evidence only when the network traffic during a real task is observable and repeatable. This guide teaches one method — watch what the browser sends while the tool works — and then shows the same method running as a standing public artifact, so claims about Toolars can be checked rather than believed.

• Promises vs evidenceA label is a promise and a capture is evidence; the difference is that a capture can be replayed, inspected, and challenged.
• One method, any toolThe method is tool-agnostic: it runs in the browser's own network panel, takes about a minute, and works on any site you choose to test.
• Tested on ourselvesThis guide names no other service and asserts nothing about how any other site behaves; it teaches the check, then demonstrates it on Toolars' own published evidence.

The Network panel helps inspect requests during a test. Its evidence is limited to the browser context, channels, and time window you capture.

Keep recording through processing and download. Record the version, browser state, and capture scope; a DevTools log alone does not guarantee that every possible network channel was captured.

• Open and clear firstOpen the tool's page and the Network panel first — developer tools, then the Network tab — clear the log, and keep it recording. Loading the page will always produce requests for HTML, scripts, and styles; that shell traffic is expected.
• Run a sacrificial fileRun only the task you want to test, using a disposable test file. Background requests may still occur; inspect their payloads before attributing them to the task.
• Watch the actionPress the tool's action and watch the list. A local tool may fetch code, fonts, or engine assets on first use — and after a warm-up run, ideally nothing at all.

The skill is telling page traffic apart from data traffic. Shell traffic delivers the application to your browser; data traffic carries content away from it. The two look different in the panel once you know what to look for.

• Shell requestsScripts, styles, fonts, and engines are expected page resources. A familiar path, extension, or small request size does not prove that a request contains no user data; inspect the destination and payload.
• The upload signatureFile data can leave through a same-origin or cross-origin request. Inspect POST, PUT, multipart bodies and other data channels; method, destination, or size alone is not proof of an upload.
• Open itSize alone proves nothing in either direction: compressed chunks, resumable sessions, and WebSockets can split a transfer. The method, destination, and payload of the request are the evidence — open it and look.

A network log measures this run in this browser state — and browser state is exactly what caches and service workers exist to change. Reading the log well means controlling that state.

• Warm-up is normalOn a repeat visit, a warmed site serves its shell from disk or a service worker, and the panel shows far fewer requests than the first visit. Fewer requests after warm-up is what a healthy local tool looks like — it is not, by itself, proof of anything.
• Start from cleanFor a clean reading, start from a fresh browser profile or an incognito window, enable the panel's disable-cache option, and remember that incognito does not block service workers in every browser.
• Block the workerThe public harness starts each scenario in a fresh browser context with service workers blocked. This reduces interference from previous browser state; still record which resources were warmed up and when the measured window starts.

Embed a unique marker in a test file, then search the captured requests. No exact match means only that the marker was not found; encoding, compression, encryption, partial transfers, or incomplete capture can hide it.

Use the marker check alongside payload inspection and a documented capture scope. State what this run observed and what it could not rule out.

• Mark the fileMake a sacrificial file and embed a marker you generated yourself and have never published: a random UUID in a text layer, an image comment, a PDF note. Uniqueness is what makes a match meaningful.
• Search the trafficSearch captured URLs, query strings, and bodies. A match means the marker appears in a recorded outbound request; also check the request's status. This does not prove that the entire file was transferred. No match does not prove that no file data left the device.
• Repeat the checkA canary covers only the session you observed, which is why recurring, scheduled captures matter more than one thorough manual check.

Toolars runs the same method as a standing public artifact: a typed processing declaration for every tool, a Trust Center page with captured traffic, and a machine-readable receipt that states its limits as plainly as its results.

• Declared hostsThe Trust Center page lists every external host the site shell can reach, the security headers served with responses, and self-verify steps you can run by hand in the same network panel.
• Machine-readable receiptA machine-readable verification receipt at /privacy-proof/verification-receipt.json publishes the verification commands, the measured scenario results, the disclosed external hosts, and the release revision to compare against the site's X-Toolars-Release response header.
• Honest limitsThe receipt says what it does not prove as clearly as what it does: a measured window covers that run, not an audit of everything the service could ever do.

The open repository provides a runnable harness for the live site. Its checks cover the requests and test windows recorded by the script; consult the receipt for each run's outcome and limitations.

The harness lives in the public repository https://github.com/aixtral/toolars-open, under evidence-harness/. It is published under the MIT license, and it verifies the deployed site — the thing the claim is actually about — not a private staging copy.

• 6 configured scenariosThe script configures 6 scenarios: image conversion and download, HEIC conversion, OCR, PDF rotation, CSV relay, and a custom tool chain. Configuration is not a passing result: check each scenario's status, measured window, and release revision in the receipt.
• Three invariantsThe checks flag detected uploads, matching canary markers, and unexpected cross-origin requests. The disclosed first-party analytics proxy is counted separately. A pass covers these checks in the measured window, not every possible data transfer.
• Check the releaseA scheduled workflow is configured to capture the live site. Check the latest completed run, its outcome and release revision. The website receipt is an archived sample and is not automatically refreshed by that workflow. A failed or incomplete capture is not by itself evidence of a privacy leak.

A receipt is only as valuable as its reproducibility. The harness is built to be run by anyone, against the live origin, with results written to a file you can inspect line by line.

Zero requests means the recorder observed no requests in that measured window. It excludes any separately documented warm-up traffic and does not establish behavior outside the captured channels, version, or session.

• Clone and verifyClone the repository, enter evidence-harness/, install its dependencies and a Playwright Chromium, then run its verify script with the live site as the target origin.
• Exit codes are the verdictThe run writes privacy-proof-receipt.json and exits non-zero if anything unexpected crosses the boundary — a request carrying a body, a canary string in a URL, or a host that is not on the site's published list.
• Metadata onlyThe receipt records request metadata only — method, host, path, resource type, whether a body was present — never file contents, request bodies, or response bodies.

Honest verification includes its own boundaries. Knowing them keeps a clean network trace from being over-read into a guarantee it was never designed to be.

• One windowA clean trace covers the observed session — that run, that browser, that file. It does not audit a provider's servers, personnel, or future code.
• Your device mattersWhat leaves your device also depends on your device: a compromised browser, a malicious extension, or a shared profile can move data independently of any tool's architecture.
• Standing evidenceTreat every privacy claim — including the one this site makes — as standing evidence to be re-captured, not a lifetime guarantee. That is exactly why the harness re-runs on a schedule instead of resting on one good capture.