WHY NO-SEND
Why we chose a no-send design
The default model for online tools is upload-based. This site goes the other way — here's why, and what trade-offs come with it.
The unverifiable trust gap inside upload-based services
Most online converters / editors are built on "upload, process, return." Many terms of service include "we delete uploads shortly after processing," and many operators do follow through on that. The structural problem is that the user has no way to verify the deletion, the absence of logs, or the absence of training-data reuse after the fact.
An upload-based service therefore embeds an unverifiable trust dependency on the operator. For confidential contracts, unreleased audio transcripts, photos with location metadata, or production JWTs — anything where unintended secondary use would be a problem — that unverifiable trust is a resource it is hard to spend cheaply.
Why this design only became practical recently
A decade ago, video conversion / PDF editing / large-image EXIF reading were the domain of server-side processing because JavaScript could not realistically host the relevant native libraries. WebAssembly (stable in major browsers since 2017) plus the ecosystem of ffmpeg.wasm, libheif-js, pdf-lib, PDF.js, kuromoji.js, transformers.js etc. that matured into the 2020s changed that — running those libraries in a browser tab is now within ordinary cost budgets.
The old assumption "browser-only = slow and limited" no longer holds. Desktop-app-class functionality can now ship as an install-free online tool. NoSend Tools sits on top of that technical inflection.
Knock-on benefits to the user experience
Treating "don't transmit" as a structural rule produces several incidental benefits: no account signup (no recipient to identify the user to), no server-side file-size cap (only device memory matters), many tools work offline once cached, and the design clears internal policies in organisations that forbid uploading sensitive data to external services.
The aim is to become the default landing place when someone hits "I don't want to upload this." Removing transmission as a structural option happens to align demand with the design.
Explicit trade-offs
There are real costs. Tools using ML models (OCR, transcription, background removal) ship a model of tens to hundreds of megabytes that loads on first use, so startup is slow. Video conversion runs on the device CPU and is meaningfully slower than a server-side service. Collaborative editing (e.g. two people editing the same PDF) is not realistic.
In exchange, transmission of input data is structurally absent. "Optimise for speed by accepting upload" vs "optimise for non-transmission by accepting slower processing" is a real choice, and NoSend Tools takes the latter as a site-wide stance.