Getting a Table Out of a PDF and Into a Spreadsheet

A table in a PDF looks like a table. It has rules, aligned columns and a header row, and it is obvious to you at a glance which number belongs to which heading. None of that obviousness is recorded in the file, which is why pulling the figures into a spreadsheet goes wrong in ways that are easy to miss and expensive to inherit.

What the file actually contains

A PDF stores text as marks placed at coordinates: these characters, in this font, at this position on the page. The column you see is not a column. It is a set of unrelated text fragments that happen to have been drawn at similar horizontal positions. The ruled lines are separate graphics that know nothing about the numbers sitting between them.

Every tool that turns such a page into rows and columns is therefore inferring the grid from the spacing. That inference is usually good and occasionally confidently wrong, and a confidently wrong table is the dangerous kind: it opens, it looks plausible, and one column is shifted.

The errors worth looking for

These are the failures that recur, roughly in order of how often they slip past a quick glance.

• Numbers arriving as text. A value written as 1,240 or $1,240 or with a trailing footnote marker is a string, not a number. It looks right in the cell and quietly contributes nothing to a sum.
• Minus signs that are not minus signs. Accounting exports often use a typographic dash, or wrap negatives in brackets. Either way the value stops being negative, and a total can come out wrong by twice the figure.
• Merged cells and multi-line cells. A description that wrapped onto two lines in the PDF frequently becomes two rows, pushing every value in that row out of alignment with its label.
• Repeated header rows. On a table running over several pages the header is redrawn on each one, so it reappears as data in the middle of the extracted range.
• Empty cells collapsing. Where a cell was blank, some extractions simply omit it, and everything to its right shifts one column left. This is the error that produces a plausible-looking table with the wrong answers.
• Scanned tables. If the page is an image, nothing can be extracted until OCR has run, and OCR confuses digits far more readily than letters. OCR explained covers what that process can and cannot promise.

Decide whether you need the conversion at all

Extraction is not always the cheapest route to the numbers, and it is worth two minutes to check.

1. 1Ask whoever produced the PDF for the source file, or for a CSV export. It costs one message, and it is the only version where the values are still values rather than pictures of values.
2. 2If the table is small, retyping it is often faster than extracting and then verifying an extraction, and it puts your attention on every figure rather than on the ones you happen to spot.
3. 3If the table appears in a report you receive regularly, solve it once at the source. A recurring extraction is a recurring opportunity for a silent shift.
4. 4If the page is a scan and the figures matter, budget for checking every digit, not for a spot check.

A checking routine that catches the shifts

Whatever produced the spreadsheet, the verification is the same, and it is the part most workflows skip.

1. 1Count the rows. Compare the number of data rows in the spreadsheet with the number in the PDF. A mismatch usually means a wrapped cell split, or a header row came through as data.
2. 2Re-total every numeric column and compare each total against the one printed in the document. This single check catches the collapsed-cell shift, the text-not-number problem and lost negatives at once.
3. 3Sum a column that should contain numbers. If the result is zero or improbably small, the values are strings. Most spreadsheet applications also align text left and numbers right by default, so a column of left-aligned figures is a visible warning.
4. 4Open the most complex row you can find, ideally one with a wrapped description, a blank cell and a footnote marker, and compare it against the PDF cell by cell.
5. 5Check the last page. Tables are commonly truncated at the end, and the final rows are the ones nobody reads.

What Formynex can and cannot do here

Formynex does not convert PDFs into spreadsheets. There is a page at /tools/pdf-to-excel describing the tool, but no processing is connected behind it, and that page is deliberately kept out of search results until there is. This guide exists because the question is worth answering honestly, not because there is a button at the end of it.

It is worth being precise about the tools that do work, because they are sometimes mistaken for a way around this. PDF to Word and PDF to Markdown both read the text layer and group it into lines by vertical position on the page. That is genuinely useful for getting prose out of a document, and it is exactly the wrong shape for a table: every cell sitting on the same line of the page is merged into a single line of text, with no record of where one column ended and the next began. You can read the values; you cannot import them.

One Formynex tool does earn a place in this workflow. If the table you need sits on three pages of a ninety-page report, Extract Pages will pull out just those pages first, in your browser. Whatever you then use to read the table has less to get wrong, and you have less output to verify.