When you drag three separate PDFs onto minipdftoosz's Merge PDF tool and a single combined file appears in your downloads folder a second later, it can feel like magic, or at least like something happened on a server somewhere. It did not. Every step of that merge happened inside the browser tab you were already looking at, using a JavaScript library called pdf-lib, and understanding roughly what pdf-lib is doing under the hood makes the whole "no uploads" claim a lot less mysterious and a lot more concrete.
The first thing that happens when you select files is not an upload — it is a local read. The browser's File API hands your JavaScript code a reference to the bytes sitting on your disk, and the tool reads those bytes into memory using a FileReader or the newer File.arrayBuffer() method. At no point in this step does a network request fire. If you opened your browser's developer tools and watched the Network tab while merging files, you would see it stay essentially empty — no POST request carrying your PDF anywhere, because there is nowhere for it to go and no code written to send it.
Once the bytes are in memory, pdf-lib parses each PDF's internal structure. A PDF file is not really one flat document; it is a small database of objects — pages, fonts, images, an outline tree for bookmarks — cross-referenced by an index at the end of the file. Merging is the process of loading each source PDF's object graph, copying the relevant page objects (and everything they depend on, like embedded fonts and images) into a new, empty PDF document object, and then re-writing a fresh cross-reference index that ties it all together as one coherent file. This is genuinely more delicate than concatenating text files; a naive byte-level concatenation of two PDFs would just produce a broken file, because each PDF's internal object numbering and cross-reference table only makes sense on its own.
Because merging happens client-side, nothing about page count, page size, or content is ever visible to anyone but you. There is no page limit enforced by the tool itself — only your device's available memory, which on a typical modern laptop comfortably handles merges well into the hundreds of megabytes. Bookmarks (the PDF outline structure) attached to each source file are preserved where the underlying viewer supports it, so a merged file built from bookmarked chapters still lets a reader jump around by section afterward.
The output step mirrors the input step in reverse: pdf-lib serializes the new combined document back into raw bytes, and the browser wraps those bytes in a Blob object with a PDF MIME type. A temporary object URL is created pointing at that Blob, and a hidden anchor tag with a download attribute is programmatically clicked to trigger your browser's normal "Save File" behavior. The Blob and its object URL are released from memory shortly after, and the merged PDF that lands on your disk was never anywhere except your own machine from start to finish.
This same fundamental pattern — read bytes locally, manipulate the PDF object graph with pdf-lib, serialize back to bytes, hand off through a Blob download — underlies most of the editing tools on this site: Split, Delete Pages, Reorder Pages, and Rotate all follow essentially this same read-manipulate-write loop, just with a different manipulation step in the middle. Once you've seen how one of them works, the others stop feeling like separate magic tricks and start looking like variations on the same honest, boring, entirely local mechanism.