How to Extract Tables from PDF

A PDF does not contain tables. This is the single fact that explains why table extraction works beautifully on one document and produces nonsense on the next, why two tools disagree about the same page, and why no setting fixes the hard cases.

Once you accept it, the practical question changes from "which tool is best" to "does my table carry enough evidence of its own structure for anything to reconstruct it". That is answerable by looking at the document, and it takes about ten seconds.

What a PDF stores instead of a table

A PDF is a set of drawing instructions. For a page of tabular data it holds, more or less: put the string Laptop dock at this x and y in this font, put 2700.00 at that x and y, draw a line from here to there.

There is no cell, no row, no column and no header. The table you see is something your visual system infers from alignment and whitespace, and every extraction tool is doing the same inference with far less context than you have.

Worse, the order the strings are stored in is the order the generator happened to emit them, which is frequently neither reading order nor row order. That is why copying a two-column layout so often pastes as interleaved lines, and why copying a table produces a single column of values with nothing to say which row each came from.

You can see this for yourself on one of your own documents with Extract Text from PDF. It returns the text the file contains, in the browser, with nothing uploaded — and the instructive part is that the words all arrive and the structure does not come with them.

Look at your table before choosing anything

Three properties decide how this will go, and all three are visible at a glance.

Ruled or not. Does the table have drawn lines between its cells? Ruled tables are dramatically easier, because the lines are real objects in the file, and cell boundaries can be read rather than guessed. A table separated only by whitespace has to be inferred from alignment alone, which is where tools start disagreeing with each other.

Consistent columns. Does every row have a value in every column, and do the columns line up down the page? Ragged tables with empty cells are where columns get merged or shifted.

Single page or continued. A table that runs across a page break usually repeats its header and sometimes carries a subtotal. Both become rows if nobody is watching.

A ruled, fully-populated, single-page table will come out almost exactly right from almost any tool. A whitespace-aligned, ragged, three-page table is a job that needs checking line by line whatever you use.

How tables go wrong, specifically

Knowing the failure modes is what lets you spot them in the output. Take a three-column extract where the description column is wide and whitespace is the only separator:

A bad read of those same two rows produces three:

row 1   "Laptop dock, 4-port 3"   ""   "2700.00"
row 2   "Keyboard, UK layout,"    ""   ""
row 3   "backlit 4 320.00"        ""   ""

Two separate failures there, and both are typical. The quantity has been absorbed into the description because the gap between the columns was narrower than the gap inside the text. And the second item's wrapped description has become a row of its own, which means the extract now has three rows where the document had two — and the Qty column, which should have held 3 and 4, is empty on every one of them.

The other four failures worth recognising:

Merged header cells. A header spanning two columns produces either one column too few or a header in the wrong place, and everything below inherits it.

Repeated headers mid-table. On a continued table, the repeated header row arrives as a data row reading "Description, Qty, Amount".

Subtotals as items. "Carried forward" and section subtotals sit among the rows and look exactly like rows.

Right-aligned numbers against a long value. A long description pushes into the numeric column's space and the two collide.

All of them have the same remedy, and it is not a setting: decide what a row is before you start — usually "a line carrying a quantity or an amount" — and treat everything else as belonging to the nearest such row.

Ways to extract a table

Copy and paste. Always try it first; it costs five seconds. Some PDFs paste perfectly. Then paste into a spreadsheet and use Text to Columns, splitting on a delimiter or by fixed width. Fixed-width splitting is the underrated option and it is excellent on monospaced system reports and bank statements, because those really are aligned by character position.

Excel's built-in PDF import. Data → Get Data → From File → From PDF lists the tables Excel believes it found on each page and lets you preview each before loading. Worth knowing about because it is already installed, and the preview is the valuable part — it shows you the misread before you build anything on it.

Dedicated table extractors. Tabula and Camelot are the established open-source options, and both let you draw the table region on the page, which removes most of the ambiguity in one stroke. Camelot distinguishes ruled tables from whitespace-aligned ones and uses a different strategy for each, which is exactly the distinction this article is about.

Acrobat's export. Export to Excel from Acrobat if you have a licence. Good on ruled tables, and it produces a worksheet shaped like the page rather than like your data, which matters for what comes next.

Field extraction instead. If what you want is six values from each of fifty documents rather than one table verbatim, table extraction is the wrong approach entirely. See the section below.

Multi-page tables need a plan, not a tool

The commonest real-world table is one that runs across several pages, and the commonest mistake is extracting it page by page and concatenating.

Do it deliberately instead:

1. Extract each page separately.
2. Delete the repeated header row from every page after the first, before joining anything.
3. Remove subtotal and "carried forward" rows, keeping a note of what they said.
4. Join, then check the row count against those subtotals. This is the only independent check you have that the join is complete.
5. Re-check the first and last row of every page boundary specifically. Boundaries are where rows go missing, because a row split across the break can be dropped by both halves.

If the pages are in one large PDF and you want to work through them in pieces, Split PDF separates it by page range in the browser, and PDF Page Counter tells you how many pages you are dealing with before you commit.

Check the extract against something the document already tells you

Never ship a table extract unchecked, and do not check it by re-reading it. Use the arithmetic the document supplies:

• Sum the amount column and compare with the printed total. If the document prints a total, you have a complete independent check of every row for the cost of one formula.
• Count the rows and compare with a printed count if there is one — "12 items", "page 1 of 3".
• Look for rows with a gap. A row with a description and no amount, or an amount and no description, is a wrapped line or a merged cell. Filter for them.
• Sort each numeric column. A lost decimal point sits at the top of a sort and is invisible in the middle of a sheet.

A difference you can explain — tax, delivery, rounding — is fine. A difference equal to exactly one row's value is a missing row.

When you do not want the table at all

Worth separating, because it is the distinction most people have not drawn, and it changes the method completely.

You want the table verbatim. One document contains a price list, a schedule or a statement, and you need it as a grid. Table extraction is the right tool, and everything above applies.

You want a few values from each of many documents. Fifty invoices, and from each one you want supplier, reference, date and total. Here table extraction is actively the wrong approach: you would get fifty approximations of fifty different layouts and the consolidation work would be untouched. What you want is one sheet, one row per document, under headings you chose — converting multiple PDFs into one spreadsheet is that workflow, and extracting specific fields from PDFs is how to specify the fields.

You want a line table from each of many documents. Both at once: many rows per document, every header field repeated onto each row. This is the hardest shape and it has its own layouts and checks — extracting invoice line items sets them out.

Common questions

Why does the same tool work on one PDF and fail on another? Because it is inferring structure that is not in the file, and how much evidence a table carries varies enormously between documents. Ruled lines are evidence; whitespace is a hint.

My PDF is a scan. Does any of this apply? Not yet. A scan has no text to position, so the characters have to be recognised from the image first — converting scanned PDFs to Excel covers that, and the table problem then applies on top of it.

Can I extract the same table from 200 PDFs at once? You can extract 200 tables, and then you have 200 differently-shaped sheets to reconcile. If the 200 documents are the same kind of document, field extraction gives you one sheet directly.

Should I fix the table in the PDF or in the spreadsheet? The spreadsheet, always. Editing a PDF to help a tool read it is work that has to be repeated for every document.

Is CSV or Excel the better output? Excel if the table contains references with leading zeros, non-US dates or currency, because CSV has no way to say "this column is text". PDF to CSV vs PDF to Excel covers it properly.

The short version

Look at your table first. Ruled, fully populated and on one page means almost anything will work. Whitespace-aligned, ragged and continued across pages means you are going to be checking the output row by row, and the printed total is the check to use.

And if you are extracting tables from fifty documents to get four values from each one, the table was never the thing you wanted.