# Scanned PDF to Text: What You Get and How to Get It

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2023-06-26T21:28:30Z
- Updated: 2026-10-11T19:22:20Z
- Category: Converting scans
- Canonical: https://www.schemalaw.com/blog/scanned-pdf-to-text

> Extract plain text from a scanned PDF with OCR. What a TXT file keeps and drops, when to choose it, and how to handle line breaks and symbols.

To turn a scanned PDF into text, run it through OCR and export a plain text (TXT) file. You get the words from every page as ordinary characters, with no fonts, images or layout. That makes the file small, searchable by any program, and easy to paste, compare or index.

Plain text is the least glamorous export and often the most useful. It opens anywhere, it cannot hide anything, and it will still open in thirty years. The price is that everything except the words is gone. Whether that is a fair trade depends on the job, and the sections below go through the trade, the procedure and the quirks of the format.

## What does plain text keep and what does it drop?

Plain text keeps the characters and their order. It drops everything about how they looked: typeface, size, bold and italic, indentation, columns, and every image, including signatures and stamps. What is left is the wording, which for many legal tasks is the only part you wanted.

The detail matters, so here is how a plain text export from Schema Law treats each part of a document.

| In the scanned document | In the TXT file |
| --- | --- |
| Paragraph | The paragraph's words as running text, with a blank line after it |
| Heading | The heading's words on their own line, no longer distinguished from body text |
| Bulleted list | One item per line, each starting with a hyphen |
| Numbered list | One item per line, each starting with a number and a period |
| Table | One line per row, with a tab character between cells |
| Bold or italic type | The words only; the emphasis is gone |
| Signature, seal, logo, photograph | Nothing |
| End of a page | A form feed character, the plain text signal for a page break |

Two of those rows have consequences people overlook.

**Emphasis disappears without a trace.** If a contract puts a disclaimer in bold capitals, the capitals survive because they are characters, but the bold does not. If a transcript or an opinion italicizes a word for stress, the text file gives no sign of it. Anyone quoting from the file has to restore emphasis from the page image.

**Tables become rows of tab-separated values.** That is readable for a small table and useless for a ledger. If the figures matter, the post on [getting a scanned PDF into Excel](https://www.schemalaw.com/blog/scanned-pdf-to-excel) describes the better route.

If you want headings and tables to stay marked while keeping the file as simple text, Markdown is the middle path. The post on [PDF to Markdown OCR](https://www.schemalaw.com/blog/pdf-to-markdown-ocr) compares the two.

## Extracting text from a scanned PDF in three steps

The three steps are upload, review and export. Add the scanned file to an OCR tool, look over the pages it has read, and download the result as a TXT file. In Schema Law, plain text is an export format on every plan, the free one included, so you can try it without paying.

1. **Upload.** Sign in and add the PDF. A PNG or JPEG of a single page works too, which is handy for a phone photo of one document. Files can be up to 20 MB, and your plan sets how many pages one document may have.
2. **Review.** When the document is ready, open the parsed pages. Spend a minute on the page you care about most and compare a few lines with the scan. Reading order is the thing to watch: a two-column page or a page with a sidebar should come out in the sequence a person would read it.
3. **Export.** Choose Plain text. The download is a single `.txt` file containing every page in order.

Then do two small things that save trouble later. Rename the file so it is tied to its source, for example `Dunmore depo vol 2 (OCR text).txt`. And put a line at the very top stating where it came from and when it was made. A text file has no properties panel worth the name, so the provenance has to be in the text or in the file name.

What about a long file where you need only a few pages? Extract those pages into their own PDF first and upload that. You use fewer pages of your plan, and the text file contains only what you want.

What about a PDF that is partly typed and partly scanned? Upload the whole file the same way. You get one text file covering every page, which is easier to search than a patchwork of copied and recognized text. Check a typed page and a scanned page separately when you review.

## When is a TXT file better than Word or PDF?

A TXT file is better when the words are going somewhere else: into a brief, an email, a search index, a comparison, or a script. It is worse when a person needs to read the document as a document, or when layout carries meaning.

Pick by task:

| Your task | Best export | Reason |
| --- | --- | --- |
| Paste a passage into a brief or letter | Plain text | Nothing comes with the words; they take on your document's formatting |
| Search hundreds of documents at once | Plain text | Every search tool reads it, and the files are tiny |
| Compare two versions of a document | Plain text | A comparison sees only wording, not styling |
| Revise the document itself | Word | You need headings, lists and tables you can edit |
| File or produce the document | Searchable PDF | The page must look as it did |
| Total a schedule | Excel | Cells you can calculate with |

The pasting case deserves a word. Text copied from a Word conversion or from a searchable PDF often brings invisible baggage: a font, a paragraph style, a hard line break at the end of every line of the scan. Text from a TXT file brings none of the styling. That is why plain text is the usual source for a quotation, and the post on [quoting text from a scanned PDF](https://www.schemalaw.com/blog/how-to-quote-text-from-a-scanned-pdf) sets out how to verify one.

There is also a case for exporting text in addition to another format, not in place of it. You can export the same uploaded document more than once. A searchable PDF for the file plus a TXT for your working folder covers most needs, and the guide to [making a scanned PDF searchable](https://www.schemalaw.com/blog/how-to-make-a-scanned-pdf-searchable) explains the first of those.

Do not choose plain text for anything where position on the page is the point: a form with labeled boxes, a signature page, an organization chart, a plat. The words will arrive, but their relationship to each other will not.

## Line breaks, hyphens and page boundaries in extracted text

Extracted text can break in three places the original did not mean it to: at the end of each scanned line, at a hyphen where a word was split, and at the end of each page. Each one affects searching and pasting, and each has a simple check.

### Line breaks

Older OCR output often ends every line where the scan's line ended, so a paragraph arrives as a ragged stack of short lines. In Schema Law's TXT export, a paragraph's lines are joined and written as continuous text, and paragraphs are separated by a blank line. Your editor wraps the text to the window. If a paragraph does come out in pieces, the page was probably read as several short blocks, which happens with pleading paper, forms and narrow columns.

Why it matters: a phrase search fails when a line break sits in the middle of the phrase. Before a long search session, paste a paragraph into your editor and confirm it is one unbroken run.

### Hyphens

A word split at the end of a printed line, such as "indemni-" and "fication", can come through three ways: rejoined correctly, joined with the hyphen kept ("indemni-fication"), or left as two fragments. Real hyphens ("attorney-client") must stay. No automatic rule distinguishes the two perfectly. When a search for a long word finds fewer hits than you expect, search for its first half and see what follows.

### Page boundaries

A form feed sits between one page's text and the next. It is an invisible control character that old printers used to eject a sheet. Programs show it differently. Some editors display a small symbol or a box, some show nothing, and some word processors start a new page there.

The form feeds are useful. Counting them tells you which page of the scan a passage came from: text after the fourth form feed is on the fifth page of the uploaded file. Leave them in. If a tool you are feeding chokes on them, replace each one with a visible marker such as `[page 5]` and do not delete them outright.

Remember that this is the page of the file, which may not be the number printed on the page. A production that begins at HARLOW-0004127 is not at "page 1" in any sense your reader will recognize.

When you lift text from that production, carry the Bates number into your note along with the file page. An exhibit sticker may sit on the image and stay easy to miss in the text file. Discovery review later depends on that link, so write the exhibit number next to any passage you keep.

Also expect the page's furniture, meaning running headers, footers and printed page numbers, to appear in the text wherever it sat on the page. A sentence that crosses a page boundary will have a footer, a form feed and a header in the middle of it.

## Feeding extracted text into search and comparison tools

Plain text is the input almost every search and comparison tool prefers. Once a set of scans exists as TXT files, you can search all of them at once with tools you already have, compare versions line by line, and count or extract patterns such as dates and dollar amounts.

**Searching a folder.** Your operating system's file search, a code editor's "find in files", or a command-line tool will all search a folder of text files in seconds. Name each text file after its source document so a hit leads you to the scan. A search like this is how you answer "which of these 60 letters mentions the escrow account" without opening 60 PDFs.

**Pattern searches.** Many editors support patterns in addition to literal words. A pattern for a dollar sign followed by digits lists every amount in a contract. A pattern for two digits, a slash, two digits, a slash and four digits lists the dates. Treat the list as a set of leads to check against the pages, never as a finished schedule.

**Comparing versions.** A text comparison tool shows what differs between two files. It is the quickest way to see whether the "final" scan a counterparty sent matches the draft you agreed. Two cautions apply. Both sides should be text produced the same way, or layout differences will swamp the real ones. And when you compare a scan with a native document, every OCR misread shows up as a difference. That is useful, since it doubles as a proofread, but it means each difference has to be resolved against the page image before you call it a change in the deal.

**Indexing.** Document management and desktop search programs build their indexes from text. A scan sitting in a matter folder with no text is invisible to them. Whether your system indexes a companion TXT file or needs a searchable PDF depends on the system, so test with one document.

**Passing text to other software.** Summarizing, classifying or extracting with another program all start from text. If the document is a client's, decide where the text is allowed to go before you send it anywhere. The post on [whether it is safe to upload client documents to an OCR tool](https://www.schemalaw.com/blog/is-it-safe-to-upload-client-documents-to-an-ocr-tool) lists the questions to ask of any service, and Schema Law's own commitments are set out in the [security section of the homepage](https://www.schemalaw.com/#security).

A warning that applies to all of these: a search of OCR text finds what was recognized, not what was printed. A clean "no results" over poor scans proves little. Keep a note of which source files were hard to read so that a negative search is weighed accordingly.

## Text encoding and special characters in legal documents

A text file is a sequence of numbers, and an encoding is the rule that maps those numbers to characters. Schema Law's TXT export is written in UTF-8, which can represent section signs, paragraph marks, curly quotation marks, accented names and non-Latin scripts. Problems arise when another program opens the file under a different rule.

Legal documents are full of characters outside the plain typewriter set:

- the section sign (§) and paragraph mark (¶) in citations
- curly quotation marks and apostrophes in anything typeset
- long dashes in prose and in number ranges
- accented letters in party names, such as Muñoz or Škoda
- currency signs other than the dollar, such as £ and €
- degree signs and fractions in property descriptions

The classic failure looks like this: "§ 1983" shows up as "§ 1983", or a curly apostrophe turns into three odd symbols, as in "don’t". Nothing is wrong with the file. The program opening it has assumed an older Western encoding and is reading each multi-byte character as two or three separate ones. The fix is to reopen the file and choose UTF-8 in the program's open or import dialog. Do not fix the symbols by hand, and do not save the file from the program that misread it, because that bakes the damage in.

Three related points for legal text:

- **Recognition errors are a separate problem from encoding errors.** If "§" appears as "S" or "5", the software misread the symbol on the page. That is consistent throughout a document and worth a targeted search: look for "S 12" and "5 12" patterns near citations.
- **Quotation marks may not match your house style.** The text holds whatever marks were recognized, straight or curly. When you paste into a brief, let your word processor's settings govern, and check that opening and closing marks pair up.
- **Lookalike characters defeat search.** A hyphen, a non-breaking hyphen and a dash are different characters that look almost the same. So are a capital "I", a lowercase "l" and the digit "1" in many typefaces. If a search for a statute citation or a hyphenated term fails, retype the search without the punctuation.

When a text file is going into another system, tell whoever runs that system that it is UTF-8. Naming the encoding up front avoids most of these problems.

For what happens between the upload and the text, stage by stage, see [how OCR extracts text from a PDF](https://www.schemalaw.com/blog/ocr-extract-text-from-pdf).

## 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)