Scanned PDF to Excel: Turning Image-Only Pages Into a Table

Scanned PDF to Excel fails for one reason, and it is not the converter: a scanned PDF contains no text. The page is a photograph wrapped in a PDF container, so software that reads a text layer finds nothing to read and returns an empty sheet — or a single cell holding the whole page. Getting the table out means recognising the pixels, and that is a different job with its own limits. This page covers how to check what kind of PDF you have, how to convert the scanned kind, and where the errors will come from.

Two kinds of PDF that look identical

A PDF exported from Excel, Word, or an accounting system carries its characters as characters — a text layer. Copy a row out of it and you get the row. A PDF produced by a scanner, a fax server, or a phone scanning app carries one big image per page; the characters exist only as ink shapes. Both open the same way, both print the same way, and one of them is roughly a thousand times easier to convert.

The difference matters because it decides the path. With a text layer, extraction is copying: the converter reads the hidden characters and the result is exact, no guessing involved. With a scan, every character has to be inferred from its shape, which is why the quality of the scan — not the quality of the tool — sets the accuracy ceiling.

The five-second test

Open the PDF in any viewer and drag the cursor across a row of numbers. If the text highlights and you can copy it into a note, the file is born-digital. If the cursor leaves a hand icon, or selecting does nothing, the page is an image and OCR is required. A third case exists in the wild: a scanned PDF that has been through OCR afterwards, so it has an invisible text layer sitting over the picture. Those convert like a digital file, but check a few values — a cheap OCR pass baked into the file can carry its own errors into your spreadsheet, and they are harder to spot because nothing is highlighted.

How to convert a scanned PDF to Excel

1. Open the PDF and try to select a row of text. If nothing selects, it is a scan.
2. Drop the PDF into the converter — up to 25 MB and ten pages per file.
3. Recognition runs page by page in the browser; the file is not uploaded.
4. Compare each page against the rebuilt grid, fix the yellow cells, then download .xlsx or .csv.

Ten pages is the per-file ceiling, which covers a monthly statement comfortably and a quarterly one not at all. For longer documents, split the PDF first and run the parts in sequence, keeping the export order the same as the page order so the rows stay chronological. The bank statement walkthrough covers that stitching in more detail, and the PDF to Excel page covers the digital-text case.

What actually goes wrong on a scan

Skew. A page fed at two degrees off vertical throws the row detection out by the bottom of the page: the first rows read cleanly, the last ones drift into the neighbouring column. A deskew step before conversion fixes more bad scans than any setting inside a converter.

Marks on top of data. A received stamp, a highlighter stroke, a signature or a coffee ring covering a digit means the digit is not visible to any OCR engine on earth. Those cells come back wrong or empty, and they are the ones to check by eye against the paper.

Continuation pages. A table that runs over a page break usually repeats its header row. After conversion you get that header again in the middle of the data, which breaks sorting until it is deleted. Rows that continue across a break — an invoice total split from its line items — have to be rejoined by hand.

Two-up scans. Book pages or A4 sheets scanned two at a time put two columns of a different table side by side on one image. Recognition sees one wide table with doubled columns. Crop each page before converting.

Making a better scan (this part is on you)

300 dpi in grayscale is the setting that works for tables almost everywhere. Below roughly 200 dpi, small digits start to merge into their neighbours and 5 becomes 6 with no warning. Above 400 dpi the files grow and the accuracy stops improving. Scan flat — a phone held at an angle introduces the perspective that a flatbed does not — and avoid the scanner's JPEG re-compression at a low quality setting, which leaves ringing artefacts around every character.

If a page is hopeless, rescanning takes a minute and saves twenty of correction. Working from the original paper beats working from a photocopy of a photocopy, and it is not close.

Why local recognition matters for financial PDFs

The documents people want in a spreadsheet are the ones they would least like on someone else's server: bank statements, payslips, supplier invoices, tax forms. Upload-based converters handle that by asking you to trust their retention policy. Here the rendering and recognition run inside the browser with WebAssembly, so the PDF never leaves the machine, there is no account, and there is no stored copy to be breached later.

There is a practical edge too: the same sandbox that keeps the file private is also why the tool works offline once the engine has loaded, which matters on a laptop tethered in a client's office with no usable Wi-Fi. The full statement is on the Privacy page.

When there is no need for OCR at all

Scans are the hard case because the data has to be inferred. Some PDFs make it unnecessary. Invoices issued under European e-invoicing rules often arrive as PDF/A-3 with a machine-readable XML payload embedded in the file — the totals, VAT lines and line items are already structured data, sitting beside a PDF that merely looks like a document. Reading that XML is exact and instant, and no amount of OCR competes with it. The invoice to Excel page describes that path.

The rule of thumb: if the file can hand you the numbers, let it. Reach for recognition only when the numbers exist as pixels and nothing else.

Scanned PDF to Excel FAQ

Related guides

• scanned PDF to Excel converter
• PDF to Excel
• bank statement to Excel
• invoice to Excel
• OCR image to Excel