A table in a PDF looks like a table, but it isn't stored as one. The page holds text positioned at coordinates — the rows and columns you can see exist only in your head, and every extraction method is really a guess at where the grid was. That's why copy-paste produces a jumbled column and why one tool nails a file another mangles. There are four practical ways to extract a table from a PDF: copy and paste, Excel's Power Query, a developer library like Tabula or Camelot, and automatic parsing. This guide covers what each one actually does, where each one breaks, and how to pick without trying all four.
Why tables break when they leave a PDF
A PDF stores characters with positions on a page, not cells in a grid. When a PDF is generated, the table structure is thrown away — what remains is "this text at this coordinate", so the borders you see may be drawn lines, or may just be whitespace your eye reads as columns. Extraction tools have to reconstruct the grid by inference: looking for ruling lines, or for vertical gaps that repeat down the page. That reconstruction is why results vary so much between files. A bordered table with consistent columns reconstructs almost perfectly; a borderless one with multi-line cells, merged headers or a wrapped description column is genuinely ambiguous, and different tools resolve the ambiguity differently. Scanned PDFs are a harder case again — there is no text layer at all, only an image, so anything that reads characters directly finds nothing.
Method 1: Copy and paste
Select the table in your PDF reader, copy, and paste into Excel or Google Sheets. It costs nothing, needs no setup, and for a small bordered table it sometimes works on the first try.
It fails on structure. Because the copy carries text and not the grid, values usually land in a single column, and multi-line cells break row alignment so one logical row becomes three. You can recover some of it with Data → Text to Columns when the separator is consistent, but wrapped description fields and right-aligned numbers rarely are. Copy-paste is reasonable for a table you could retype in five minutes. Past that, the clean-up costs more than it saves.
Method 2: Excel Power Query
Excel imports PDFs natively: Data → Get Data → From File → From PDF, then pick the detected table, promote headers, set column types and load. If the layout is stable month to month, the query refreshes against a new file without rebuilding.
Two conditions have to hold. The PDF must be text-based — Power Query has no OCR, so a scan or a photo gives you nothing to import. And the table needs to be reasonably well-formed; irregular layouts, tables split across pages, and multi-line cells usually need manual steps added to the query. Note also that the From PDF connector is a Windows Excel feature, so Mac users skip to another method. Within those limits it is the best free option, and it is genuinely repeatable, which copy-paste is not.
Method 3: Tabula and Camelot
If you write code or don't mind a desktop tool, two open-source projects target this problem directly.
Tabula is a free tool with a simple interface: you draw a box around the table, and it exports to CSV or Excel. It runs on Mac, Windows and Linux, and it's a good fit for a one-off extraction from a document you can inspect by hand.
Camelot is a Python library with two parsing flavors: Lattice, which uses the ruling lines drawn on the page, and Stream, which infers columns from whitespace. Lattice is the more accurate of the two when your table has visible borders; Stream is what you fall back to when it doesn't, at the cost of treating a page as one table, which misreads pages holding several. Camelot's documentation is explicit about the boundary: it "only works with text-based PDFs and not scanned documents."
Both are free and both give you real control. Both also assume you'll iterate — choosing a flavor, adjusting regions, re-running — which is fine for a pipeline you build once and reasonable for a developer, and a poor use of an afternoon if you have twenty statements to process today.
Method 4: Automatic parsing
Automatic parsing runs OCR over the document and then applies a schema: instead of asking "where is the grid", it asks "what fields does this kind of document have". Because it reads the page as an image, it handles scans and phone photos that every method above rejects, and because it knows the document type, it can return a date, a description and an amount as distinct fields rather than as three guesses about column boundaries.
That's what ParseForMe does: upload the PDF, each extracted value carries a confidence score so you review the uncertain ones rather than proofreading everything, then export to Excel, CSV, Google Sheets or QuickBooks. It works the same way for invoices, receipts and the other document types, and there are per-bank walkthroughs for common cases like converting a Chase statement.
The honest trade-offs: it's a paid step beyond small volumes, and it is schema-driven, so it's strongest on recognised document types and least differentiated on an arbitrary table in an arbitrary report. If your PDF is a scan, or you have a stack of them, or the layout changes between files, this is the fastest route to a table you can trust.
Which method fits your PDF
| Method | Handles scans | Repeatable | Setup | Best for | | --- | --- | --- | --- | --- | | Copy and paste | No | No | None | One small bordered table | | Excel Power Query | No | Yes | Moderate, Windows Excel only | Consistent digital PDFs, monthly refresh | | Tabula | No | Partly | Low | A one-off extraction you can supervise | | Camelot | No | Yes | Code required | A pipeline over text PDFs you control | | Automatic parsing | Yes | Yes | None | Scans, volume, or layouts that vary |
The dividing question is usually not accuracy but whether your PDF has a text layer. If it does, and the layout is stable, Power Query or Camelot will do the job for free. If it doesn't — a scan, a photo, a fax — the first four rows of that table are unavailable to you regardless of effort, because there is no text to read. Check by trying to select a word in your PDF reader: if nothing highlights, you have an image.
Getting a clean table out
Whatever you use, the same few habits decide whether the output is usable. Work from the original digital file rather than a printed-and-rescanned copy, since every generation of scanning costs accuracy. Extract to one row per record with values in separate columns — a date column that also contains the description is not a column. Check a known total after extraction: if your source has a sum, a closing balance or a row count, verify it, because a silently dropped row is the failure mode that survives review. Watch multi-line cells, which are the usual cause of misaligned rows, and date formats, which flip between regions without warning.
If the table you're extracting is a financial one, the destination matters as much as the extraction: parsed data can go straight to Excel in your own template, to Google Sheets, or to QuickBooks and Xero rather than being re-keyed. And if it's specifically a bank statement, there's a fuller walkthrough in how to convert a PDF bank statement to Excel.