Every tool site says "we respect your privacy". Almost none can prove it, because the files you upload live on their server — even if only for seconds. "We delete it after" is a promise. Architecture is a proof.
I built a 398-tool utility site (https://toolfyra.com) on a simple rule: if a task can run client-side, the server never sees the file. Not "encrypted in transit" — never touched, period.
What that looks like in practice:
- Media tools (compress, trim, merge, convert): ffmpeg compiled to WASM, running in the browser tab. Your 4 GB screen recording never leaves the device — it can't, there's no upload path in the code.
- Documents (PDF merge/split, images): same pattern with WASM libraries.
- The few API-backed tools (previews, metadata): only the public URL you typed is sent — never a file.
-
Analytics: GA4 with
anonymize_ip, no user IDs, no cookie walls.
The interesting part isn't the tech, it's the constraints it forces on you:
- You can't cheat on UX. Server-side tools can brute-force quality. Client-side, you budget CPU: chunking, progress events, and honest limits ("your browser can merge 2 clips, not 20").
- Vendor discipline. WASM engines get vendored same-origin and version-pinned — a CDN outage can't take down your privacy story.
- Your privacy policy becomes short. Mine basically says "we never receive your files" and it's true by construction, which is the kind of claim an auditor can verify in the network tab.
The EU AI Act transparency wave and watermark debates are pushing this direction anyway — users are getting literate about what leaves their machine. If your privacy answer is a policy page, start moving workloads client-side now; if it's an architecture, you already have the better story to tell.
Top comments (0)