HOW IT WORKS
How tools run entirely in your browser
Three angles on how each NoSend Tools tool runs without a server: standard browser APIs, WebAssembly libraries we ship, and the (non-existent) network path that user data takes.
1. Tools that use only browser-native APIs
Many of the text, crypto, and time tools need no extra libraries — only what the browser ships. Base64 encoding pipes UTF-8 bytes through TextEncoder and into btoa; JWT signature verification calls SubtleCrypto's `verify(...)`; hashing calls `subtle.digest('SHA-256', bytes)` directly; timezone conversion uses Intl.DateTimeFormat plus IANA tz identifiers and delegates to the browser's native implementation.
These browser APIs run inside the page sandbox. Their inputs and outputs do not get transmitted to any server automatically, and the tool code itself never invokes `fetch` or `XMLHttpRequest` on user-supplied content. The whole round-trip stays in page memory.
2. Heavy libraries shipped via WebAssembly
Video conversion (ffmpeg.wasm), HEIC decoding (libheif-js), PDF manipulation (pdf-lib / PDF.js), PDF password handling (qpdf compiled to WASM), Japanese morphological analysis (kuromoji.js), and audio / image ML models (transformers.js + Whisper / RMBG) are native C / C++ / Rust libraries compiled to WebAssembly and shipped into the page.
WebAssembly is a sandbox inside the same process as ECMAScript. It only uses capabilities the host (browser) granted it — DOM access, file picking, memory allocation. A WASM module cannot open a network socket on its own. Data lives in WASM's linear memory or in JavaScript TypedArrays, with copy / view operations across the boundary. Loading 30 MB of ffmpeg.wasm at first use is not the same thing as uploading your video — the WASM bytes are the tool, not your data.
3. The actual network path: there isn't one
A file the user picks through a file dialog or drag-and-drops reaches the page process via `<input type="file">` or `FileSystemFileEntry`. NoSend Tools limits the journey from there to "in-browser processing → local download" only. There is no tool whose code places file content into the body of a `fetch`. The Report dialog only sends text the user typed by hand; tool input is never auto-attached.
Verification is straightforward: open DevTools, switch to the Network tab with Preserve log enabled, exercise the tool normally, and observe that the only requests are the initial load of the tool itself. For code-level audit, the full source for the site is at otomomik/nosend-tools on GitHub.
4. Static site + Cloudflare Workers Static Assets
The site itself is a static build (Astro SSG) producing all 743 pages ahead of time, served via Cloudflare Workers Static Assets. The Worker script does not assemble responses dynamically for tool pages — every page a user touches is plain pre-built HTML.
The only dynamic path is the Report dialog form, which writes to Cloudflare D1 (see the Privacy Policy for details). Tool input data does not flow through it. The Google AdSense SDK is loaded for ad serving, but the site code does not contain a path that transmits tool input to the ad provider.