How I built a file converter that never uploads your files

Dinesh Kumar — Sat, 14 Nov 2026 12:12:43 +0000

Every time I needed to merge a couple of PDFs or turn an iPhone HEIC into a JPG, I hit the same wall: almost every “free online converter” wants me to upload my file to their server. For a meme, fine. For a signed contract, a payslip, or a passport scan? That’s a copy of a private document sitting on a machine I don’t control, for as long as that service decides to keep it.

So I built ConvertWarp around one rule: the file never leaves your device.

The core idea: no conversion backend at all

The interesting constraint is that there is no server-side conversion. There’s no upload endpoint, no processing queue, no “we’ll delete your file in 2 hours” promise to trust — because the file is never sent anywhere. Everything runs in the browser via WebAssembly.

The stack:

ffmpeg.wasm — audio/video. MP4→MP3, extract audio, compress video, MKV/MOV→MP4, GIF making. It’s literally FFmpeg compiled to WASM, running on the user’s CPU.
pdf-lib + pdf.js — PDF operations. Merge, split, compress, delete pages, rotate, PDF→image, image→PDF.
Tesseract.js — OCR. Image-to-text and scanned-PDF text extraction, entirely client-side.
Format-specific libs (HEIC decoding, Office/spreadsheet handling) for the long tail of ~70 tools.

The whole thing is a static export (Next.js) hosted on Cloudflare. No server runtime means no per-conversion CPU cost and nothing to scale — the user’s own device does the work. A nice side effect: once the WASM is cached, the tools work offline.

Why this is a genuinely better privacy model

The usual privacy pitch is “we delete your files.” That’s a promise. The in-browser model removes the need for the promise: open your browser’s Network tab while you convert, and you’ll see no file data leaving the page. Go offline and the conversion still works. There’s no server-side copy to leak, subpoena, or sell — it was never created.

That turned out to be the whole product’s identity: free, no signup, no watermarks, no size paywall, and private by architecture rather than by policy.

The trade-offs (because there are always trade-offs)

This approach isn’t free lunch:

Browser memory is the ceiling. A server can stream a 4GB video through FFmpeg; a browser tab can’t. Large video jobs are where client-side genuinely struggles, and I’m honest about that in the UI.
WASM is slower than native. For a big batch, a native desktop app will beat it. For the everyday “convert these 10 photos” case, it’s plenty fast and the privacy win is worth it.
Bundle size. ffmpeg.wasm and the PDF/OCR engines are big. Lazy-loading per tool (you only pull FFmpeg when you open a video tool) was essential to keep the initial load sane.
No server means no server-side features — things like scheduled jobs or huge-file handling are simply out of scope by design.
What I learned

The biggest lesson: a constraint can be the product. “No backend” started as a privacy idea and ended up shaping everything — the hosting (static/Cloudflare, basically free to run), the offline capability, and the honest marketing (“your files are never uploaded” is a fact you can verify, not a slogan).

If you’re building anything that handles users’ files, it’s worth asking how much actually needs a server. For a surprising amount of file manipulation, the answer is “none” — and WebAssembly has quietly made that practical.

If you want to poke at it, it’s live at convertwarp.com — I’d love feedback on the approach, and especially on what breaks.

Tags: #webdev #javascript #privacy #showdev

DEV Community: Dinesh Kumar

How I built a file converter that never uploads your files