Merging PDFs: Native Assembly Versus Flattening, and When Each Is Right

Native assembly: keep everything

Native merging copies each page object into a new document without re-rendering it. Text stays as text, vector graphics stay as mathematical paths, fonts remain embedded, and links continue to work.

• Text remains selectable, searchable and readable by screen readers.
• Vector content stays infinitely sharp at any zoom level.
• File size is roughly the sum of the inputs, often less, because shared fonts can be deduplicated.
• The operation is fast, because nothing is being redrawn.

This is the right default for contracts, reports, invoices, anything that will be searched, and anything that needs to remain accessible. Assume native unless you have a specific reason not to.

Flattening: deliberately throw the structure away

Flattening renders each page to an image and rebuilds the document from those images. What you see is preserved. Everything underneath is gone, because there is no longer anything underneath.

Flattening is the correct choice in three situations: when you need every recipient to see byte-identical rendering regardless of their software, when the document contains hidden material that must not travel, and when a form must be locked so it cannot be edited further.

The redaction trap

This is the mistake worth the whole article. Drawing a black rectangle over text in a PDF does not remove the text. It draws a rectangle on top of it. The words are still in the file, still selectable, and trivially recovered by copying the page into a text editor.

Documents have been released publicly with sensitive passages "redacted" this way more than once. Flattening genuinely fixes it, because rendering the page to an image produces a picture of a black rectangle with nothing underneath.

Metadata survives more than people expect

Beyond the visible page content, PDFs carry a document information dictionary and often an XMP metadata block. Between them these commonly record the author name, the originating application, the creation and modification timestamps, and sometimes the full local file path of the source document.

That last one has embarrassed people: a path such as C:\Users\jsmith\Clients\Acme\draft-final-v3.docx discloses a name, a client relationship and an editing history, none of which was in the visible document.

• Check the document properties before sending anything outside your organisation.
• Merging does not automatically clear metadata, and the merged file may inherit fields from whichever input was processed first.
• Flattening removes page-level structure but the new document still has its own metadata, so set or clear it deliberately.
• Attachments embedded inside a PDF survive a native merge. If an input file had a spreadsheet attached, the merged output still contains it.

Getting the order and orientation right

1. Confirm the page count of every input before merging. A missing page is far harder to spot in a 200 page output than in its 12 page source.
2. Check orientation per input. Documents scanned in batches frequently contain pages rotated 90 or 180 degrees, and the rotation is a page property that carries over.
3. Watch for duplicated cover pages and headers when combining several reports. Repeated near-identical pages make a document harder to navigate and add nothing.
4. Rebuild the bookmark structure if the document is long. Native merging usually preserves each input bookmark tree but does not create a top-level entry for each section.
5. Verify the total page count at the end. It is the quickest check that nothing was silently dropped.