File-Level PDF Merging
This section explains the internal process of combining multiple PDF files using pdf-lib. Multiple PDF files selected by the user are loaded into browser memory via File.prototype.arrayBuffer(), where PDFDocument.load parses each file into an independent PDF document object.
Next, a new empty PDF container document is initialized using PDFDocument.create(), and copyPages is invoked sequentially across the uploaded files in their listed order.
This merge functionality operates as a file-level concatenation. The user interface allows reordering files via Up/Down buttons or removing files from the queue, but it does not support page-level reordering within files, page rotation, or drag-and-drop thumbnail editing.
Pages extracted from each document in page order are appended to the new document instance using addPage, and pdf-lib reconstructs resource dictionaries and object trees to assemble a unified downloadable byte array.
Page Extraction and Splitting Behavior
The page extraction (split) feature extracts specified pages from a large multi-page document into a single new PDF. A key functional characteristic is that this extraction workflow is limited to gathering specified pages from a single source PDF in designated order (allowing duplicates) into one output file.
Unlike specialized desktop utilities that burst a document into dozens of individual single-page files or segment ranges into multiple separate PDFs, this implementation outputs only one unified document.
The application reads the single source PDF into memory, invokes copyPages based on parsed zero-indexed page numbers, and copies the targeted pages into a newly created PDFDocument.
This process is non-destructive to the original document, omitting thumbnail generation, and does not provide dedicated PDF compression features, while advanced structures such as bookmarks or forms may not be preserved.
Range Notation Parsing Algorithm
The extraction UI accepts string notation such as '1-3, 5' and parses it with a dedicated range-parsing algorithm. The input string is split by commas, and each resulting segment is evaluated.
If a segment contains a hyphen, it is treated as a range, parsing the start and end values into integer page numbers. Strict validation checks confirm that inputs are valid positive numbers, starting pages are 1 or greater, ending pages do not exceed total document page count, and start values do not exceed end values.
Valid page numbers are converted to zero-based indices and appended sequentially to the extraction queue. Individual page numbers without hyphens undergo identical boundary checks.
Duplicate numbers result in duplicate extracted pages in the output document. If invalid syntax, non-numeric characters, reversed ranges, or out-of-bound pages are detected, processing halts with an exception and returns immediate user feedback in the UI status panel.
Client-Side Processing and URL Lifecycle
To eliminate server transmission, all file operations occur entirely within local browser memory. Selected PDF files are handled as File objects and converted to ArrayBuffer data in client memory.
No document binary data is transmitted or uploaded across the network to cloud servers, distinguishing local document manipulation from site network communication, though client processing does not guarantee host operating system security.
Once generated, the output document binary is obtained as a Uint8Array and wrapped in a Blob with MIME type application/pdf. A dynamic download URL is generated via URL.createObjectURL(), triggering an anchor click event to initiate browser downloading.
Temporary Blob URLs are released via URL.revokeObjectURL() inside setTimeout(..., 0) immediately after download initiation. Whether a save dialog appears or the file saves automatically depends on user browser settings.
Memory Considerations for Large Files
Because this client-side architecture operates without server-side batch workers, performance and stability depend directly on device hardware (especially physical RAM) and browser heap limitations.
While the tool sets no artificial file size or page count limits, it processes documents by reading each file into memory and building the new document in memory.
Handling multi-hundred-megabyte files or documents with numerous high-resolution images can rapidly approach browser JavaScript heap thresholds.
If heap memory is exhausted, an Out of Memory error occurs, crashing the tab or freezing the interface. The tool lacks streaming mechanisms to segment large binary streams or guarantee bounded memory usage under extreme workloads.
When processing dozens of large PDFs or extensive page extractions, users should ensure adequate free memory or divide files into manageable subsets before processing.
Unsupported PDF Features and Structural Limitations
Because pdf-lib performs page-copy operations to construct a new document, retention of advanced PDF structures from source files is not guaranteed.
The core process extracts content streams and associated direct resources (fonts, images, vector drawing commands) for the designated pages and rebuilds them in a newly generated document.
Document-level metadata (authors, creation dates, keywords), outline bookmarks, interactive form fields, submitted form data, embedded file attachments, and cryptographic digital signatures are not reliably inherited and are frequently omitted.
Consequently, this tool is unsuitable for strict legal or enterprise workflows requiring digital signature integrity. Furthermore, password-protected or encrypted PDFs cannot be autonomously decrypted.
While loading with ignoreEncryption: true bypasses encryption checks to read page counts in some files, this does not guarantee page count retrieval for all encrypted documents, and subsequent processing via PDFDocument.load will throw an error and abort if the file remains encrypted.
Password protection must be removed prior to processing.