Why does table extraction work on some PDFs but fail badly on others?

Because a PDF stores text as positioned characters, not as a table with rows and columns — the "table" you see is an illusion created by where the characters happen to sit. A simple, fully-ruled table on a single-column page is easy: the lines mark the cell boundaries and a tool can reconstruct the grid reliably. The trouble starts with complexity. A two-column page layout makes a naive extractor read straight across both columns and interleave unrelated text. A table with no borders gives the tool nothing to latch onto. Merged cells, multi-line cells, and tables continued across pages all break the assumption that one visual row equals one data row. So extraction does not "fail randomly" — it fails in predictable ways tied to specific layout features, and once you can name the feature, you can pick the technique that handles it.

What is the difference between lattice and stream table extraction?

They are two strategies for finding cell boundaries, suited to different tables. Lattice (line-based) detection uses the ruling lines drawn in the table — the borders between cells — to reconstruct the grid; it is accurate and reliable when the table actually has visible lines around its cells. Stream (whitespace-based) detection has no lines to use, so it infers columns from the alignment and gaps between text — the runs of whitespace that separate one column from the next; it is what you need for tables that use spacing instead of borders. The practical rule: try lattice first if the table has clear ruling lines, switch to stream if it is borderless, and expect borderless tables to need more manual checking because whitespace is a softer signal than a drawn line.

How do I handle a multi-column page layout (like a journal or report)?

Treat each column as a separate region rather than letting the tool read across the whole page width. On a two-column page, an extractor that scans left to right across the full width will splice the first line of column one to the first line of column two, producing scrambled nonsense. The fix is to tell the tool the column boundaries — define the left column as one region and the right as another — and extract them independently, then concatenate in the correct reading order (all of the left column, then all of the right). Most serious extraction tools let you specify regions or detect columns; if yours does not, split the page visually first. Getting reading order right is the single biggest win on multi-column layouts.

How do I deal with merged cells and multi-line cells?

These are the two failure modes that quietly corrupt your data, so handle them deliberately. A merged cell — one value spanning several rows or columns — usually extracts into just one of the positions it spans, leaving the others blank; the fix is to fill the value forward or down into the cells it logically covers, then check it against the source. A multi-line cell — where one cell’s content wraps onto several visual lines — often extracts as several separate rows; the fix is to detect the wrapped continuation lines and re-join them into the single cell they belong to. Both fixes are mechanical once you spot them, but neither happens automatically, which is why a complex table always needs a validation pass before you trust the output.

How do I know the extracted data is correct?

Validate structurally and numerically before you use it. Structurally, check that the number of rows and columns matches the source table, and that no header row has slipped into the data (common when a table spans pages and its header repeats). Numerically, re-compute a column total or two and compare them to the printed totals in the original; if they match, your alignment is almost certainly right, and if they do not, you have a merged-cell or shifted-column problem to find. Finally, spot-check a handful of cells — especially around merged cells, the bottom of pages, and anything that looked tricky — against the PDF. Never feed complex-table extraction straight into analysis: one shifted column can invalidate everything downstream, and the check takes minutes.

Is it safe to extract tables from a confidential PDF online?

Only if the extraction runs on your own device. Complex tables often live in exactly the documents you must protect — financial statements, clinical data, internal reports — and many online extraction tools upload your file to a third-party server to process it. Client-side (in-browser) tools do the extraction locally so the file never leaves your computer — ScoutMyTool’s PDF tools work this way. For confidential or regulated data, confirm a tool is client-side before uploading, or use offline software. Data-protection obligations follow the data out of the PDF and into your spreadsheet, so the source file deserves the same care as the analysis you build from it.

7 min read

How to extract data tables from complex PDFs

By ScoutMyTool Editorial Team · Last updated: 2026-05-21

The first table I tried to pull out of a PDF was a clean, ruled grid and it extracted perfectly — so I assumed the problem was solved. Then came a two-column research report with borderless tables, merged header cells, and rows that continued across three pages, and my tidy little workflow produced scrambled garbage. That gap, between the easy table and the complex one, is where most people lose hours. The reason is that a PDF does not actually store a table; it stores characters at positions, and the table is something we infer from where they sit. This guide is about the hard cases — multi-column layouts, missing borders, merged and multi-line cells, page-split tables, and scans — and how to get clean, trustworthy data out of each, then prove it is right.

The hard cases — and how to handle each

Challenge	What breaks	Approach
Multi-column page layout	Extractor reads straight across, interleaving columns	Define column regions; extract each, in reading order
No ruling lines (whitespace only)	Tool cannot find cell boundaries	Use stream/whitespace detection, not line detection
Ruled tables with clear borders	Usually fine — the easy case	Use lattice/line detection for clean cells
Merged or spanning cells	Values land in the wrong row or column	Fill-down/forward, then verify against the source
Multi-line cells	One cell splits into several rows	Re-join wrapped lines within a cell after extraction
Table split across pages	Repeated headers become data rows	Drop repeated headers; concatenate the page fragments
Scanned (image) table	No text exists to extract	OCR with table mode first, then extract and validate

Step by step — extract a complex table cleanly

Check for real text first. If you cannot select the table’s text, it is a scan — run OCR in table mode to create a text layer before any extraction, and review it for misread digits.
Fix reading order on multi-column pages. Define each column as its own region and extract them separately, then concatenate in reading order — never let the tool read across the full page width.
Pick lattice or stream. Use line-based (lattice) detection for tables with visible borders, and whitespace-based (stream) detection for borderless tables that rely on spacing.
Repair merged and multi-line cells. Fill spanning-cell values forward or down into the positions they cover, and re-join wrapped continuation lines back into their single cell.
Stitch page-split tables. Drop the header rows that repeat at the top of each page, then concatenate the per-page fragments into one continuous table.
Validate before you trust it. Check row/column counts against the source, re-compute a column total and compare to the printed total, and spot-check tricky cells. Only then export to CSV and use it.

The principle that ties it together

Every technique here comes back to one idea: a PDF table is a reconstruction, not a retrieval, so your job is to give the tool the right hints and then check its work. Name the feature that makes a table hard — columns, missing borders, merges, wrapping, page splits, or a scan — and the matching technique follows directly. What never changes is the validation step. Complex extraction is exactly where a single shifted column or a stray repeated header slips through, and because the output looks like a clean spreadsheet, the error is invisible until it has already corrupted your analysis. Reconciling one total against the source takes minutes and catches almost all of it. Treat extraction as "reconstruct, then verify," and even the ugliest multi-column, merged-cell, page-spanning monster becomes reliable data.

FAQ

Why does table extraction work on some PDFs but fail badly on others?: Because a PDF stores text as positioned characters, not as a table with rows and columns — the "table" you see is an illusion created by where the characters happen to sit. A simple, fully-ruled table on a single-column page is easy: the lines mark the cell boundaries and a tool can reconstruct the grid reliably. The trouble starts with complexity. A two-column page layout makes a naive extractor read straight across both columns and interleave unrelated text. A table with no borders gives the tool nothing to latch onto. Merged cells, multi-line cells, and tables continued across pages all break the assumption that one visual row equals one data row. So extraction does not "fail randomly" — it fails in predictable ways tied to specific layout features, and once you can name the feature, you can pick the technique that handles it.
What is the difference between lattice and stream table extraction?: They are two strategies for finding cell boundaries, suited to different tables. Lattice (line-based) detection uses the ruling lines drawn in the table — the borders between cells — to reconstruct the grid; it is accurate and reliable when the table actually has visible lines around its cells. Stream (whitespace-based) detection has no lines to use, so it infers columns from the alignment and gaps between text — the runs of whitespace that separate one column from the next; it is what you need for tables that use spacing instead of borders. The practical rule: try lattice first if the table has clear ruling lines, switch to stream if it is borderless, and expect borderless tables to need more manual checking because whitespace is a softer signal than a drawn line.
How do I handle a multi-column page layout (like a journal or report)?: Treat each column as a separate region rather than letting the tool read across the whole page width. On a two-column page, an extractor that scans left to right across the full width will splice the first line of column one to the first line of column two, producing scrambled nonsense. The fix is to tell the tool the column boundaries — define the left column as one region and the right as another — and extract them independently, then concatenate in the correct reading order (all of the left column, then all of the right). Most serious extraction tools let you specify regions or detect columns; if yours does not, split the page visually first. Getting reading order right is the single biggest win on multi-column layouts.
How do I deal with merged cells and multi-line cells?: These are the two failure modes that quietly corrupt your data, so handle them deliberately. A merged cell — one value spanning several rows or columns — usually extracts into just one of the positions it spans, leaving the others blank; the fix is to fill the value forward or down into the cells it logically covers, then check it against the source. A multi-line cell — where one cell’s content wraps onto several visual lines — often extracts as several separate rows; the fix is to detect the wrapped continuation lines and re-join them into the single cell they belong to. Both fixes are mechanical once you spot them, but neither happens automatically, which is why a complex table always needs a validation pass before you trust the output.
How do I know the extracted data is correct?: Validate structurally and numerically before you use it. Structurally, check that the number of rows and columns matches the source table, and that no header row has slipped into the data (common when a table spans pages and its header repeats). Numerically, re-compute a column total or two and compare them to the printed totals in the original; if they match, your alignment is almost certainly right, and if they do not, you have a merged-cell or shifted-column problem to find. Finally, spot-check a handful of cells — especially around merged cells, the bottom of pages, and anything that looked tricky — against the PDF. Never feed complex-table extraction straight into analysis: one shifted column can invalidate everything downstream, and the check takes minutes.
Is it safe to extract tables from a confidential PDF online?: Only if the extraction runs on your own device. Complex tables often live in exactly the documents you must protect — financial statements, clinical data, internal reports — and many online extraction tools upload your file to a third-party server to process it. Client-side (in-browser) tools do the extraction locally so the file never leaves your computer — ScoutMyTool’s PDF tools work this way. For confidential or regulated data, confirm a tool is client-side before uploading, or use offline software. Data-protection obligations follow the data out of the PDF and into your spreadsheet, so the source file deserves the same care as the analysis you build from it.

Citations

Pull tables out of a PDF in your browser

ScoutMyTool’s PDF table tools extract tabular data to CSV client-side, so a confidential report never leaves your computer — then run the validation pass before you trust the numbers.

Open the PDF text/table tool →