The latest articles on DEV Community by Ali Tools (@qariyah_studio_82d635ffb2). https://dev.to/qariyah_studio_82d635ffb2 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%2F4199412%2F8c01702c-5721-47b3-8615-ba2c6de9ce8e.jpg https://dev.to/qariyah_studio_82d635ffb2 en Ali Tools Fri, 23 Oct 2026 04:21:01 +0000 https://dev.to/qariyah_studio_82d635ffb2/i-built-a-full-pdf-editor-that-runs-100-in-your-browser-no-uploads-no-servers-34c7 https://dev.to/qariyah_studio_82d635ffb2/i-built-a-full-pdf-editor-that-runs-100-in-your-browser-no-uploads-no-servers-34c7 <p>Every PDF tool I tried had the same problem: upload your file to some server, wait, download it back — and hope the site deletes it. Contracts, ID cards, bank statements... people upload their most private documents to strangers' servers every day, just to merge two pages or add a signature.</p> <p>So when I built the PDF editor for Ali Tools (alitools.online), I set one hard rule: <strong>the file never leaves the device.</strong> Everything — rendering, editing, merging, splitting, converting — happens locally in the browser tab.</p> <h2> How it works, in plain terms </h2> <ul> <li> <strong>Rendering:</strong> The document is drawn page-by-page onto canvas elements directly from the file you open. The parser runs in a Web Worker so the UI never freezes, even on a 200-page file.</li> <li> <strong>Editing:</strong> Text, images, shapes and signatures are absolutely-positioned layers on top of the rendered page. Nothing is baked in until you export.</li> <li> <strong>Export:</strong> On save, a fresh PDF is assembled in memory from the original file data plus your edits, and the browser downloads it. There is no upload step anywhere in the code path — you can verify this by opening the Network tab: zero requests carry your file.</li> <li> <strong>Conversions</strong> (PDF to Word, images to PDF, and the rest of the 628+ tools on the site) follow the same local-first pattern wherever the format allows it.</li> </ul> <h2> Why local-first matters </h2> <ol> <li> <strong>Privacy by architecture, not by promise.</strong> A "we delete files after 1 hour" policy is a promise. Code that never sends the file is a guarantee.</li> <li> <strong>Speed.</strong> No upload/download round-trips — a 50 MB file opens instantly because it never travels.</li> <li> <strong>Cost = $0 hosting for processing.</strong> Static files + the visitor's own CPU. That's how the site can afford to keep every tool free with no accounts and no limits.</li> </ol> <h2> Trade-offs I hit </h2> <ul> <li>Large PDFs on low-end phones need lazy page rendering (render on scroll, release off-screen canvases) or the tab runs out of memory.</li> <li>The editing bundle is heavy, so it is code-split: the editor downloads only when you actually open it, not on the landing page. That took our mobile PageSpeed from the 50s to the 80s+.</li> <li>Browser print pipelines differ just enough that "Print to PDF" output needs per-browser checks.</li> </ul> <p>The editor is free to use — no sign-up: <a href="https://alitools.online/pdf-editor/" rel="noopener noreferrer">https://alitools.online/pdf-editor/</a><br> And the full toolbox (image/video compressors, converters, calculators, generators, more PDF tools) lives at <a href="https://alitools.online/" rel="noopener noreferrer">https://alitools.online/</a></p> <p>If you build tools for the web: what's stopping you from going local-first? I'd genuinely like to hear where this approach breaks for your use case.</p> <p>— Ali Haider, maker of Ali Tools</p> webdev javascript productivity pdf