A PDF file is really a container: a cross-reference table pointing to a tree of page objects, fonts, and image streams. Merging two PDFs, done correctly, means splicing those object trees together and rebuilding a single cross-reference table — not re-rendering pages as images and stitching them back into a new document. That distinction is why a proper merge is lossless in the sense that matters most: your original vector text, embedded fonts, and image resolution pass through untouched, rather than being rasterized into flat images.
What actually happens when you merge
- Each source file is parsed into its object graph (pages, content streams, fonts, embedded resources).
- Every page is copied into the new document (not embedded as a flattened image), which is what keeps text selectable and fonts intact.
- If a page's size doesn't match the target page size (see below), its content is uniformly scaled to fit — never stretched or distorted.
- The result is serialized back into a single PDF — done entirely in your browser's memory via
pdf-libcompiled to WebAssembly, so the file never has to leave your device to be processed.
Page sizes are normalized, not left mismatched
If your source files have different page sizes — a mix of A4 and US Letter documents, or scans done at different DPI — this tool scales every page towards the size of the first page of the first file, so the merged document doesn't end up with a visibly huge page followed by a visibly tiny one. Scaling is always uniform (the same factor on both axes, never a stretch), so nothing gets distorted. Because a page that doesn't share the target's exact aspect ratio can only be made to match on one axis while staying proportional, its other dimension will land close to — but not always pixel-identical to — the target; in practice this means mixed A4/Letter batches come out looking consistent rather than mismatched.
Where merging gets tricky
A few edge cases are worth knowing about before you rely on the output:
- Interactive form fields don't currently survive a merge. If a source PDF has fillable AcroForm fields (text boxes, checkboxes), those fields are not carried over into the merged document today — the page's visual content is preserved, but the field data structure is not. If you need a source PDF's fillable fields to remain fillable, don't merge it; keep it as a separate file.
- Plain link and comment annotations are preserved, since page copying (rather than flattening to an image) keeps most page-level annotations intact — but bookmarks (the document outline tree) are not currently carried over from any source file into the merged document.
When you shouldn't merge first
If any source file is password-protected, unlock it before merging — encrypted PDFs can't be parsed at the object level without the password, which is what merging requires. Use Unlock PDF first, then merge. And if your goal is a smaller final file rather than just combining them, run each large scanned document through Compress PDF individually before merging — compressing after merging gives you less control over which specific document is bloating the result.
Common uses
- Combining case exhibits, affidavits, and evidence into a single legal bundle
- Consolidating a year of monthly invoices or bank statements into one report
- Assembling a resume, cover letter, and portfolio into a single file for a hiring manager
- Joining scanned chapters of a paper document after digitizing them separately
FAQ
Is there a limit on how many PDFs I can merge?
No — there's no cap on how many files you can select at once, on Free or Premium. The only real limit is per-file size: 100MB on Free, 500MB on Premium.
Does merging preserve searchable text?
Yes — since the underlying text objects are copied rather than rasterized, any text that was selectable/searchable in the source PDFs stays that way in the merged file.
Can I merge images alongside PDFs?
Yes. Drop JPG, PNG, or WebP files into the same batch and they're converted to PDF pages automatically before merging.
Does the tool reorder or renumber page labels?
Physical page order follows what you set in the merge queue, but custom page labels (like "i, ii, iii" for a preface) from the source documents aren't currently preserved — the merged file uses plain sequential numbering.
Why did an older merged file have inconsistent page sizes?
If you merged files before this behavior was added, pages kept each source document's original size verbatim, so combining an A4 file with a US Letter file produced a document where the pages were visibly different sizes. This is now fixed: page sizes are normalized as described above.