Skip to content

PDF Table to Excel

Extract any table from a PDF into Excel or CSV, with the columns kept in place rather than collapsing when a cell is blank.

Private · on device. Runs in your browser: your file is not uploaded. No sign-up.

Nothing is uploaded, it is read on this device
Your PDF is not uploaded. It is read in this browser tab and never sent anywhere, so a table of invoices, salaries or customer details stays on this device.

A PDF does not contain a table

It contains text at coordinates. The table you see is an arrangement of positions, the rows are text at similar heights, the columns are text at similar horizontal offsets. There is no cell, no row object and no structure recording which is which.

So extracting a table means reconstructing it from geometry, and the quality of a converter is entirely a question of how well it does that.

The empty-cell bug

Here is the failure that produces most bad output. Consider two rows:

Date         Description        Debit     Credit    Balance
01/04/2024   SALARY                       3,500.00  13,500.00
05/04/2024   RENT PAYMENT       1,200.00            12,300.00

The first row has four pieces of text on it; the second has five. A converter reading each row independently, left to right, produces this:

01/04/2024 | SALARY       | 3,500.00 | 13,500.00 |
05/04/2024 | RENT PAYMENT | 1,200.00 | 12,300.00 |

The salary is now filed as a debit. Every figure is a real number in a real column, and the whole row is wrong. Nothing about the output looks broken, which is precisely the problem.

The fix is to find the column positions once, across the whole page, and assign each piece of text to the column it physically sits in, leaving the debit cell empty on the first row rather than pulling the next value into it.

Right-aligned columns need clustering

A further wrinkle: amount columns are right-aligned, so "1,234.56" and "45.00" start at different x positions despite being in the same column. Treating every distinct start as its own column produces a spreadsheet with forty columns and one value in each.

Starts within about fourteen points are therefore treated as one column. That is wide enough to absorb alignment variation and narrow enough not to merge genuinely adjacent columns.

What this cannot recover

Being straightforward about the limits, since they follow from the format rather than from effort.

Multi-line cells. A description wrapping onto a second line becomes a second row. Nothing in the PDF says the two lines belong together.

Merged cells. A header spanning three columns lands in the one it starts in.

Cell borders. Drawn lines are graphics, not structure, and carry no information about the cells.

Scanned tables. No text layer, nothing to extract.

This is why the preview is shown before the download rather than after. Look at it against the original, it takes seconds and is the only check that covers the cases geometry cannot.

For bank statements, use the other tool

If your table is a bank statement, the statement converter does considerably more: it identifies which column is which, normalises the dates to a single format, and then verifies the arithmetic by checking every row's running balance against the row above it. That turns "probably right" into something you can actually rely on, and no amount of careful table extraction gives you the same assurance.

Frequently asked questions

Why do other converters shift my columns?

Because they read each row on its own. A row with an empty cell has one fewer piece of text on it, so a converter counting values left to right files everything after the gap one column early. The result looks plausible, right formats, wrong columns, which is what makes it dangerous. This tool works out the column positions across the whole page first and assigns each value by its position, leaving a gap where a cell is empty.

Will it handle merged cells and multi-line rows?

Partly, and it is worth being clear about the limits. Text wrapping onto a second line within a cell becomes its own row, because there is nothing in the PDF marking the two as belonging together. Merged header cells appear in whichever column they start in. Neither is fixable in general, the information simply is not in the file, so the preview is there for you to check before downloading.

My PDF produced nothing.

It is almost certainly a scan: a photograph of a page has no text to extract. Try selecting a word in your PDF reader, if you cannot highlight individual words, there is no text layer, and no converter can help without OCR. Make it searchable first with the OCR PDF tool, then extract the table from the result.

Is the Excel file real?

Yes, a genuine .xlsx, not a CSV with the extension changed. Amounts such as 1,499.00, 1,25,000.50, (250.00) or ₹ 80 are written as numbers with two decimals, so a SUM works immediately. The table’s own header row becomes the first row, rather than an invented "Column 1, Column 2". Excel does not show a format warning on opening, and long reference numbers are kept as text, not silently converted to scientific notation.

Is my file uploaded?

No. Everything runs in this browser tab and nothing is transmitted. You can verify it by watching the Network tab, or by going offline after the page loads and converting anyway.

Should I use this or the bank statement tool?

Use the statement tool for a bank statement, it identifies the date, description and amount columns, normalises the dates, and verifies the running balance, which is a much stronger guarantee. Use this one for any other table, where there is nothing to interpret and you simply want the grid.