Excel files: a workbook is a ZIP of XML, and a PDF has no tables at all

The difficulty is entirely on the other side. A PDF has no tables. It has glyph runs with a position each, and the ruled lines you can see are unrelated drawing operations — nothing in the file records that a cell exists, let alone which text belongs to it. So the grid has to be inferred from geometry, which is what every tool that does this really does, including the ones that charge for it.

The inference runs in two steps. Rows come from shared baselines, which is the reliable half because it is how the page was typeset in the first place. Columns come from horizontal extents that overlap, and a band has to recur across several rows before it counts as a column — recurrence is what separates a real column from a paragraph that happens to be indented. Left edges alone do not work, which is worth recording because it is the obvious first implementation and it fails on the most ordinary table there is: a right-aligned quantity column holding 6, 96 and 240 has three different left edges, a digit apart each, so the column splits and every row grows a stray empty cell. Overlap handles left, right and centre alignment without having to know which it is looking at.

What lands in a cell as a number is deliberately conservative: plain, optionally signed decimals and nothing else. 007, 1,234, 2026-09-10, +44 20 and anything carrying a currency symbol stay exactly as they appeared, because a leading zero, a thousands separator and a date are each information that coercion would destroy. Decimal places are kept, so 48.50 arrives as 48.50 rather than 48.5. The limits are stated on the page rather than hidden: merged cells come out in the first column they span, a cell whose text wraps onto two lines becomes two rows, one sheet is produced per page, and a page with no repeating column structure comes back as a single column of lines — which is the honest answer for prose.