Merging PDFs: What Actually Changes in the File, and Who Gets to See It

Most people merging PDFs are combining documents they would not hand to a stranger: six months of bank statements for a housing loan, payslips and an EA form for a tax query, a passport scan and utility bill for a bank's KYC pack. Two questions matter and almost no merge tool answers either. Where does the file actually go when you click Merge, and what does the merged copy quietly lose compared with the originals? Both have concrete, checkable answers.

Uploaded or in-browser: the difference is not marketing

A server-side merge tool sends your document over the network to a machine you do not control, writes it to disk there, processes it, and holds the output long enough for you to download it. Even an operator acting in complete good faith now has your file in request logs, on a temporary volume, and often in a CDN cache. Their retention promise — 'deleted after one hour' — is a policy, not a technical property, and you cannot verify it.

A browser-side tool loads the PDF bytes into the page's own memory with the File API, rewrites them using JavaScript running on your machine, and hands the result back through a blob download. The bytes never cross the network. That is not a stronger promise; it is a different architecture, and the difference is that you can check it yourself.

The check takes ten seconds. Load the tool page, then disconnect from the internet — turn off Wi-Fi or flip on airplane mode — and merge your files. If the merge completes offline, nothing was uploaded, because there was nothing to upload to. If it hangs or errors, your documents were going somewhere. You can also open your browser's developer tools, switch to the Network tab, and watch whether a request carrying megabytes of your file leaves the page when you click Merge.

This tool is the browser kind: the merge runs on pdf-lib loaded into the page, and the offline test above passes.

What survives a merge and what does not

A PDF is not a flat stream of pages. It is an object graph with a page tree plus several document-level structures that sit beside the pages rather than inside them. A merge copies the page tree. Anything living at document level in the source files has no obvious home in the new document, and standard merge implementations — including the one here — do not carry it across.

ElementSurvives a merge?Why
Page content, text, vector artYesLives inside each page object and is copied with it.
Embedded images and fontsYesCopied as page resources, per page.
Link and comment annotationsUsuallyAttached to the page; internal links to pages in a different source file break.
Bookmarks / outlineNoA document-level outline tree with no equivalent in the merged file.
Fillable form fields (AcroForm)Often brokenField widgets are copied, the document-level field catalogue is not, so fields lose their values or stop responding.
Digital signaturesNo — invalidatedA signature covers an exact byte range; a merge rewrites every byte.
Password / encryptionNoEncrypted files usually cannot be opened by the merge tool at all.
Document metadata (title, author)NoThe merged file starts with fresh, mostly empty metadata.
File attachments embedded in the PDFNoStored in a document-level names tree.
Tagged-PDF accessibility structureNoThe structure tree is document-level; screen-reader order degrades.

Why digital signatures always break

This is the one that causes real problems, because the merged file looks perfect while quietly failing validation. A PDF signature stores a cryptographic hash over a declared byte range of the file. Any change to any byte — including simply rewriting the same visual content with different object numbering, which is exactly what a merge does — makes the recomputed hash differ from the signed one. The reader then shows the signature as invalid or 'document has been altered'.

In practice: if you merge a digitally signed e-invoice, a signed bank statement, or a signed letter into a combined pack, the signature on the merged copy is worthless as proof. The visible signature image may still be there, which is precisely what makes this a trap.

The fix is procedural, not technical. Where a recipient needs to verify a signature — LHDN, a bank's credit team, a lawyer — send the signed PDF as its own untouched file and merge only the unsigned supporting documents. If they just want a readable pack, merge away; nobody is verifying the cryptography on a photocopied utility bill.

Encrypted and password-protected files

Malaysian banks and insurers routinely email statements encrypted with your IC number or date of birth as the password. Being able to open one in a reader is not the same as the file being decrypted — the encryption stays in the file, and a merge tool will typically refuse to load it and report an error.

Remove the protection first rather than fighting the tool. Open the PDF in a reader, enter the password, then print to PDF or export a copy without a password; that copy merges normally. Note what you have just done: the unprotected copy of your bank statement is now sitting in your Downloads folder with no password on it. Delete it once the merged pack is sent.

Why the merged file is bigger than you expected

Merging three 2 MB PDFs gives you roughly a 6 MB file, not something smaller, and occasionally slightly more. A merge concatenates page objects and their resources; it does not look across source documents for duplicate content. If the same logo image and the same embedded font subset appear in all three files, all three copies are carried into the output.

That matters because upload limits are real and low. Many Malaysian portals and bank submission forms cap attachments at 2 MB to 10 MB per file. If the merged pack is over the limit, compressing afterwards usually beats merging fewer documents — and the biggest single win is almost always the scans. A page photographed at full phone resolution can be 3 MB by itself; rescanning at 200–300 dpi in greyscale brings a text document down by an order of magnitude with no loss of legibility.

Getting the order right the first time

  • Page order follows the order you add the files, not their filenames — adding a 'page 3' file first puts it first.
  • If a file must land in the middle, add the files in three steps rather than reordering afterwards.
  • Name source files with zero-padded numbers (01, 02, … 10) before selecting them in bulk, or your file picker will sort 10 before 2.
  • Check the first and last page of the output, plus one page either side of each join — that is where a wrong-order mistake shows up.
  • To combine only part of a document, extract the pages you want first and merge the extracts; splitting then merging is cleaner than merging then deleting pages.

Important caveats

The behaviour described here is standard for page-copy merging and matches the tool on this page; other merge implementations differ in detail, and a few paid desktop applications do explicitly rebuild bookmarks and form catalogues. If bookmarks or working form fields must survive, test with a copy before committing to a workflow.

Browser-based processing protects the file in transit. It does not protect you from everything else — a shared or public computer keeps the merged output in the Downloads folder, and a device with malware on it is compromised regardless of where the merge ran. For genuinely sensitive documents, work on your own device and clear the downloads afterwards.

Nothing here is legal or compliance advice. If a document is being submitted as evidence or as a signed instrument, confirm the required format with the receiving party before altering the file in any way.

Open the Merge PDF →

Last reviewed: 2026-11-03