Your files don't need to leave the device: building browser-local tools

Indie Maker — Thu, 01 Oct 2026 05:22:34 +0000

Most "free online tools" work like this: you upload your file to a server, it does the work, you download the result. For many tasks, that round trip is pointless — your browser can do the whole job locally, faster and more privately.

I learned this building a small toolbox of utilities, and the pattern is simpler than people expect. Here's the playbook.

Reading files without uploading. The File API gives you everything: an <input type="file"> plus URL.createObjectURL() lets you work with the file entirely in memory. No fetch, no FormData, no server involved at all.

Images: canvas does the heavy lifting. Compression and format conversion are just drawImage into a canvas followed by canvas.toBlob() with a quality setting, or toDataURL('image/webp') for conversion. Resizing is the same pipeline. The browser's image decoders are excellent — you get quality comparable to server-side tools for the common cases.

PDFs: real libraries run in the browser now. pdf-lib can merge and split PDFs purely client-side; pdf.js renders previews. These are the same libraries server tools use, just bundled for the browser. The main gotcha is memory: a 200MB PDF will hurt on a low-end phone, so process in chunks where you can and warn the user before tackling huge files.

Text and dev utilities are trivially local. JSON formatting, Base64, UUIDs, hashing, QR codes — all pure functions. There's never a reason for these to touch a network.

The architecture payoff. With zero backend, the whole thing is a static site. Hosting costs next to nothing, there are no servers to scale, and the privacy story writes itself: files never leave the device because there's nowhere for them to go. That's not a marketing line — it's a structural guarantee.

What to watch out for. Mobile Safari has quirks around large blobs and downloads; always test the download step (a[download] + object URL) on real devices. And be honest about limits: browser-local can't do OCR well or handle truly massive files — say so in the UI instead of failing mysteriously.

I put this approach into practice with Quick Toolbox (https://tools.toppn.com/) — 14 free utilities, all client-side, no sign-up. If you're building tools like these, start local-first and only add a server when the browser genuinely can't do the job.

DEV Community: Indie Maker

Your files don't need to leave the device: building browser-local tools