Every file-tool landing page says "secure." The word is doing two very different jobs. For upload-based tools it means "we promise to be careful with your file on our computers." For client-side tools it means "your file never reaches our computers." One is a policy; the other is an architecture. Policies can change, be violated, or be subpoenaed. Architecture can't.
What "upload and process" really involves
When a converter or splitter uploads your file, the minimum true statements are: the file crossed the network; it existed in plaintext on someone else's infrastructure (TLS protects transit, not the server that decrypts it to do the work); and copies may persist in temp storage, task queues, crash dumps, and backups beyond any advertised deletion window. Add the normal realities of the free-tool economy — third-party processors, ad-tech, breach risk, acquisition — and "deleted after 2 hours" is a hope stacked on a promise.
None of this requires bad intent. It's just what having the file at all implies. The strongest privacy guarantee available is the boring one: don't transmit the file.
Why file tools ever uploaded in the first place
Ten years ago browsers couldn't do the work. Today the reasons are mostly gone:
- File System & File APIs read a dropped file into memory without any network step
- Canvas and WebCodecs decode, slice, and re-encode images and video
- Web Audio decodes any playable audio into raw samples
- WebAssembly runs full libraries (PDF parsers, codecs) at near-native speed
- Blob URLs save results straight to your download folder
Splitting an image, extracting PDF pages, cutting audio — these run in milliseconds on a laptop. The upload was never for your benefit; it centralizes processing so the operator can meter, watermark, and upsell it.
How to verify (don't trust, test)
- Network tab. Open DevTools → Network, then drop a file into the tool. Local processing shows no request carrying your file — no POST body, no storage-bucket PUT.
- Airplane mode. Load the page, disconnect, use the tool. Local tools work offline; upload tools error out.
- File size behavior. A 2 GB video that opens instantly wasn't uploaded anywhere — physics forbids it.
Every split.tools utility passes all three tests: the image, PDF, audio, and video splitters do all parsing, cutting, and packaging in your tab's memory.
The honest limits
Client-side isn't magic dust. The claim covers the files; a page could still run analytics scripts (check your blocker's report), and your browser, extensions, and OS still see everything you do locally — the same trust you extend to every app you run. What client-side architecture eliminates is the new party: the tool's servers, storage, staff, and data policies. For your contracts, medical records, and unreleased work, that's the party worth eliminating.
More on the machinery in the browser APIs behind split.tools.