Free PDF Merge Online

How It Works

1. Upload PDFs: Drop or select multiple PDF files to merge.
2. Arrange: Use up/down buttons to reorder pages. Remove unwanted files.
3. Merge: Click "Merge PDFs" to combine all files into one. Processing happens instantly in your browser.

Why Merge PDFs?

Merging PDFs is essential for organizing documents, creating reports from multiple sources, preparing submissions, or reducing file clutter. Instead of sending multiple attachments or creating complex file structures, combine everything into one easy-to-share PDF. Perfect for contracts, presentations, invoices, and documentation.

Features

• Unlimited files: Merge as many PDFs as you need.
• Reorder pages: Arrange files in any order before merging.
• Privacy: All processing happens locally in your browser. Files never uploaded to any server.
• Fast: Instant merging with no waiting or queues.

Frequently Asked Questions

Can I reorder files after uploading?

Yes. Each file shows up/down buttons to adjust order. Files are merged in the order they appear in the list.

What's the file size limit?

Each PDF can be up to 50 MB. Total merged file size depends on your browser's available memory, but typically you can merge files totaling several hundred MB.

Are my PDFs uploaded to a server?

No. All merging happens locally in your browser using pdf-lib. Your PDFs never leave your device, ensuring complete privacy and security.

Can I merge PDFs on mobile?

Yes. This tool works on desktop, tablet, and mobile browsers. Just tap to select files and merge.

What if a PDF is corrupted?

The tool will show an error for corrupted files. Try re-exporting the PDF from its source, or use an online PDF repair tool first.

A brief history of the PDF and the merge operation

Adobe announced the Portable Document Format in 1993, framing it as the digital extension of paper, a way to send a printed page from one computer to another without the receiving end having to install the same fonts, the same operating system, or the same application that produced it. The first version shipped on 15 June with Acrobat 1.0, priced at $695 for the reader and $2,500 for the distiller. Adoption was slow until Adobe made the reader free in 1994 and the US Internal Revenue Service standardised on PDF for fillable tax forms in the late 1990s, pulling the format into government workflows everywhere.

By 2008 the specification had stabilised enough for Adobe to hand it to the International Organization for Standardization, which published it as ISO 32000-1 that July. The current edition, ISO 32000-2:2020, is the standard every serious PDF tool implicitly conforms to today. Through this whole history, the merging operation has been one of the most-used PDF transformations, behind only "view" and "print" by total user count. The 2021 AIIM industry survey estimated that the average knowledge worker merges between two and five PDFs every week, with the median operation combining three to seven source files.

Merging is older than PDF itself. PostScript files were already being concatenated with shell pipes in 1989, sometimes by literally appending one file to another and renumbering the page markers by hand. PDF made the operation both easier (because the file format is random-access through a cross-reference table) and harder (because page content does not live in a single linear stream). Every modern PDF merger, from desktop Acrobat to this browser tool, is solving the same underlying problem: take several page trees and produce one combined page tree that points to the original content objects without breaking any of the indirect references that link a page to its fonts, images, and resources.

What "merging" actually does inside the file

A PDF is not a single document; it is a tree. The root is the catalog, which points to a pages tree, whose leaves are the individual page objects. Each page object holds references, not the resources themselves: the fonts the page uses live as separate indirect objects in the file body, as do the images, the form XObjects, the graphics-state dictionaries, and the patterns. The page's resources dictionary maps short names (/F1, /Im2, /GS0) to these indirect object numbers. This indirection is the reason merging is possible at all without modifying the original page content: you can build a new root pages object that points to leaves drawn from multiple source documents.

A correct merge is not a binary append. The library reads each source file's cross-reference table, parses every indirect object into memory, then for each requested page walks the resource graph to copy every transitively referenced object into the output. The copied objects get fresh object numbers in the destination's numbering space, and every reference inside them is rewritten to match. Finally a new pages tree is built whose kids point to the copied page leaves in the order you requested, and a new cross-reference table is emitted. None of the source content is decompressed, re-encoded, or rasterised. Text, images, and vector graphics from the source pages are written verbatim to the output, which is why merging is lossless and why the merged file size is essentially the sum of the inputs.

Real-world workflows that drive merging

• Contracts and legal filings. A signed contract is rarely one document. Master agreements, schedules, signature pages, and annexes all need to ship together. Court e-filing systems, the US Federal Courts' CM/ECF among them, explicitly require combined-PDF submissions for motions with exhibits.
• Expense reports and reimbursement. Concur, Expensify, and most enterprise reimbursement systems take a single PDF per claim. Workers scan or download receipts, merge them, and upload. Merging is the routine glue of every monthly expense cycle.
• Letterhead and cover sheets. Photographers, consultants, and designers maintain a one-page PDF letterhead they prepend to every deliverable. It is the cheapest way to apply consistent branding without re-rasterising artwork.
• Course materials and exam papers. Universities distribute combined PDFs of weekly readings. Exam boards combine question booklets with answer keys. Students assemble portfolios of homework. This is the highest-volume merge use case in absolute terms, with academic peak load running through late-semester deadline weeks.
• Government and immigration filings. USCIS, the UK Home Office, and most European immigration authorities require single-PDF evidence bundles. A typical naturalisation application can combine 20 to 80 individual scanned documents, each from a different source format, into one filed PDF.
• Photography and portfolio submissions. Galleries, agencies, and art-school applications routinely require a single combined PDF, often with a maximum file size. The merge step is typically followed by compression to fit the cap.

Common pitfalls and how to work around them

• Form fields go dead. The interactive-form dictionary lives at the document level, not on individual pages. Merging copies the visual artefacts of form widgets (rectangles, labels, appearance streams) but not the field definitions that make them interactive. The merged form looks right but will not accept input. Fix: flatten each form first with the PDF Flatten tool, which converts widgets to ordinary page content, then merge.
• Bookmarks disappear. The outline tree (the table of contents you see in Acrobat's side rail) is a document-level structure. There is no general algorithm for combining outlines from several source documents into one coherent outline, so most browser-only mergers, including this one, discard them. If bookmarks matter, merge first and rebuild the outline by hand in a desktop editor.
• Encrypted PDFs fail to load. A PDF with an open password cannot be parsed until the password is supplied. This tool does not support encrypted input. Workflow: use the PDF Unlock tool to remove the protection first, then merge the unlocked copies.
• Signatures break. A digital signature on a PDF is a cryptographic hash of an exact byte range of the file. Editing the file in any way, including merging it with others, invalidates the signature. The merged output is still a valid PDF, but the "Signature valid" indicator becomes "Signature invalid." This is the right cryptographic behaviour but rarely what you want. Fix: keep signed PDFs as separate files; the signed copy needs to stay intact.
• Font subsets duplicate. When the same font appears in two source documents, it is typically embedded as two slightly different subsets. The merger has no general way to detect equivalence, so the output carries both copies. The merged file is therefore slightly larger than the sum of the inputs would predict. Running the merged output through the PDF Compress tool can recover some of the bloat.

Browser-only versus cloud merging

The single biggest functional difference between this tool and the cloud PDF mergers that dominate Google's search results is where the parsing happens. Smallpdf, ILovePDF, PDF24's web app, Sejda's free tier, and Adobe's online tools all upload your source files to their servers, perform the merge there, and serve the merged file back as a download. Their privacy policies state that uploaded files are deleted within a few hours. The files nonetheless transit the operator's network, exist on their disks for the processing window, and pass through whatever logging the operator maintains for abuse detection.

This tool does not do that. Your PDF files are read into the browser tab through the standard File API, parsed in the same tab by the pdf-lib library, and written back to your disk through the standard download API. The only network traffic during a merge is the one-time CDN load of pdf-lib itself when the page first opens. You can verify it: open the browser's developer tools to the Network tab, perform a merge, and watch that no requests fire that include your file content. Anything confidential (HIPAA, GDPR, attorney-client privilege, non-disclosure obligations) is best merged in the browser. Anything larger than a few hundred megabytes, anything requiring downstream OCR, or anything that needs role-based access is better handled by a server-side tool you have explicitly chosen.

A note on accessibility

PDF accessibility is governed by ISO 14289 (PDF/UA-1) and by the W3C's PDF Techniques for WCAG 2.0. A correctly tagged PDF contains a structure tree mapping logical reading order, headings, lists, table cells, and figure alt text. Screen readers such as JAWS, NVDA, and VoiceOver use this tree to present the document in a sensible order rather than the visual order, which often runs in columns or with sidebars. The structure tree is a document-level object, so merging two tagged PDFs in this tool produces an untagged output. For private archives and reimbursement bundles this is fine. For documents intended for public use by readers with visual impairments, you will want to remediate the merged output through Adobe Acrobat's "Make Accessible" action wizard, or start from already-flat scanned PDFs with no accessibility metadata to lose.

More frequently asked questions

Can I merge more than 50 MB of PDFs in one go?

Each file can be up to 50 MB, and the practical limit on total merged size is roughly 300 MB on desktop browsers and 100 MB on mobile. Both numbers are consequences of browser memory rather than the PDF format itself. ISO 32000-2 allows files up to 2^64 bytes, so PDF is not the constraint. The constraint is the JavaScript heap, which most browsers cap at 2 to 4 GB per tab. If your combined input is near or above those numbers, a desktop tool such as Adobe Acrobat or Apple Preview will handle it more reliably.

Why is my merged file slightly bigger than the sum of the inputs?

Most of the time the merged file is essentially the sum, give or take a few percent. The overhead comes from duplicated font subsets (the same font embedded by two source documents shows up twice in the output), duplicated image resources that the merger could not detect as equivalent, and the new cross-reference table covering the combined object count. Running the merged output through the PDF Compress tool can usually recover most of that overhead.

Can I merge PDFs of different page sizes?

Yes. Each page in a PDF carries its own media box, the rectangle that defines its visible area. A merged PDF can contain any mix of sizes (A4, US Letter, A3, custom dimensions) and most readers will display each one at its native size. The merged file itself does not pick a "winning" size. If you need every page in the output to be the same size, that is a separate operation (resizing), which the merger does not perform.

Will merging strip my metadata?

The document info dictionary (title, author, subject, keywords, producer) is taken from the first source document. Any metadata in subsequent sources is discarded. The XMP metadata stream, where modern PDFs store the richer structured-metadata block, is rebuilt from scratch by pdf-lib. If preserving specific metadata across the merge matters, set it intentionally in the first source document, or use a desktop editor to apply it after merging.

Does the order I drop files in matter?

Yes. Files are merged in the order they appear in the list. You can reorder them with the up and down buttons on each file row before clicking "Merge PDFs." The first file becomes the first pages of the output, the second file follows, and so on. The metadata is also pulled from the first file, so put the document whose title and author you want to keep at the top.

Related Tools