PaperKit

PDF to Excel

Extract tabular data from a PDF into an XLSX spreadsheet you can actually work with — no retyping.

Drop your file here

Processed server-side: streamed through, never stored

Private: files never leave your device

Extracting tables from a PDF into XLSX gives you cells you can sort, filter and calculate with instead of numbers you would otherwise retype. Table recovery needs a document engine rather than a browser, so this runs on our server: the file is streamed through the converter and the spreadsheet streams back, with nothing stored afterwards — but the file does leave your device, which is worth weighing for confidential financial data. The difficulty of the job is that a PDF table is not a table. It is a set of drawn lines and independently positioned text, with nothing recording which value belongs to which row. The converter infers the grid from alignment and rules, which works well on clean bordered tables and struggles with merged cells, multi-line entries and tables split across pages. Check the output against the original before you rely on it.

Why PDF tables are hard

In a spreadsheet, a cell knows its row and column. In a PDF, a table is lines drawn on a page and numbers placed at coordinates — the grid is something a human perceives, not something the file records.

Reconstruction therefore means inferring structure from geometry: values that share a vertical position are probably a row, values sharing a horizontal band are probably a column, and drawn rules probably indicate boundaries. That inference is reliable on a plain bordered table and progressively less so as the design gets cleverer.

What converts well and what does not

Clean tables with visible borders, one line per cell and consistent alignment convert accurately. Financial statements, price lists and simple data tables are usually close to correct on the first pass.

Merged cells, cells wrapping to several lines, nested headers, tables without ruling lines, and tables continuing across a page break are the recurring failure cases. Numbers can land in the wrong column, and a wrapped cell can become two rows. A scanned PDF, again, has nothing to extract until OCR has been run.

Check before you calculate

The dangerous failure is not the obviously mangled sheet — it is the one that looks right and has a value in the wrong column. Compare row and column totals against the source document before building anything on the data.

Watch the number formatting too: currency symbols, thousands separators and negatives in parentheses sometimes arrive as text rather than numbers, which makes a column silently refuse to sum. Fixing that in the spreadsheet is quick once you know to look.

Frequently asked questions

How are my files handled?

This conversion needs a rendering engine that browsers do not have, so the file is processed on our server: it is streamed through the converter and the result is streamed back — nothing is stored, and files are discarded the moment the response is sent.

Where does the conversion run?

On our server. Table reconstruction needs a document engine that cannot run in a browser, so the file is streamed through the converter and the XLSX streamed back. Nothing is stored, but the file does leave your device.

Why did my numbers land in the wrong columns?

Because the grid has to be inferred from positions and ruling lines rather than read from the file — PDFs do not record cells. Merged cells, multi-line entries and borderless tables are the usual causes. Always check totals against the original.

Can it extract a table that runs across several pages?

It extracts each page, but it does not know the table continues — so a table spanning pages usually arrives as separate blocks with the header repeated. Stitching them together in the spreadsheet is quick once the data is out.

More PDF tools

Advertisement