Home/ Blog/ Why This Site Uses pdf-lib, pdf.js, and qpdf-wasm (and What Each One Actually Does)
Architecture June 30, 2026 2 MIN READ

WHY THIS SITE USES PDF-LIB, PDF.JS, AND QPDF-WASM (AND WHAT EACH ONE ACTUALLY DOES)

Three different open-source libraries do almost all of the real work behind these 31 tools, and they are not interchangeable — each one solves a distinct problem the others genuinely cannot.

A reasonable question to ask about any tool site is what is actually doing the work underneath the interface, and on minipdftoosz the honest answer is a small set of mature, open-source libraries that each handle a distinct, non-overlapping part of what "PDF processing" means. None of them are interchangeable with each other, and understanding what each one is actually for explains a lot about why the site is organized the way it is.

pdf-lib handles PDF structure and manipulation: creating new PDFs, merging, splitting, deleting or reordering pages, adding text, watermarks, page numbers, and images onto existing pages, and reading and filling AcroForm fields. Its job is manipulating a PDF's internal object graph — the pages, fonts, and content streams that make up the document — and writing that graph back out as a valid PDF file. It does not render pages visually; it works with the PDF's data model directly, which is exactly the layer most of the editing-category tools on this site operate on.

pdf.js, originally built by Mozilla and now widely used across the web, handles the opposite problem: rendering a PDF page visually, as pixels, the way a PDF viewer does. When a tool needs to show you a live preview of your pages, let you visually pick which pages to keep or delete, or convert a page into an image format like JPG, PNG, or WebP, that rendering step is pdf.js drawing the page onto an HTML canvas element. It is also what powers the PDF to Text tool's ability to extract a page's actual text content, since parsing text positions correctly during rendering is core to what pdf.js already needs to do.

qpdf, compiled to WebAssembly as qpdf-wasm, handles one specific, security-sensitive job that neither of the other two libraries is built for: correct, standards-compliant PDF encryption and decryption. Password protection in the PDF specification is genuinely intricate — different encryption revisions, key derivation schemes, and permission-flag encodings that have to be implemented exactly right or the resulting file will not open correctly in other PDF viewers. qpdf is a mature, long-maintained C++ library that has handled this correctly for years in server and desktop contexts; compiling it to WebAssembly lets that same battle-tested encryption logic run directly inside a browser tab instead of requiring a rewrite in JavaScript, which would have meant re-implementing delicate cryptographic-adjacent code from scratch and trusting it with people's passwords on day one.

A few smaller, single-purpose libraries round out the rest: JSZip bundles multiple output files together into a single zip download for tools like Split Pages that produce many files at once; signature_pad captures smooth handwritten strokes for Add Signature; markdown-it parses Markdown syntax into HTML for the Markdown to PDF tool; and html2canvas rasterizes rendered HTML into an image for both HTML to PDF and Markdown to PDF, as covered in an earlier post on this blog.

The throughline across all of these choices is the same: rather than writing new, unproven code for problems that already have mature, well-tested open-source solutions, this site leans on the specific library that has already solved each distinct sub-problem correctly, and confines the actual custom code here to the interface layer and the logic that ties these libraries together into 31 coherent, single-purpose tools.

END OF ARTICLE · BY MINITOOLSZZ
← MORE ARTICLES