The latest articles on DEV Community by SAHU Khan (@sahu_khan_74873a8e161176b). https://dev.to/sahu_khan_74873a8e161176b https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4172557%2Ff6bd01f9-d6f8-442b-b7a2-0aa3b4473593.png https://dev.to/sahu_khan_74873a8e161176b en SAHU Khan Fri, 09 Oct 2026 05:35:05 +0000 https://dev.to/sahu_khan_74873a8e161176b/i-built-15-free-browser-tools-that-never-touch-a-server-2b7l https://dev.to/sahu_khan_74873a8e161176b/i-built-15-free-browser-tools-that-never-touch-a-server-2b7l <h1> I Built 15 Free Browser Tools That Never Touch a Server </h1> <p>A few months ago I started building something simple: free online tools that do their entire job inside your browser. Today the collection — Napizo — has 15 tools: PDF to JPG, JPG to PDF, PDF merger, PDF compressor, image compressor, image resizer, background remover, QR code generator, word counter, an AI caption generator, an InPage Urdu-to-Unicode converter, an EPUB splitter, and a few more.</p> <p>The unusual part isn't the tool list. It's the architecture: <strong>your files never leave your device.</strong> No uploads, no sign-up, no server processing your documents. Here's what I learned building it that way.</p> <h2> Why client-side was the right call </h2> <p>Most free tool sites work like this: you upload your file, their server processes it, you download the result. That model has real costs — bandwidth, compute, storage — which is exactly why those sites are covered in ads and paywalls.</p> <p>Running everything in the browser flips the economics: the user's device does the work, so there is no per-file server cost at all. It also kills the biggest trust question for a tools site — "where did my file go?" — because the answer is verifiable: nowhere.</p> <h2> The tech stack is boring (deliberately) </h2> <p>There's no backend framework. The stack is HTML/CSS/JavaScript plus battle-tested client-side libraries: PDF work runs on pdf.js and pdf-lib entirely in memory; image work uses the Canvas API and Web Workers; OCR for the PSD converter uses Tesseract.js rebuilt into layered files via ag-psd.</p> <p>"Boring" matters here: fewer moving parts means the tools keep working even on a plain static host, and every tool is auditable by anyone who opens dev tools.</p> <h2> The hard parts nobody warns you about </h2> <p><strong>1. Memory on mobile.</strong> A phone browser will kill your tab if you load a 100-page PDF into RAM carelessly. The fix: process pages in chunks, release object URLs promptly, and never keep the full decoded document in memory longer than necessary.</p> <p><strong>2. Trust signals.</strong> A free tools site with no company behind it has to earn trust differently: clear privacy copy ("files stay in your browser"), an honest limitations page, and About/Contact/Privacy/Terms pages that read like a real site. We published all of them before caring about SEO at all.</p> <p><strong>3. Saying what tools CAN'T do.</strong> The PSD converter's "editable text layers" are AI-reconstructed via OCR — fonts won't match the original. We say that on the tool page itself. Short-term it costs conversions; long-term it's the only way people come back.</p> <h2> What I'd tell anyone starting this </h2> <p>Ship the tool that solves one person's Tuesday-morning problem — compressing a PDF for an email attachment, resizing a photo for a form upload. Boring problems, done instantly, with zero friction. Then make the privacy story the headline, not a footnote.</p> <p>The full collection is live here if you want to try the tools: <a href="https://napizo.netlify.app" rel="noopener noreferrer">https://napizo.netlify.app</a></p> webdev productivity tools opensource