How to get a table out of a PDF and into Excel without retyping it

You have a report with a table of figures you need in a spreadsheet. You select the table, copy it, paste it into Excel, and get a single column with every value stacked on top of the next. Or you get rows that are correct for four lines and then silently shift by one column for the rest. Either way, checking the result takes longer than retyping it would have.

The reason is worth understanding, because it tells you which approach will work on which document.

PDFs do not contain tables

A spreadsheet stores structure. It knows that a particular value sits in row twelve, column D, and that the column is headed Amount. That relationship is part of the file.

A PDF stores appearance. It knows that certain characters should be drawn at a specific position on the page. There is no row, no column and no header, because none of those concepts survive the export. What you see as a table is text placed so that it lines up in a grid, plus possibly some lines drawn between the values to suggest borders.

So when software extracts a table from a PDF, it is not reading structure. It is inferring it, by looking at where text sits on the page and deciding which items belong to the same row and the same column. Good extraction is good guessing.

Why the guess fails

Knowing what makes inference hard tells you what to expect before you start.

• Merged cells, where one heading spans several columns beneath it
• Values that wrap onto two lines inside a single cell, which look like two rows
• Tables with no ruling lines, where column boundaries must be guessed from spacing alone
• Numbers right-aligned in one column and left-aligned in another, shifting the apparent boundary
• A table continuing across a page break, repeating its headers partway through
• Footnote markers and currency symbols attached to values

A clean, ruled table with single-line cells extracts almost perfectly. A dense financial statement with merged headers and wrapped descriptions will need review whatever tool you use.

The scanned document problem

There is one case where extraction cannot work at all, and it is worth checking for first. If the PDF is a scan, the page is a photograph. There is no text to position and no positions to infer from, so extraction returns nothing.

The test takes a second: try to select a single number on the page. If nothing highlights, it is an image. Run OCR first to generate a text layer, then extract. Accept that you are now stacking one inference on another, and check the figures carefully, because OCR confusing an eight for a three in a column of numbers is both easy to do and hard to spot.

Getting a usable result

1. Confirm the PDF has real text by trying to select a value. Run OCR first if it does not.
2. Extract the whole document rather than a page at a time, so tables spanning pages stay together.
3. Open the spreadsheet and compare the first and last rows against the PDF before anything else.
4. Check the column totals. If the source has a total row, recalculating it in the spreadsheet catches most misalignment instantly.
5. Look specifically at rows where a description wrapped, since those are where shifts tend to start.

The totals check is the highest-value item in that list. A misplaced value nearly always breaks a sum, so one formula tells you whether the extraction can be trusted without reading every line.

When to stop fighting it

If the document originated as a spreadsheet, ask for the spreadsheet. Thirty seconds of asking beats an hour of cleanup and carries no risk of a transcription error entering your figures.

For a genuinely awkward table of twenty rows, retyping with a second person reading values aloud is sometimes faster and more reliable than repairing a bad extraction. Extraction earns its place on long documents, on repeated monthly reports, and on anything where the volume makes manual entry impractical.

Extraction gets you ninety percent of the way in seconds. The last ten percent is yours, and skipping it is where errors enter the numbers.