← All guides

How to convert a PDF table to CSV

Getting a table out of a PDF into CSV works well when two things are true: the PDF has a text layer (you can select the table text with your cursor), and the table has a reasonably clean structure (clear columns, ideally ruled lines). When both hold, PDFMoka's PDF to CSV converter pulls the table into CSV in your browser without uploading the file. When the PDF is a scan (an image, no selectable text) or the table is borderless and irregular, extraction gets unreliable fast, and this guide is honest about where the line is so you do not waste time. The quick test is the same as for any PDF text task: try to select the table text. If you can, you are in good shape; if you cannot, you have a scan and need OCR first.

The two things that decide whether this works

1. Text layer vs scan. This is the hard gate. A PDF made digitally (exported from Excel, Google Sheets, a database report, LaTeX) has the numbers stored as real text, and a converter reads them directly. A PDF that is a scanned or photographed page is just an image; there is no text to extract, and you need OCR to recognize the characters first. As the Tabula project puts it, if you can click and drag to select the table text in a viewer, your PDF is text-based. PDFMoka reads the text layer and does not do OCR, so for scanned tables it will not help; you would need a Tesseract-based or cloud OCR step first.

2. Table structure. Even with a text layer, not all tables extract equally. This is where PDF table extraction gets genuinely fuzzy, and it is worth understanding the two approaches every tool uses:

  • Ruled tables (lines between cells). When a table has visible borders (vector lines separating rows and columns), extraction is most reliable, the tool traces those lines to find cell boundaries precisely. This is the "lattice" approach.
  • Borderless tables (whitespace only). When columns are separated only by spacing, the tool has to infer column boundaries from alignment and gaps. This is the "stream" approach, and it is inherently more error-prone: closely spaced columns can merge, and ragged alignment can shift values into the wrong column.

So a bordered financial table extracts cleanly; a design-forward invoice that uses only whitespace is the hard case.

The reliable path (text-based PDF)

If your table text is selectable:

  • Browser, no upload: PDFMoka's PDF to CSV converter reads the text layer and outputs CSV, running entirely in your browser so a financial statement or customer list is never uploaded.

  • Python, for scripting or tricky tables: camelot and pdfplumber are the standard libraries, and they let you choose lattice vs stream and tune the detection.

    pip install "camelot-py[base]"
    import camelot
tables = camelot.read_pdf("input.pdf", flavor="lattice")  # or "stream"
tables[0].to_csv("out.csv")
print(tables[0].parsing_report)  # accuracy / whitespace metrics

    Use flavor="lattice" for tables with ruled lines, flavor="stream" for whitespace-separated ones. The parsing_report accuracy metric is useful for spotting bad extractions without eyeballing every table.

verify against current docs: Camelot's install extras and flavor options evolve (newer versions add auto-selection and optional ML/OCR backends). Confirm the current API and install command before relying on the exact syntax. pdfplumber is a good alternative when column boundaries are ambiguous.

The honest failure modes (so you don't fight the wrong battle)

Three situations where any tool, including ours, will struggle, and what to do instead:

  1. Scanned PDFs. No text layer means no text extraction, period. Run OCR (Tesseract locally, or AWS Textract / Google Document AI for complex tables) to build a text layer first, then extract.
  2. Borderless, tightly-packed tables. Whitespace-only tables with narrow gaps between columns frequently merge columns. If a browser tool gives you a messy result, a Python library with tunable stream settings (or manual column separators) is your next step.
  3. Multi-page tables and merged cells. Tables that span several pages, repeat headers each page, or use cells that merge across rows/columns often need cleanup after extraction. Expect to fix these by hand or with a script; do not expect one click to be perfect.

We spell these out because a lot of "PDF to CSV" tools present a clean-looking result even when they have silently merged or dropped columns. For anything you will compute on (finances, inventory), always eyeball the CSV against the original before trusting it.

After extraction: check the CSV

Whatever tool you use, open the CSV and verify against the source: right number of columns, no merged fields, headers intact, numbers not mangled (watch for thousands separators and merged superscripts). For a text-based PDF with a clean table this is a quick sanity check; for a borderless or complex table it is essential.

Quick decision guide

  • Table text is selectable, table is bordered/clean: convert it here, done.
  • Text selectable but borderless/irregular: try the browser tool, and if columns merge, move to camelot/pdfplumber with stream tuning.
  • It's a scan (no selectable text): OCR first, then extract.
  • Need the reverse (CSV into a PDF)? See CSV to PDF.
  • Want plain text, not a table? See extract text from a PDF.

References