Extracting tables from PDFs to CSV: how position detection works and when it fails

Why table extraction is hard in principle

In a Word document, a table is a first-class object: the file says "this is row 3, cell 2". In a PDF, the same table is a list of draw-operations: put this text here, draw a line there. Two visually identical tables can be stored completely differently by different producers. Extraction therefore cannot rely on structure — it must infer it.

The tool uses the most reliable signal available: text position. Characters that share a vertical band are one row; characters that share a horizontal band are one column. This heuristic — sometimes called position-based or whitespace-based detection — is deterministic and transparent: the same PDF always produces the same output.

Using the tool

1. Upload a PDF that contains tables (up to 100 MB).
2. Choose the output format: CSV or Excel (XLSX).
3. Click Process — rows and columns are detected by position across the document.
4. Download the file and open it in Excel, Google Sheets or any text editor to verify.

The verification step is part of the workflow, not optional politeness: position detection is a heuristic, and its output is a starting point for your spreadsheet work, not a promise of perfect reproduction of the source.

CSV versus Excel output

CSV is universal but structureless — every page's rows flow into the same list. The XLSX option is more useful for multi-page documents because each page becomes its own sheet, letting you fix page 2 without disturbing page 1. The workbook is assembled locally by a tiny built-in module, so choosing Excel output adds no extra download.

Tables that extract well

• Simple grids — one header row, uniform columns, no merged cells: bank statements, price lists, timetables.
• Consistent spacing — rows separated by clear vertical gaps and columns by clear horizontal ones.
• Text-based PDFs — digital documents where real text (not a photo of text) carries the coordinates.

For these documents the output is usually ready to use with minimal cleanup: strip an occasional artifact row, confirm the header landed as the first row, and continue.

Two more details worth knowing before you start. First, empty cells are legitimate output: a row where one column is blank produces an empty field in the CSV or an empty cell in the sheet — that is the detector reporting what the page shows, and most spreadsheets display it the same way. Second, the detection works across the full page width, so side-by-side tables on one page can interleave their rows; the workaround is to crop the PDF to one table's area first, extract, then repeat for the second table.

Tables that need cleanup (honest limits)

• Merged cells — a cell spanning two columns has text at one position and emptiness at another; the row comes out with a gap that you fill manually.
• Nested tables — a table inside a cell confuses the row bands; expect the inner table to appear as extra rows.
• Multi-line cells — an address wrapped over three lines becomes up to three rows; rejoin them in the spreadsheet.
• Scanned tables — there is no text to position. Run OCR first, then extract; results depend on how accurately OCR reconstructed the layout.
• Rotated or landscape tables inside portrait pages — coordinates still work, but column bands may skew.

None of these are bugs — they are the inherent gap between "where text sits" and "what the author meant". The tool reports what it found so you can judge quickly whether the extraction is usable.

A verification and cleanup workflow

1. Extract to Excel (XLSX) so each page is isolated on its own sheet.
2. Compare the first sheet against the PDF page visually — headers aligned? Row count plausible?
3. Fix merged-cell gaps by hand; use spreadsheet filters to spot rows that are obviously artifacts.
4. For page-based documents, repeat per sheet, then consolidate into one master table if needed.

Extracting from multipage documents

Long reports spread one logical table across many pages, or carry many separate tables page after page. The two output formats handle this differently, and picking the right one saves real cleanup time:

• CSV collects every detected row into a single flat file — convenient for scripts and quick inspection, but rows from page 12 sit right under rows from page 11 with no separator, and a table that repeats its header each page produces repeated header rows you delete later.
• Excel (XLSX) gives one sheet per page, which isolates each page's rows for review. You can fix or delete a sheet without disturbing the rest, then consolidate the good sheets into one master table at the end.

For documents you will clean by hand, XLSX is usually the better starting point; for automated pipelines that already expect a flat stream of rows, CSV fits directly.

When commas and quotes break CSV — and how the file handles it

CSV looks trivial but has two classic traps, both worth understanding before you blame the extraction. First, a cell that itself contains a comma — "1,500.00" in a price column — must be wrapped in double quotes, otherwise spreadsheet software reads it as two fields. Second, a cell containing a double quote must escape it by doubling. Well-behaved CSV writers (including this tool) apply both rules automatically, so the output opens correctly; the trap appears only when you later edit the CSV by hand and paste unquoted text into it.

A related detail is the encoding: the output uses UTF-8, which preserves accented characters and non-Latin scripts as they appeared in the PDF. If your downstream script expects a legacy single-byte encoding, convert deliberately rather than letting it guess — silent mis-encoding corrupts names and currency symbols in ways that are easy to miss and hard to trace.

From raw extraction to a clean dataset

Treat extraction as step one of a small pipeline rather than a finished result. In the spreadsheet: promote the first row to real headers, trim whitespace the detector copied from the PDF, merge the fragments of wrapped cells, and delete artifact rows before any analysis. Ten minutes of this cleanup turns a rough extraction into data you can sort, filter and chart with confidence — and doing it once per document beats redoing it every time the report arrives.

For recurring documents, keep the cleanup steps written down. The same producer (same bank, same invoicing system) stores tables the same way every time, so the second extraction needs exactly the same fixes as the first — and if a cleanup step becomes too tedious, that is the moment to check whether one of the dedicated converters (PDF to Excel, or OCR plus extraction for scans) skips it entirely.

Related tools that pair well

• PDF to Excel — the dedicated converter when the whole document is tabular.
• OCR PDF — the prerequisite for scanned tables.
• PDF to Text — plain text extraction when you need content, not structure.