The latest articles on DEV Community by Need Any Tool (@needanytool). https://dev.to/needanytool 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%2F4087604%2F6f4e60bb-0230-4a39-90b4-3a45231186d3.png https://dev.to/needanytool en Need Any Tool Fri, 21 Aug 2026 05:56:48 +0000 https://dev.to/needanytool/how-we-built-browser-based-pdf-tools-without-uploading-user-files-366p https://dev.to/needanytool/how-we-built-browser-based-pdf-tools-without-uploading-user-files-366p <p>When we started building NeedAnyTool's PDF utilities, one architectural decision affected almost everything else: where should document processing happen?</p> <p>For supported operations, we wanted processing to happen inside the browser rather than requiring every PDF to be sent to a backend.</p> <p>Why this architecture interested us</p> <p>PDF utilities often work with sensitive files:</p> <ul> <li>invoices</li> <li>resumes</li> <li>contracts</li> <li>IDs</li> <li>academic documents</li> </ul> <p>If an operation can be performed locally, sending the source file to a remote server introduces infrastructure and privacy considerations that may not be necessary.</p> <p>Our web architecture</p> <p>NeedAnyTool is built with Next.js and organizes its utility products under the same application:</p> <p>**/pdf/</p> <p>/image/**</p> <p>Each tool owns the client-side functionality it requires while shared concerns such as analytics, SEO and navigation remain centralized.</p> <p>Keeping heavy processing away from unrelated pages</p> <p>One important consideration with a utility platform is bundle size.</p> <p>The homepage should not download PDF-processing libraries simply because a Merge PDF tool exists elsewhere in the application.</p> <p>Heavy processing dependencies are therefore loaded only where they're required.</p> <p>Analytics without document data</p> <p>We want to understand whether a tool actually helps users complete their task.</p> <p>So our analytics focuses on actions such as:</p> <ul> <li>tool_start</li> <li>tool_complete</li> <li>tool_download</li> </ul> <p>rather than collecting filenames or document contents.</p> <p>That gives us useful product information while keeping the analytics separated from the user's actual document data.</p> <p>What we're building toward</p> <p>NeedAnyTool currently includes PDF and Image utilities, but we're designing the architecture so additional categories can be introduced without turning the application into a collection of unrelated standalone projects.</p> <p>We're still improving this architecture, and I'd be interested in hearing how other developers approach browser-based document processing.</p> <p>Android app: <a href="https://play.google.com/store/apps/details?id=com.needanytool.pdftoolkit" rel="noopener noreferrer"></a></p> <p>Web tools: <a href="https://needanytool.com" rel="noopener noreferrer"></a></p> architecture nextjs privacy webdev