Extracting tables from PDF into Markdown
Ask anyone who converts PDFs regularly what breaks most often, and the answer is almost always the same: tables. Headings, paragraphs, and lists convert reliably; tables are the part that needs eyeballing every single time.
This article explains why tables are structurally hard in the PDF format, how modern converters rebuild them into Markdown pipe tables, which table features Markdown cannot express at all, and how to verify a converted table instead of trusting it blindly.
PDF has no tables — that is the whole problem
Word documents, HTML pages, and spreadsheets all have a real table object: rows, columns, cells, spans. The PDF format has none of that. What looks like a table in a PDF is a set of text fragments placed at coordinates, plus optionally a set of drawn lines and rectangles nearby.
That means extracting a table is not retrieval, it is inference. The converter must decide which fragments belong to the same row, which column each belongs to, whether a nearby rule is a cell border or page decoration, and where the table ends and the next paragraph begins.
This is also why the same table can convert perfectly in one PDF and badly in another. The difference is not the table's complexity but how much evidence the document carries: explicit rules and consistent alignment give the detector something to work with, and their absence forces guesswork.
Ruled tables vs whitespace tables
Ruled tables, the ones with visible lines between cells, are the forgiving case. The lines segment the page into regions, each region holds one cell's text, and the structure recognition problem reduces to reading order inside a known grid. Most converters, including the one on this site, handle these well.
Borderless or whitespace-aligned tables are the opposite. With no rules to segment by, the detector clusters text fragments by their coordinates: fragments whose baselines align form a row, fragments whose x-positions cluster form a column. Alignment that is even slightly inconsistent, a cell shifted two points off its column, can ripple into misassigned values.
Financial statements exported from reporting software tend to be ruled and convert cleanly. Tables pasted from decks, tables typeset with only spacing, and tables split across pages with repeated headers are the borderless and fragmented cases where inspection is non-negotiable.
How structure recognition rebuilds the grid
The PDF engine behind this site's converter performs table structure recognition as part of extraction: it detects table regions on the page, segments them into rows and columns, assigns each text fragment to a cell, and emits the result as a GitHub-flavored Markdown pipe table.
That output is the honest, lossy-but-useful common denominator. A pipe table preserves the essential semantics — which value belongs to which row and column header — while discarding visual details like column widths, cell shading, and alignment that Markdown has no way to record.
Recognition quality on public table-extraction benchmarks has improved dramatically in recent years, and engines like this one score far above the naive text-dump approach of copying a PDF and pasting it. But a benchmark score is an average, and your table might be below average. Verification advice follows below, and it exists for a reason.
What arrives in your Markdown
A clean conversion looks exactly like what a human would write: a header row, a separator line, and one row of pipes per data row. Empty cells stay empty, numeric columns keep their values, and the table renders as a proper table on GitHub, in Obsidian, and in every mainstream Markdown renderer.
Surrounding context survives too. The paragraph above the table, the table's caption if it was set as regular text, and the footnotes below it convert as normal content, so the table keeps its context instead of floating unexplained.
What does not survive is any two-dimensional structure beyond rows and columns. Column groups, summary rows that span the table width, and nested sub-headers all get flattened into extra rows or merged into cell text. The data is still there; the shape it took in the original is not.
Merged cells and other GFM limits
GitHub-flavored Markdown pipe tables are deliberately minimal. They have exactly one header row, no cell spans, no row spans, and no alignment beyond per-column left/center/right. Anything richer in the source PDF must be flattened to fit.
A merged cell across three columns becomes text in the first cell and empty cells after it, or text repeated in each. A two-level header becomes a single header row where the levels are joined, sometimes with a separator. Whether that flattening is acceptable depends entirely on what you do next: readable in a document, lossy in a spreadsheet import.
If the destination actually needs the merged structure, the table has outgrown Markdown, not the converter. CSV export from the original source, or a spreadsheet tool's own PDF import, is the better path for that one table — a converter should not be forced to pretend the semantics survived.
Always spot-check the numbers
The failure modes of table conversion are quiet by nature. A shifted column renders as a perfectly ordinary table with one value in the wrong place. A row split by a page break can become two rows. A minus sign read as a hyphen turns a negative into a positive without changing the table's appearance.
So verify proportionally to consequence. For a table in a blog post, glance at it rendered. For a financial or scientific table feeding a report, compare row counts, column sums, and a random sample of cells against the original. For anything feeding a model or a database, this check is part of the pipeline, not an optional step.
The converter helps where it can: pages whose tables look like they need review are flagged in the conversion warnings rather than passed over in silence. Treat those flags as pointers to exactly the rows worth checking first.
Routing tables onward with Pandoc
Once a table is a Markdown pipe table, it is a first-class citizen of the pandoc engine that powers this site's other output formats. Choose HTML output and the table becomes real <table> markup; choose LaTeX and it becomes a tabular; choose RST and it becomes grid syntax.
That second stage is lossless in the sense that pandoc parses the pipe table into a document model before writing, so column alignment and header structure are preserved into every format. What was lost at PDF-to-Markdown time does not come back, but nothing further is lost either.
For most workflows the chain stops at Markdown because that is what the destination speaks. When it does not — a LaTeX paper, a Sphinx site — the conversion path is already there, one dropdown away, running on the same local, private pipeline.