How We Built a 12-Tool PDF Suite That Runs Entirely in Your Browser
No upload server, no WebAssembly build, no file ever leaving the device. Here's the stack behind it, how the twelve tools split into four categories, and the limits we chose to ship honestly instead of quietly working around.
· 6 min read · part 2 of a series on the PDF suite
The goal: a full PDF toolkit that never uploads
The brief going in was narrow on purpose: build the tools people actually reach for — split, merge, compress, convert — and don't send the file anywhere to do it. That second part wasn't a privacy slogan bolted on afterward; it was the constraint that shaped every other decision, starting with which libraries were even eligible to use.
A server-based PDF tool can lean on whatever's easiest on the backend — a mature native library, a command-line converter, anything. Rule that out, and the question becomes different: what can a browser tab actually do to a PDF, a Word file, or a spreadsheet, using nothing but JavaScript that ships with the page? The answer turned out to be "most of it" — but which twelve tools made the cut, and which one didn't, came directly out of what that stack could do well.
The client-side stack
Every tool in the suite is built from five pure-JavaScript libraries — no WebAssembly anywhere. Each one owns a different slice of the problem:
- pdf-lib handles page-level operations — splitting a document apart, merging several into one, reordering or deleting pages, and rebuilding a PDF from new page content.
- pdf.js reads an existing PDF back out: rendering its pages to a canvas (for image conversions and for rasterizing) and extracting the underlying text.
- jsPDF, with the jspdf-autotable plugin, builds new PDFs from scratch — turning plain text or tabular data into laid-out pages.
- SheetJS (xlsx) reads .xlsx workbook data so a spreadsheet's rows and columns can be handed to jsPDF's table layout.
- JSZip builds .docx files by hand — a Word document is a zip archive of XML files under the hood — and zips up any tool's output that comes back as multiple files.
None of these need a build step beyond bundling; they run as regular JavaScript in the page. That's the whole toolkit — no native code, no compiled binary, no Wasm module to fetch before the tool is usable.
Four categories, twelve tools
The full PDF Tools suite groups into four categories, and the grouping maps pretty directly onto which library is doing the heavy lifting.
Edit covers Split, Merge, and Organize Pages — pure page-shuffling, all pdf-lib. Improve covers Compress and Flatten, where pdf.js renders and pdf-lib rebuilds. Convert to PDF takes Image, Word, TXT, and Excel files and turns them into PDFs with jsPDF (and SheetJS for the Excel path). Convert from PDF goes the other way — PDF to JPG/PNG and PDF to Text lean on pdf.js's rendering and extraction, and PDF to Word combines pdf.js's text extraction with JSZip to assemble a .docx.
Twelve tools, one set of libraries reused across all of them — including Compress, which is where the honest limits start showing up.
The limits we shipped honestly
Working entirely client-side means some things are genuinely harder than they'd be with a native library on a server. Rather than fake a capability or quietly ship a broken one, each real limit got surfaced as a warning in the tool itself.
Compress gets its size reduction by rasterizing pages — rendering each one to an image and rebuilding the PDF from those images. That's the right move for a scanned or image-heavy file, but it flattens any selectable text into the picture, so an already-small, mostly-text PDF may not shrink at all, or can even grow. PDF to Word extracts text with pdf.js and reassembles it into a .docx, but it's text-only — the original layout, columns, and positioning aren't preserved, because recovering exact layout from a PDF client-side isn't reliable. And scanned PDFs have no underlying text layer at all — there's no OCR step in this suite, so text extraction and PDF-to-Word only work on PDFs that already have real text in them, not a scanned image of a page.
PDF to Excel didn't make the cut at all. Recovering structured rows and columns from a PDF's page-position data is unreliable enough client-side that it was dropped rather than shipped half-working — the suite covers the more tractable direction, Excel to PDF, instead.
FAQ
Can PDF tools really run without a server?
Yes, for a large share of what people actually do to a PDF — split it, merge it, reorder pages, compress it, convert it to or from a handful of common formats. The browser can already parse a PDF’s byte structure, render its pages to a canvas, and write new bytes back out. None of that requires sending the file anywhere; it only requires a JavaScript library that knows the PDF (and .docx, and .xlsx) file formats well enough to do the work locally.
Why no WebAssembly?
It wasn’t needed. WebAssembly earns its keep when you’re porting an existing native library (a C/C++ PDF or OCR engine, say) into the browser at near-native speed. This suite went the other direction: pure-JS libraries — pdf-lib, pdf.js, jsPDF, SheetJS, JSZip — already cover page operations, rendering, text extraction, and archive building. Reaching for Wasm on top of that would have added a build step and a download without solving a problem the JS libraries didn’t already solve.
Why does compressing a PDF remove selectable text?
Because of how the compressor gets its size reduction. It rasterizes each page — renders it to an image with pdf.js and rebuilds the PDF from those images with pdf-lib — which is what actually shrinks a scanned or image-heavy file. The tradeoff is that any real text on the page becomes part of the picture, not text anymore, so it’s no longer selectable or searchable. That’s a genuine limit of the rasterize approach, and it’s why the tool warns about it instead of hiding it: it’s the right call for scanned pages, and the wrong call for an already-small, mostly-text PDF.
Why isn’t there a PDF-to-Excel tool?
It didn’t make the cut. Going from a PDF back into structured spreadsheet rows and columns means recovering a table layout from a format that only really stores where each character sits on a page — there’s no reliable client-side way to do that well across arbitrary PDFs. Rather than ship a converter that produces garbled sheets some of the time, the tool was left out. The suite covers the more tractable direction instead: Excel to PDF.
Try the Suite the Stack Was Built For
Twelve tools, one page, nothing uploaded — split, merge, compress, or convert a PDF right in this tab.