The latest articles on DEV Community by Woody WK (@filecpu). https://dev.to/filecpu 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%2F4235936%2F421a9d1d-4165-4ea4-8904-ceaec42570ff.png https://dev.to/filecpu en Woody WK Mon, 09 Nov 2026 21:57:10 +0000 https://dev.to/filecpu/building-a-browser-only-pdf-toolkit-pdf-lib-web-workers-and-what-broke-5274 https://dev.to/filecpu/building-a-browser-only-pdf-toolkit-pdf-lib-web-workers-and-what-broke-5274 <p>Most "free online PDF" sites upload your file to a server. I wanted the opposite: a toolkit where the file never leaves the device. That constraint changes almost every implementation decision.</p> <h2> Why browser-only is harder than it sounds </h2> <p>PDF manipulation is CPU-heavy. Doing it on the main thread freezes the UI for seconds on a 40-page document. The fix is to push every operation into a Web Worker:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code><span class="kd">const</span> <span class="nx">worker</span> <span class="o">=</span> <span class="k">new</span> <span class="nc">Worker</span><span class="p">(</span><span class="dl">'</span><span class="s1">/assets/pdfOps.worker.js</span><span class="dl">'</span><span class="p">,</span> <span class="p">{</span> <span class="na">type</span><span class="p">:</span> <span class="dl">'</span><span class="s1">module</span><span class="dl">'</span> <span class="p">})</span> </code></pre> </div> <p>With <code>pdf-lib</code> inside the worker, merging and splitting stay responsive. The trade-off is that you can no longer touch the DOM from the parsing code, which forces a clean message-passing boundary.</p> <h2> Compression is the part nobody warns you about </h2> <p>There are two very different kinds of "compress a PDF":</p> <ol> <li> <strong>Lossless-ish</strong>: re-encode streams, drop unused objects. Text stays selectable. Savings are modest, often 10-30%.</li> <li> <strong>Rasterise</strong>: render each page to an image and rebuild the PDF. Savings can be 80%+, but you lose selectable text, links and accessibility.</li> </ol> <p>Most tools quietly do (2) and call it compression. If a document needs to stay searchable or screen-reader friendly, that is a real regression. The honest approach is to expose both and say which is which.</p> <h2> Archive handling </h2> <p>ZIP is easy (<code>JSZip</code>). RAR and 7Z are not - they need dedicated decoders, and doing it in the browser means shipping a worker bundle measured in hundreds of kilobytes. Worth it only if archive extraction is a core feature rather than a checkbox.</p> <h2> What I ended up with </h2> <p>A static single-page app: no upload endpoint, no account system, no server-side file handling. Everything runs client-side, so "we delete your file" is not a promise - there is nothing to delete.</p> <p>If you want to see the result, it is at <a href="https://filecpu.com" rel="noopener noreferrer">FileCPU</a> - free, no signup, and it covers PDFs, images and archives.</p> <p>The main lesson: <strong>when you remove the server, you inherit the performance budget.</strong> A worker-based design is not an optimisation, it is the only way the thing is usable.</p> webdev