# Scan Text to Excel: Lines, Lists and Paragraphs

- Author: FastBankConvert (https://fastbankconvert.com)
- Published: 2026-10-17
- Category: Scanned and image statements
- Canonical: https://fastbankconvert.com/blog/scan-text-to-excel

> Scan text to Excel when the page is lists or paragraphs, not a table: one line per row, splitting on a pattern, and when a document is the better target.
To scan text to Excel when the page holds lists or paragraphs rather than a table, run OCR to get plain text, paste it so each printed line lands in its own row, then split each row on a repeating separator such as a dash or a comma. Paragraphs of running prose usually belong in a document instead.

## What does scan text to Excel mean without a table?

Scanning text to Excel without a table means turning printed lines into rows you can sort, filter and count. The page has no ruled columns, so the spreadsheet has to get its structure from the text itself: one line per entry, and a repeating mark inside each line that separates the pieces.

Table converters expect cells. They look for ruled lines or neat vertical gaps between columns and build a grid from them. A typed membership list, a page of notes, a printed price sheet with dot leaders or a letter full of figures has none of that. Feed it to a table converter and you tend to get one wide column, or columns split in odd places wherever two words happened to line up.

So the job splits into two parts:

- **Recognition.** OCR reads the page picture and returns the characters, line by line. Any OCR tool can do this, including the online kind covered in [what an image to Excel converter online does with a photo](/blog/image-to-excel-converter-online).
- **Shaping.** You decide what one row means and where the columns break, then use Excel to apply that rule to every line.

Before you start, confirm the file really is a scan. A PDF that already holds text can be copied directly, and [the ten-second image PDF test](/blog/pdf-image-to-excel#how-do-you-tell-an-image-pdf-from-a-text-pdf) tells you which kind you have.

Knowing the target shape before you scan saves rework. Ask what a single row should hold. In a list of members it is one person. In a page of handwritten-then-typed meeting notes it might be one action item. If you cannot name the row, the text probably does not belong in a spreadsheet.

## One scanned line per Excel row

The simplest way to get one scanned line per Excel row is to save the OCR result as plain text, open that text file in a text editor, copy everything, and paste into cell A1. Excel puts each line break in a new row. Pasting the same text from a word processor can instead merge lines or bring in formatting.

Line breaks are what carry the structure, so protect them:

1. **Export as plain text** if your OCR tool offers it. A .txt file keeps one line per printed line and carries no fonts or columns.
2. **Paste into column A only.** Click A1 and paste. If Excel opens the Text Import Wizard, choose Delimited and clear every delimiter for now. You split later.
3. **Delete blank rows.** OCR often adds an empty line between paragraphs. Filter column A for blanks and delete those rows.
4. **Remove repeated page furniture.** Page numbers, running headers and "continued" lines appear once per page. Filter for them and delete.
5. **Number the rows.** Put 1, 2, 3 in column B before any sorting, so you can always return to the printed order.

If the whole page lands in a single cell, the text had no real line breaks, only wrapped display. Paste it into a plain text editor first, check that each entry sits on its own line, and paste again.

## Splitting scanned lines on a pattern with TEXTSPLIT

TEXTSPLIT breaks a line of text into columns at every separator you name. Microsoft's page for the [TEXTSPLIT function](https://support.microsoft.com/en-us/office/textsplit-function-b1ca414e-4c21-4ca0-b1b7-bdecace8a6e7) describes it as splitting text by column and row delimiters, like the Text to Columns wizard but as a formula. One formula per row turns "Name - Town - Amount" into three cells.

### A worked example

The lines below are an example of what OCR returned from a typed list of club members. The names and figures are made up.

```
Ana Ruiz - Leeds - 40.00
Tom Okafor - York - 25.00
Priya Shah - Leeds - 40.00
Daniel Berg - Hull - 15.00
Mei Chen -York - 25.00
Sam Ortiz - Leeds - 40,00
Lena Novak - Hull - 15.00
Omar Haddad - York - 25.00
```

With those lines in A1:A8, put this in B1 and fill down:

```
=TEXTSPLIT(A1," - ")
```

Each row spills into three columns. The result for most rows is clean:

| Name | Town | Amount |
| --- | --- | --- |
| Ana Ruiz | Leeds | 40.00 |
| Tom Okafor | York | 25.00 |
| Mei Chen -York | 25.00 | (empty) |

Row 5 shows the usual trouble. OCR dropped the space after the dash in "Mei Chen -York", so the separator did not match. The line broke into two pieces instead of three, and the amount slid into the Town column. Two fixes work. You can clean the source line by hand. Or you can split on the dash alone and trim the pieces:

```
=TRIM(TEXTSPLIT(A1,"-"))
```

Splitting on the bare dash fails for anyone with a hyphenated name, so pick the separator that never appears inside a piece. Row 6 has a different problem: "40,00" with a comma. The split works, but the amount is text. Replace the comma and wrap the amount in VALUE before you total it.

The steps, in order:

1. Look at ten lines and pick the separator every line shares.
2. Check whether that separator ever appears inside a value.
3. Write the TEXTSPLIT formula on row 1 and fill down.
4. Filter for rows where the last column is empty or #N/A. Those lines broke the pattern.
5. Fix those lines in column A and let the formulas recalculate.
6. Copy the result and paste it as values before you sort.

If your version of Excel lacks TEXTSPLIT, the Data tab's Text to Columns wizard does the same job once, without a formula.

When you only need a handful of facts from each page, such as a date and a reference number, splitting every line is overkill. [Extracting chosen fields from a scanned PDF to Excel](/blog/extract-data-from-scanned-pdf-to-excel) covers that narrower job.

## How do you rejoin paragraphs that wrap across scanned lines?

You rejoin wrapped paragraphs by deciding which line breaks are real and which are only the edge of the printed page. In OCR output every printed line ends with a break. A sentence that wrapped therefore arrives split across two or three rows, and each fragment looks like a separate entry.

There are a few ways to tell a wrap from a real break:

- **The next line starts in lowercase.** A real entry usually starts with a capital, a number or a bullet.
- **The line does not end with punctuation.** Real paragraphs and list items often end with a full stop or a figure.
- **The line is as long as the page width.** Wrapped lines run to the margin. Final lines of a paragraph are usually shorter.
- **There is a hyphen at the end.** "recon-" followed by "ciliation" on the next row is one word.

In Excel, a helper column can flag likely wraps. If B2 holds `=AND(LEN(A1)>60, EXACT(LEFT(A2),LOWER(LEFT(A2))), NOT(EXACT(LEFT(A2),UPPER(LEFT(A2)))))`, TRUE means row 2 starts with a lowercase letter and probably continues row 1. The third test stops a line that starts with a digit or a symbol from being flagged. Adjust the 60 to the typical line length of your page. Then join flagged rows with `=A1&" "&A2` and delete the continuation row.

This is fiddly work, and it gets worse with each paragraph. A page with three or four short wrapped items is worth fixing in Excel. A page of solid prose is the signal to stop and consider a different target, which the next section covers.

Bank statements have their own version of this problem. A long payee description can wrap onto a second printed line with no date and no amount. If that is what you are scanning, the rows belong in a fixed set of columns, and [a bank statement Excel template for converted statements](/blog/bank-statement-excel-template) gives you that layout with a running balance built in.

## Is a Word document a better target for scanned text?

A Word document is the better target whenever the scanned text is meant to be read rather than counted. Letters, contracts, reports and notes keep their meaning in paragraphs. Splitting them into rows destroys the flow and gains nothing, because there is nothing to sort or total.

A rough rule for choosing:

| What the page holds | Better target | Why |
| --- | --- | --- |
| A list of names, items or codes | Excel | Each line is an entry you can sort and filter |
| Entries with repeating separators | Excel | TEXTSPLIT turns the pattern into columns |
| A few figures inside a letter | Excel, for the figures only | Pull the numbers out and leave the prose |
| Running paragraphs | Word or a text file | The sentences are the value |
| A mix of paragraphs and a table | Both | Prose to the document, the table to Excel |

Mixed pages are common. A letter from an insurer might have three paragraphs of explanation and a small table of premiums. Send the table to Excel and keep the letter as a searchable PDF or a document. Forcing both into one sheet leaves you with a table you cannot sum and paragraphs you cannot read.

Scanned bank statements sit firmly on the Excel side. Their lines are entries with dates and amounts, and the running balance gives you a way to check the result. FastBankConvert is built for that layout, reading statement PDFs into Excel or CSV and warning you when the balances do not add up. It is getting ready to open, and [Get started](/get-started) puts you on the list.