PDF to CSV Converter
Pull a table out of a PDF and into a spreadsheet. A PDF has no columns, only text at coordinates, so this works out where the columns are from the positions themselves and rebuilds the table from that. Nothing is uploaded.
- Nothing uploaded
- Works with no signal
- No sign up
- Reads the text layer
Nothing loaded yet.
What was found
Load a PDF to see the table it contains.
Values are quoted properly, so a cell containing a comma, a quotation mark or a line break survives opening in a spreadsheet.
Your PDF never leaves this device.The file is opened and read by your browser, the table is worked out here in the page, and the download comes from your own machine. That matters for this one in particular, because the tables people extract are usually full of prices, readings or names.
Columns worked out from positions
A PDF holds no column information at all. A column is inferred from an x position that many rows start a run at, and a stray annotation is correctly ignored.
How to use this tool
Drop a PDF on the box at the top. Every page is read, the columns are worked out, and the table appears so you can check it before downloading anything.
If the columns look wrong, the two settings underneath are the ones to reach for. They are explained below, and they fix almost everything.
The CSV that comes out is quoted properly, so it opens cleanly in a spreadsheet even when values contain commas.
A PDF has no columns
This is the thing that makes extracting a table genuinely hard, and it surprises people.
When you look at a PDF table you see ruled columns and neat alignment. None of that is structure. The file contains runs of text, each with a position, and the columns exist only because those positions happen to line up. There is no list of columns anywhere in the file to read, and often no lines either: the alignment is the entire structure.
So the columns have to be inferred. Every run in every row contributes its starting position, positions within a few points of each other are treated as the same position, and a position that many rows begin a run at is a column. A position only one or two rows use is not a column, it is a stray label or a footnote.
That last rule is what separates a table from prose. In a paragraph, every line starts at the left margin and nowhere else, so exactly one position is popular and the page is correctly reported as having no table.
The two settings that fix almost everything
The tolerance decides how far apart two positions can be and still count as the same column. Real documents drift by a point or two, so some tolerance is essential.
If a single column is coming out split in two, the tolerance is too tight: raise it. If two genuine columns are being merged into one, it is too loose: lower it. Those two symptoms and their two fixes cover most of what goes wrong.
The second setting is how many rows a position must appear in before it counts. A column that is usually blank, a remarks field filled in three times out of forty, will be missed at the default. Requiring it in fewer rows picks it up, at the cost of occasionally promoting a stray label into a column of its own.
When a column is not recognised, its values are not thrown away. They are appended to the cell on their left, so you get a slightly wrong table rather than a table missing data. That is a deliberate choice: merging is recoverable, dropping is not.
A worked check you can repeat
Take a four column monitoring table whose columns begin at 50, 150, 260 and 380 points from the left edge.
Every row contributes four starting positions. Each one clusters with the same position on every other row, so four clusters form, each supported by every row in the table. All four clear the threshold and four columns are found, at exactly those coordinates.
Now add a single note at position 500 on one row. It forms a cluster of its own supported by one row out of five, which is below the threshold, so it is not promoted to a column and its text joins the last real column instead. That is the behaviour you want: one stray annotation should not add a column to a forty row table.
The detection was checked against an independent implementation before publishing: thirty five hand written cases covering clean tables, positions drifting by a point or two, stray runs, prose with only one popular position, cells missing from the middle of a row, and two runs landing inside one column. Then twenty thousand generated tables confirming that the extraction never crashes and that the CSV always parses back to exactly the table that was written.
One further check ran across fifty nine thousand generated tables asking a single question: did any source text disappear entirely? It never did. The encoder was also verified to be the exact inverse of the parser used by the CSV to PDF converter on this site, so a table containing commas, quotation marks and line breaks survives a trip through both unchanged.
Mistakes that catch people out
Expecting a scan to work. There is no text in a scanned page, only a picture of one, so there are no positions to cluster. Optical character recognition first.
Expecting merged cells to survive. A cell spanning two columns has one position, so it lands in one column. Nothing can recover the span from coordinates alone.
Extracting a whole report at once. Pages of prose are correctly skipped, but if different pages hold different tables they will be stacked together. Extract a page range at a time.
Trusting it without looking. The table is shown before you download for a reason. Check the columns line up with what you expected.
Right aligned numbers. A column of numbers aligned on the right has a different starting position on every row, which clusters poorly. A looser tolerance usually recovers it.
Common questions
Is my PDF uploaded anywhere?
No. The file is opened and read by your own browser and the table is worked out here on the page. That matters for this one in particular, because extracted tables are usually full of prices, readings or names.
How does it know where the columns are?
It looks at where the text sits. A PDF has no columns, only runs of text at coordinates, so a column is inferred from an x position that many rows start a run at. Positions that only one or two rows use are not columns.
A column is being split in two. What do I change?
Raise the tolerance. Two positions a few points apart are being treated as separate columns when they are really one, and a looser tolerance merges them.
Two columns are being merged into one. What then?
Lower the tolerance. It is currently wide enough to swallow both positions into a single cluster.
It says no table was found.
Then the text does not line up into columns, which normally means the page is prose. If it genuinely is a table, try a looser tolerance or require a column in fewer rows.
Will a comma inside a value break the CSV?
No. Any value containing the separator, a quotation mark or a line break is quoted properly, so it survives opening in a spreadsheet intact.
Related PDF tools and reference
Reference: RFC 4180, the specification describing the CSV quoting used here.