PDFs do not contain tables — they contain text at coordinates. Understanding that explains why extraction sometimes works perfectly and sometimes produces nonsense.
Bank statements, invoices, price lists, exported reports — enormous amounts of useful data arrive as PDF tables that you then have to retype. Extraction tools can save that effort, but their results vary wildly, and the reason is worth understanding before you judge any particular tool.
PDFs do not contain tables
This is the crucial point. When you look at a PDF table you see rows, columns and perhaps gridlines. The file contains none of those concepts.
What it contains is a list of text fragments, each with x and y coordinates, and possibly some line-drawing instructions that happen to look like a grid. There is no marker saying "this is a table," no cell boundaries, and no indication of which fragments belong together.
Extraction therefore means inferring structure from geometry — and how well that works depends entirely on how regular the original layout is.
How good extraction works
A capable tool reconstructs the grid in two passes:
- Rows come from vertical position. Text fragments sharing a baseline, within a tolerance, belong to the same row.
- Columns come from horizontal position. If many rows have text starting at roughly the same x coordinate, that position is almost certainly a column boundary. One-off indents are not.
Our PDF to Excel tool does exactly this, and then tells you how many pages it judged genuinely tabular — so you know whether to trust the output or check it carefully.
What extracts well
- Bank and credit card statements. Highly regular columns, consistent row spacing.
- Invoices and line-item lists. Usually clean.
- Price lists and catalogues. Generally good.
- Reports exported from databases. Often the best case, since a machine laid them out consistently.
What causes trouble
- Merged cells. A header spanning three columns has one position, so it lands in one cell.
- Multi-line cells. A description wrapping to three lines looks like three separate rows geometrically.
- Tables spanning pages. Each page is analysed separately, so headers repeat and you will need to stitch them.
- Right-aligned numbers in variable-width columns. Alignment varies with value length, blurring the boundary.
- Scanned tables. No text at all — run OCR first.
Checking the output properly
Extraction is not a fire-and-forget operation when the numbers matter. Spot checks that catch most errors in under a minute:
- Count the rows. Compare against the PDF. A mismatch means wrapped cells split or rows merged.
- Check the totals. If the source has a sum, verify it against the extracted column. This catches misplaced decimal points and shifted cells immediately.
- Inspect the first and last rows. Headers and footer totals are the most likely to be misaligned.
- Confirm numbers are numbers. If a column will not sum, the values arrived as text — often because of currency symbols or thousands separators.
When extraction is the wrong approach
If the data exists somewhere as CSV, Excel or a database export, use that instead. A PDF is the output of a system that almost certainly had the data in a structured form. Asking the sender for the underlying file takes one email and beats any extraction tool.
Extraction is for when the PDF is genuinely all you have — which, with statements and third-party reports, it very often is.
Privacy
Financial statements are among the most sensitive documents most people handle, and uploading them to a free converter means a complete copy of your account activity sits on someone else's server. Our extraction runs entirely in your browser, so the statement never leaves your machine.
Pixellwork Editorial
Documents & Privacy
Published October 1, 2026