# Combine Searchable PDFs Without Losing the Text Layer

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2024-10-01T11:47:40Z
- Updated: 2026-10-11T19:22:20Z
- Category: Searchable PDFs
- Canonical: https://www.schemalaw.com/blog/combine-searchable-pdfs

> Combine searchable PDFs with a merge command and each page keeps its text layer. How to handle mixed files, OCR order, bookmarks, page order and seam tests.

When you combine searchable PDFs with the merge command in a PDF editor, the result stays searchable, because every page carries its own text into the new file. The combined file is only as searchable as its parts, though, so a scan that had no text layer stays silent until you run OCR on it.

That answer covers the simple case. The rest of this guide is about the cases that go wrong without telling you: a mixed set, a merge in the wrong order, navigation that vanished, and a page lost at a join.

Once the files are joined, search the result for an exhibit label, a pleading caption, and a deposition page heading. Search for an order and for an affidavit as well, and note the page of each hit. Read that line on the picture where one source meets the next. A hit inside the wrong document means a part went in out of sequence or brought no text with it.

## Do combined PDFs stay searchable?

Yes. A merge copies whole pages from each source into one file, and a page's hidden text travels with its picture. Nothing is recognized again and nothing is redrawn, provided you use a merge, combine or insert-pages command and not a route that prints the files into a new PDF.

A searchable page is a self-contained unit: a picture, the text behind it, and the font that text is written in. Merging is bookkeeping. The editor builds a new file whose page list points at pages taken from the sources, in the order you chose. It has no reason to open a page and change what is on it.

The routes that do change pages are the ones that are not merges at all.

| How the files were joined | What happens to each page | Text kept? |
| --- | --- | --- |
| Merge, combine or insert pages in a PDF editor | Copied whole | Yes |
| Dragging page thumbnails from one open file into another | Copied whole | Yes |
| Selecting several files and printing them to one PDF | Drawn again by a print driver | Depends on the driver; test |
| Converting every page to an image, then building a PDF from the images | Replaced by a picture | No |
| Bundling the files into a portfolio or package | Each file stays separate inside a wrapper | Yes inside each file, but a search may not look inside |

The last row is the one to watch. A portfolio looks like one file in a folder and behaves like several when you search it. The post on diagnosing an unsearchable PDF explains [portfolios and attached files that a search passes over](https://www.schemalaw.com/blog/how-to-make-a-pdf-searchable#pdf-portfolios-and-attached-files-that-a-search-passes-over).

If what you hold is loose page images and not PDFs, the task is a different one, covered in the section on [combining scanned image files into a single PDF](https://www.schemalaw.com/blog/scanned-images-to-pdf#combining-scanned-image-files-into-a-single-pdf).

One limit applies before any merge. A source file that its author protected against changes may refuse to give up its pages. Ask the sender for a copy you are permitted to assemble.

## Combining searchable and unsearchable PDFs into one file

A merge of searchable and unsearchable PDFs gives you a file that is searchable in patches. The pages from the scanned source stay pictures, and nothing in the combined file marks where they are. A search then returns hits from some documents and silence from others, which reads like a clean result.

This is the most dangerous outcome of a merge, because the file passes a quick test. Open it, search a party's name, see forty hits, and the file appears searchable. The forty hits all came from the typed pleadings at the front. The scanned bank statements at the back contributed none, and no message says so.

Suppose you assemble a closing set for a sale from the fictional seller Brennan Holdings to Okafor Properties. Five source files go in:

| Order | Source file | Pages in combined file | Text layer before merging? |
| --- | --- | --- | --- |
| 1 | Purchase agreement, saved from Word | 1 to 34 | Yes, typed |
| 2 | Signed deed, scanned at the title office | 35 to 38 | No |
| 3 | Title commitment, downloaded from the insurer | 39 to 61 | Yes, typed |
| 4 | Survey, scanned | 62 to 63 | No |
| 5 | Settlement statement, scanned and run through OCR | 64 to 69 | Yes, recognized |

Six of the 69 pages cannot be searched, and they include the deed. A search of the combined file for the grantor's name misses the one page where it matters most.

Build that table before you merge. It costs one search per source file, and it becomes the map you test against afterwards. To spot the gaps in a file somebody else combined, where you have no list of sources, search for a very common word such as "the" and step through the hits. A run of pages with no hit at all is a scanned insert. The fuller method is in the post on [checking that a PDF is searchable on every page](https://www.schemalaw.com/blog/how-to-check-if-a-pdf-is-searchable).

The repair is to run OCR on the unsearchable sources and merge again from the corrected parts.

## Should you run OCR before or after combining the files?

Run OCR before combining when the sources are of different kinds, and after combining when every source is a plain scan with no text at all. OCR first lets you leave typed files untouched and check each result alone. OCR afterwards is one job, but it puts every page through recognition, typed ones included.

| Consideration | OCR each file, then combine | Combine, then OCR once |
| --- | --- | --- |
| Typed sources | Left alone, text stays exact | Exposed to recognition unless the tool skips pages with text |
| Sources that already have a good recognized layer | Left alone | May gain a second layer or lose the first |
| Finding a bad result | You know which file it came from | You have to trace the page back to its source |
| Size and page limits of the OCR tool | Each file is small | The combined file may be over the limit |
| Number of jobs | One per scanned source | One |
| Redoing one document later | Replace one part and merge again | Run the whole file again |

The risk in the right-hand column is real for mixed sets. A tool that recognizes a page which already holds exact typed text can swap that text for a reading of its picture. The post on OCR for PDF documents covers [whether to run OCR on a PDF that already has a text layer](https://www.schemalaw.com/blog/ocr-for-pdf-documents#should-you-run-ocr-on-a-pdf-that-already-has-a-text-layer).

Limits push the same way. Schema Law accepts a file of up to 20 MB and caps the pages in one document at 3 on the free plan, 250 on Solo and 1,000 on Team, as the [pricing page](https://www.schemalaw.com/pricing) sets out. A combined closing set or exhibit volume can pass a cap that each of its parts sits well under.

A working rule for the Brennan set: leave files 1, 3 and 5 as they are, run OCR on the deed and the survey, test both results, then merge the five files. Two short recognition jobs, three files never touched.

Choose OCR after combining when you are handed a stack of raw scans that belong together, such as forty single-page scans of one ledger. There is no existing text to protect, and one job over one file keeps the page order and the page count in a single place.

## What happens to bookmarks and file names when searchable PDFs are merged

File names disappear in a merge unless the tool turns each one into a bookmark, and bookmarks inside the sources survive only if the tool carries them across. Both behaviours differ between programs and between settings in one program. Look at the bookmarks panel of the result, and build one bookmark per source document if the merge left none.

The text layer is a property of each page, which is why it survives. Navigation and description are properties of each file, and a combined file has room for only one set of them.

| Belongs to each source file | After a merge |
| --- | --- |
| File name | Gone, unless the tool made it a bookmark |
| Bookmarks | Kept, dropped or nested under the file name, depending on the tool |
| Title, author and other document properties | One set survives; the others are discarded |
| Page labels such as i, ii, iii or A-1 | May be reset or carried across unevenly |
| Links from a table of contents to a page | May point to the wrong page or stop working |
| Files attached to a source PDF | May be left behind |

Page labels have their own trap, and the post on mismatched page numbers explains [what happens to page labels when PDFs are split or combined](https://www.schemalaw.com/blog/pdf-page-numbers-dont-match#what-happens-to-page-labels-when-pdfs-are-split-or-combined). For the wider question of what a file keeps when it is converted, see the post on [what a PDF keeps when it becomes a searchable PDF](https://www.schemalaw.com/blog/pdf-to-searchable-pdf).

Three steps before the merge save rebuilding afterwards:

1. **Rename the sources so the name is the bookmark you want.** `02_Deed_signed.pdf` makes a better bookmark than `scan0043.pdf`. The leading number also fixes the order.
2. **Check the merge options.** Look for a setting about adding bookmarks from file names, and one about keeping existing bookmarks.
3. **Write the page map.** List each source, the page range it will occupy in the combined file and whether it has a text layer. The list doubles as an index. If you insert it as the first page of the combined file, add one to every later page number in the map.

After the merge, click every bookmark. A bookmark that lands one page late is a sign that a page was added or dropped ahead of it.

If the combined file is headed for a court, read that court's rules on bookmarks and exhibits before you settle the structure. The post on [searchable PDFs for court filing](https://www.schemalaw.com/blog/searchable-pdf-for-court-filing) is a starting point, and requirements vary by court.

## Putting the parts of a split scan back together in page order

Rejoin the parts of a split scan in the order of the original pages, then prove the order with page counts. Sort the parts by a numbered file name, merge them, and confirm that the combined page count equals the sum of the parts and that the text reads straight through at each join.

Long scans get split for practical reasons: an upload cap, an email limit, or a recognition tool with a page ceiling. The post on [splitting a searchable PDF](https://www.schemalaw.com/blog/split-a-searchable-pdf) covers the cutting. This section covers the return journey.

Take a 612-page exhibit volume in the fictional matter of Halvorsen v. Dray Logistics, split into three parts so each fits a 250-page limit, then recognized part by part.

| Part | File name | Original pages | Pages in part |
| --- | --- | --- | --- |
| 1 | `Halvorsen_ExVol_part01_p001-250_ocr.pdf` | 1 to 250 | 250 |
| 2 | `Halvorsen_ExVol_part02_p251-500_ocr.pdf` | 251 to 500 | 250 |
| 3 | `Halvorsen_ExVol_part03_p501-612_ocr.pdf` | 501 to 612 | 112 |
| | | Total | 612 |

Four things go wrong on the way back.

- **Sort order.** Part names without a leading zero sort out of sequence; the splitting post covers [naming the parts so they sort and rejoin](https://www.schemalaw.com/blog/split-a-searchable-pdf#naming-the-parts-of-a-split-searchable-pdf-so-they-sort-and-rejoin). Check the order in the merge dialog itself, because a tool may list files in the order you clicked them.
- **The wrong version.** After recognition, the folder holds each part twice: the split piece and its searchable counterpart. Merging one unrecognized piece by mistake gives a patchy file. Move the unrecognized pieces to a subfolder before you merge.
- **Overlap.** If the parts were cut with a page repeated at each boundary, the combined count comes out higher than the original. Remove the repeats and record that you did.
- **A missing part.** Three parts of 250, 250 and 112 pages add up to 612. A combined file of 362 pages means one part of 250 was left out.

Do the sum on paper before the merge and read the page counter after it. The numbers must agree with the count of the original volume, which you recorded before the split. If nobody recorded it, open the unsplit scan and read it now.

## Testing a combined PDF at the seams between its source files

Test the first and last page of every source inside the combined file. A seam is where a missing page, a repeated page, a file in the wrong position or an unsearchable source shows itself. Search for a word on each side of every seam and read across the join.

A merge can only go wrong at the boundaries or across a whole source. Pages in the middle of a source file come along in a block. So a test concentrated on the seams, plus one search inside each source, covers the ways a combined file fails without reading every page.

For each seam in your page map:

1. Go to the last page of the earlier source. Confirm by eye that it is the last page of that document: a signature block, a certificate, the final page number.
2. Pick a word on that page and search for it. Confirm the hit lands there.
3. Go to the next page. Confirm it is the first page of the next source: a caption, a title, page 1.
4. Pick a word on that page and search for it.
5. Click the bookmark for the later source, if there is one, and confirm it lands on the page from step 3.

Then record the result. For the Brennan closing set:

| Seam | Last page of earlier source | First page of later source | Search each side | Result |
| --- | --- | --- | --- | --- |
| Agreement to deed | 34, signature page | 35, deed caption | "Okafor" found on 34 and 35 | Pass |
| Deed to title commitment | 38, notary block | 39, Schedule A | "notary" on 38, "Schedule" on 39 | Pass |
| Title commitment to survey | 61, final exception | 62, survey sheet 1 | "exception" on 61, nothing on 62 | Fail: survey has no text |
| Survey to settlement statement | 63, survey sheet 2 | 64, statement page 1 | Nothing on 63, "settlement" on 64 | Fail on 63 |

The two failures point at one source, the survey, which went into the merge without recognition. Fix that source, merge again, and run the seam test again from the top, because a replaced file can shift every page after it.

Finish with two whole-file checks. Read the page counter against the total in your page map. Then run one search for a term that should appear in every source, and confirm the hits are spread across all the page ranges and not bunched in one. Give the scanned sources a closer look than the typed ones. For Schema Law's own exports, [the questions section of the homepage](https://www.schemalaw.com/#questions) says recognition is strongest on clean print and that nothing marks a passage as uncertain.

Keep the page map and the seam sheet with the combined file. They show which sources went in, in what order, and that the joins were checked on the day it was assembled.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)