{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

{{ badge.label }}{{ badge.value }}
{{ summaryAnnouncement }}
PDF sources and merge order
{{ dropzoneTitle }}
Drop PDFs here or press Enter to browse. Files never leave this browser session.
{{ dropzoneMeta }}
  • {{ message }}
Merge order:
OrderSource PDFPagesSizeReorder
{{ index + 1 }}{{ entry.name }}{{ entry.page_count }}{{ formatBytes(entry.size_bytes) }}
The current download will be named {{ outputName }}.
{{ actionHint }}
This changes document information, not page content or order.
Allowed range: 2-50 PDFs. Default: 20.
files
Total accepted source bytes for one local merge. Default: 120 MiB.
MiB
{{ pdfDownloadAnnouncement }}
Merged PDF
{{ hasOutput ? outputFilename : outputName }}
{{ mergedArtifactNote }}
{{ hasOutput ? `Run ${mergeRevision}` : 'Not generated' }}
{{ hasOutput ? `${outputPageCount} pages · ${formatBytes(outputSize)}` : 'Merge output will appear here' }}
{{ chartExportStatus }}
Merge Summary

Load PDFs to chart how pages are distributed across the final merge order.

{{ ledgerExportStatus }}
OrderSource PDFPagesSizeQueue roleCopy
No accepted PDF sources yet.
{{ row.order }}{{ row.name }}{{ row.pages }}{{ row.size }}{{ row.role }}
Readiness Checks
{{ row.label }}

{{ row.detail }}

{{ row.status }}

A merged PDF is one document whose pages come from several source files in a deliberate order. It is useful for contracts with schedules, reports with appendices, applications with supporting evidence, and scanned packets assembled by more than one person. The final reading sequence follows the source queue from top to bottom and preserves the page order inside each source.

Good merging begins with inventory rather than the merge button. The source count catches a missing attachment, the summed page count provides a quick completeness check, and the visible filenames make the intended order reviewable. A technically successful merge can still be wrong when a cover sheet is last, an appendix is duplicated, or an unreadable file was skipped before the output was created.

  • Use merging when every accepted page belongs in one continuous reading order.
  • Use page extraction or deletion when only part of a source belongs in the result.
  • Use compression when the main problem is file size rather than document order.
  • Use redaction before merging when confidential content must be permanently removed.

Page copying does not guarantee that every document-level feature survives. Bookmarks, portfolios, digital signatures, scripts, attachments, interactive forms, and accessibility structure can depend on objects outside ordinary page content. Open the combined file in the reader used by its audience, confirm the page total and order, and test any feature that matters to the handoff.

How to Use This Tool:

Build the queue in the same order that someone should read the finished document.

  1. Add two or more files with PDF files. A file is accepted only after its PDF header and readable page count are found.
  2. Move sources up or down until the queue matches the intended page sequence. Remove duplicates and review any skipped-file warning.
  3. Choose an Output filename and Output metadata. The metadata choice changes the new document title, not its pages or order.
  4. Check the File guard and Browser work limit. Reduce the queue or raise a guard within its allowed range when the readiness check blocks the merge.
  5. Select Merge PDFs. Confirm that the merged page count equals the accepted source-page total, then download and open the result for a visual review.

Interpreting Results:

Queue ready to merge means there are at least two accepted PDFs and both configured guards pass. Merged document ready means a new PDF was created and its page count matched the source-page sum.

That count proves page allocation, not visual or semantic correctness. Inspect the first and last page of every source boundary, confirm forms and links that matter, and treat any skipped source as an incomplete packet until its absence is intentional.

Technical Details:

PDF merging creates a new document, loads each accepted source in queue order, copies all page indices from that source, and appends those copied pages to the output. The output is serialized only after every source has been processed and the copied-page count agrees with the readiness model.

Formula Core

The two main inventory values are simple sums across the accepted sources.

Ptotal=i=1nPi Btotal=i=1nBi

Here, n is the accepted source count, P is a page count, and B is a byte count. No rounding is applied. A merge is ready only when n is at least 2, n is no greater than the file guard, and the total bytes are no greater than the browser work limit.

Transformation Core

The ordered transformation is:

  1. Identify candidate files as PDFs and read their bytes.
  2. Require a PDF header, parse the document, and reject sources with no readable pages.
  3. Record each accepted filename, byte size, page count, and queue position.
  4. Create a blank output and copy every source page in queue order.
  5. Write a new title and producer record, serialize the PDF, and compare its page count with the expected total.
PDF merge limits and boundary rules
RuleAllowed rangeBoundary behavior
Accepted sourcesAt least 2One accepted PDF cannot be merged by itself.
File guard2 to 50 PDFsThe queue passes when source count is less than or equal to the selected guard.
Browser work limit10 to 300 MiBThe queue passes when accepted source bytes are less than or equal to the selected limit.
Output titleNeutral or first filenameNeutral writes “Merged PDF”; first-file mode uses a sanitized first-source basename.

The browser work limit measures accepted source bytes, not peak memory and not final output size. Parsing and rewriting can require additional memory, so a queue below the guard may still be too large for a low-memory browser or device.

Privacy and Limitations:

Source and output PDF bytes remain in the current browser session; there is no tool-specific upload for the merge. The PDF processing code must load before local work can begin, so an unavailable network resource can prevent the engine from starting even though the documents themselves are not transmitted.

  • Encrypted or malformed PDFs may be rejected during parsing.
  • The operation copies pages into a new PDF and does not promise preservation of every document-level feature.
  • The output is not a redaction, signature-preservation, archival-conformance, or accessibility-validation workflow.