Extract Tables from PDF

About Extract Tables from PDF

A PDF has no such thing as a table. It has some line segments and text fragments scattered between them, so table extraction means guessing the cells from the layout. This tool uses two guesses. Ruled tables are rebuilt by following their lines (lattice). Tables aligned with whitespace and no rules are split at the empty vertical channels between text (stream). Auto mode finds lattice tables first, then looks for stream tables in the remaining text — the same two strategies that tools such as Camelot and Tabula use.

Detected tables can be fixed in place — edit a cell, merge or delete rows and columns, add or remove separators — and exported as XLSX (one sheet per table) or CSV.

Lattice: a missing rule means a merged cell

Every straight line, rectangle outline, thin filled rectangle and cell-background edge on the page is collected as a horizontal or vertical segment. Segments within 2 pt of each other are treated as the same line, touching segments are grouped, and each connected group becomes one table. The rules' positions are the row and column boundaries.

If the boundary between two cells is absent along that stretch, the cells are treated as merged and exported as a merged range in Excel. The flip side is tables that omit row rules for style — a line under the header and nothing else. Several rows then collapse into one cell. Switch just that table to stream, or add row separators.

Stream: not mistaking two-column prose for a table

A line whose text chunks are separated by column-sized gaps counts as a multi-cell line. Two or more such lines within 2.6 line-heights of each other form a candidate. The chunks are projected onto the x axis, and every vertical channel that no text ever touches becomes a column boundary.

The most common false positive is two-column body text, so candidates are rejected when the median cell holds more than 40 characters, when a two-column candidate exceeds 25, or when a chunk spans more than 45% of the page in a two-column layout. Fewer than four filled cells is also rejected. The opposite problem is cells whose text wraps onto several lines: each visual line becomes its own row, and you merge them with “merge with row below”.

Tables in scanned PDFs

A scan without a text layer yields nothing. After OCR adds one, there is text, but the rules are still pixels in a picture, not vector lines. Lattice detection therefore cannot work on OCR'd documents; only stream can. On a densely ruled scanned table the column gaps are narrow and columns tend to merge, so adding column separators by hand is usually quickest.

Multi-page tables and export rules

A table on the next page can be appended when it has the same number of columns and either its column boundaries line up within 6 pt or its first row matches the header. A repeated header row on the continuation page is dropped by default.

On export, “1,234”, “(1,234)”, “$1,000” and “−12” become real numbers so Excel can sum them; parentheses are read as accounting negatives. Codes with leading zeros such as “007”, and numbers of 16 or more digits such as card numbers, stay as text: Excel keeps only 15 significant digits and would turn the rest into zeros. CSV follows RFC 4180 with CRLF line ends and a UTF-8 BOM so Excel detects the encoding. Cells starting with =, +, @ or - that are not plain numbers get a leading apostrophe so they cannot run as formulas (CSV injection).

Worked examples

How to use it

1. Add a PDF; tables found on each page are listed.
2. Check the cell boundaries in the preview; switch a table's mode or edit separators if needed.
3. Select tables, choose XLSX or CSV, and download.

Frequently asked questions