Convert a Scanned PDF to Excel

OCR runs on your device. No account, no upload, no page limit.

Why your scanned PDF converted to an empty spreadsheet

Because there was nothing in it to put in cells. This is the single most common surprise with these documents and it is worth understanding before you try another tool.

A PDF made by software — exported from Word, generated by a billing system, printed to PDF — stores characters, each with a position on the page. A converter reads those characters and works out which ones share a row and which share a column. A PDF made by a scanner or a copier stores one photograph per page. There are no characters in it at all. Open it in a reader and try to select a word: if nothing highlights, that is what you have.

So a converter with nothing to read has two honest options: produce an empty sheet, or say so. This one says so, and points you at the tick that fixes it — Read scanned pages (OCR). With that on, each page is rendered to an image, the characters are recognised, and the recognised words are then treated exactly like the characters a normal PDF would have supplied.

The structure survives what the characters do not

This is the finding that matters for a spreadsheet, and it runs the opposite way to what people expect. Column layout is robust. Individual digits are fragile.

We rendered the same five-column statement at falling quality and measured what came back:

All five columns came back every single time, including from a 56 dpi scan so grainy it is unpleasant to read. The cells are where quality shows: 150 dpi gives you a table you can trust, 56 dpi gives you a table you have to check.

On a denser page the same story from the other side. A 30-row statement at 150 dpi gave 60 of 60 money figures exactly right; a rough 82 dpi version of the same page gave 53 of 60. Seven wrong figures in a statement is not a rounding error, it is a wrong answer — so on a poor scan, check the numbers.

Getting a better scan is cheaper than fixing a bad one

Everything above is decided before the file reaches any converter. If you are the one doing the scanning:

• 300 dpi is the setting to use, and 150 is the floor where results stay comfortable. Most office copiers default to 200 or 300 for documents and drop to 150 for "email" or "compact" modes — that mode is the usual culprit behind a bad file.
• Black and white or greyscale beats colour for a printed table. Colour adds nothing a recogniser uses and makes the file several times larger.
• Flatten the page. A sheet that lifts off the glass throws a shadow along the crease, and a shadow through the middle of a column is read as ink.
• Straighten it. Our measurement above shows the cost: half a degree is free, one and a half degrees costs real accuracy. Scanner software usually has a de-skew option; turn it on.
• Avoid the heaviest compression. The grain and JPEG artefacts in the fifth row of that table are exactly what "smallest file size" produces.

If the scan already exists and cannot be redone, run it anyway — the columns will be right, and correcting a handful of figures in the preview is quicker than it sounds.

Generations: why a photocopy of a fax is a different problem

Documents in circulation are rarely first-generation. A supplier prints an invoice, faxes it, the recipient photocopies it for a file, and somebody eventually scans that copy to send onward. Each of those steps thickens the strokes slightly and adds speckle, and the damage compounds — by the third generation the counter inside an e has closed up and a recogniser reads it as a c or an o.

Fax is the worst of the chain by a wide margin. Standard fax resolution is roughly 200 by 100 dots per inch — deliberately squashed vertically, because the standard was designed for telephone lines rather than legibility. Characters arrive taller than they are detailed, and a decimal point is a single dot that may not have survived the journey. If a faxed document is all you have, expect the columns and verify every figure.

Two practical consequences. First, always chase the earliest generation you can reach — asking the sender for the original PDF takes a minute and removes the problem entirely, because a software-generated PDF needs no recognition at all. Second, if you must re-copy a document before scanning it, raise the contrast on the copier rather than lowering it; pale, broken characters are far harder to recover than slightly heavy ones.

Two things a scan loses that a normal PDF keeps

The ruling lines

When a PDF is generated by software, a bordered table carries its own geometry: the rules are vector paths with exact coordinates, and reading them gives a grid that matches the printed one exactly. A scan has no paths — the borders are dark pixels in a picture. So a ruled table that has been scanned is read the same way an unruled one is, by looking at the gaps between words. That works well, and it is worth knowing that a scan gives up the more precise of the two methods.

The page's own structure across pages

Grouping several pages into one continuous table relies on comparing headings and column positions between pages, and both come back slightly noisier from a scan. The grouping still works — over ten multi-page fixtures the rule got 10 of 10 right with nothing wrongly merged — but a scan is where you should glance at the preview before trusting the join.

Mixed documents: a scanned insert among typed pages

Very common in practice — a contract exported from software with a signed page photographed and dropped back in, or a report with one page of appendix that was faxed. Whether a page needs recognising is decided per page, not per document. Pages that carry real text are read directly, which is both faster and exact; only the pages that need it are rendered and recognised. The preview and the page list mark which pages went through OCR, so you know which ones to check.

That also means you never have to split the file first, and you never pay the recognition cost on pages that did not need it.

Checking the result, and what gets marked for you

A cell that cannot be what its column is gets a ⚠. The classic case is a zero read as a capital O, giving 12O0.00 in a column of money — not a hesitant reading, an impossible one. On deliberately corrupted figures that check flagged 6 of 6 with no false alarms, and it raised nothing at all on 6 correctly extracted typed pages.

Its limit is stated plainly because it matters: it catches roughly one OCR mistake in five. Most of the rest are in description text, where there is nothing to check a word against — SAINSBURVS for SAINSBURYS is wrong and looks like a perfectly ordinary word. A page with no marks is not a page with no errors.

Double-click any cell in the preview to correct it. The correction goes into the file you download, and the extraction underneath is left alone, so changing the format or the sheet settings afterwards keeps your edits.

Where to go next

• PDF to Excel OCR — what is actually doing the recognising, the measurements behind its settings, and why nothing is shaded by confidence.
• Photo to Excel — if the "scan" is really a phone photograph, the advice is different and mostly about how you hold it.
• Bank statement to Excel — the document most often scanned, and the only one that can check its own arithmetic afterwards.

Frequently Asked Questions

Related Tools