Audit "we don't send your data" yourself with DevTools and GitHub
A privacy claim in a footer is just trust. NoSend Tools is built so the claim is verifiable in two ways: open DevTools and see no requests, or read the source on GitHub. Here is how to do each.
The gap between "we don't send your data" and not sending it
More online tools advertise themselves as privacy-respecting these days, but in many cases the only artefact is a sentence in the policy page: "runs on the client side" or "your data is not transmitted." Browser-side code is technically auditable because it runs in your browser, but reading minified JavaScript at scale is not a realistic ask of users.
Declarations without practical verifiability shift the trust back to the operator. NoSend Tools tries to close that gap by making both verifiability paths trivially exercisable — DevTools and a public GitHub repository.
Open the Network tab and watch the requests
On any tool page, open DevTools (Chrome / Firefox / Safari), switch to the Network tab, enable Preserve log, and start recording. Run the tool normally — pick files, click Run, download the result. The requests you will see are limited to the initial load of HTML / JS / CSS / WASM for that tool, plus the shared analytics pixel. None of them carry your input as a body.
If a request carrying your input ever appears, the site's claim has broken. This works without specialised security tooling because the browser already shows the request URL and body in a human-readable format. Run the same check against any competing service and the architectural difference becomes visible.
Read the source on GitHub
Network-tab inspection is a runtime check. The complementary path is to read the code: the repository is open at otomomik/nosend-tools. Each tool lives in `src/tools/<category>/<slug>/`, and you can confirm directly that there is no file-upload endpoint, that each tool's body never calls `fetch` on user input, and which libraries it depends on.
All dependencies are listed on the /libraries page with their licenses and repository URLs. From there you can follow each npm package upstream. "The JS running in your browser matches the JS we publish" is a separate concern (deploy signing, SRI), but the code-level audit and the runtime check together cover most of the surface area people care about in practice.