This reads the text and its position on each page, works out where the columns are, and writes an .xlsx. It works well on simple tables and tells you when it does not.
Free · No sign-up · Files stay on your device
Files are not uploaded - everything happens in your browser.
This is the part worth understanding, because it explains both the successes and the failures. A PDF does not store a table. It stores instructions of the form "draw the characters 1,234.50 at this exact position on the page". There is no row, no column and no cell - only text with coordinates.
So the tool reads every piece of text with its position, groups pieces that sit on the same baseline into lines, and then looks at where lines start. When many lines begin at the same handful of horizontal positions, those positions are the columns. Each piece of text is then assigned to the column it starts in, and each line becomes a row.
That is roughly how a person reads a table too, which is why it works on ordinary tables and struggles on unusual ones. It is a reading of the layout, not an understanding of the data, and the page tells you how confident the reading was rather than leaving you to find out in Excel.
It works well on tables where each row is one line of text and each column starts in the same place on every row: bank statements, invoices, price lists, exam results, timetables, most reports produced by software. These make up the majority of tables people need out of PDFs.
It struggles where a human eye has to do extra work. Cells whose text wraps onto two lines become two rows. Merged cells leave gaps. Two-level headers come out as two separate rows. Columns separated by nothing but alignment, with no consistent left edge, may merge into one. Tables printed side by side on the same page are read as a single wide table.
None of this is fixable by trying harder in a browser; it is the nature of reconstructing structure that was never saved. The honest answer is that the result is a starting point which usually saves most of the typing, and that you should always look at it in Excel before using it.
If your PDF came from a scanner, a photocopier or a phone photograph, it contains pictures of pages and no text at all. There is nothing for this tool to read, and it will tell you so instead of handing you an empty spreadsheet.
The way through is OCR PDF, which recognises the letters in the picture and produces a PDF with a real text layer. Convert that result here and the table extraction has something to work with.
Expect OCR to cost accuracy. Recognised digits are occasionally wrong, and in a table of figures a wrong digit matters, so check the totals against the original. A quick way to test it: add a column in Excel that sums the numbers and compare the result with the total printed on the statement.
A number stored as text is useless in a spreadsheet: it will not sum, average or sort properly. So cells that hold nothing but a number are written as numbers, including ones with thousands separators - 1,234.50 becomes the number 1234.5.
Things that look numeric but are not get left as text on purpose. Percentages keep their sign, account numbers and reference codes with leading zeros stay exactly as printed, and anything longer than fifteen digits is kept as text because converting it would lose precision.
Dates are left as the PDF printed them. Date formats are ambiguous - 05/04/2026 is two different days depending on the country - and guessing wrong in a financial document is worse than leaving a string for you to convert deliberately in Excel.
One sheet per page is the default and keeps each page clearly separate, which helps when you want to check a page against the original.
Everything in one sheet suits a table that runs over many pages, such as a long statement: the rows are stacked in order with a blank row between pages, so a single sort or filter covers the whole document.
If a page carries a header and footer, those lines will appear in the sheet too. They are text on the page, and the tool has no way to know they are furniture rather than data. Deleting a couple of rows in Excel is quicker than any clever rule we could write, and far less likely to delete something you wanted.
Files are not uploaded - everything happens in your browser. That is particularly relevant here, because the documents people convert to Excel are bank statements, payslips and invoices. None of it leaves your device, and there is no server-side copy to worry about.
The PDF reader and the spreadsheet writer are both fetched on demand, once, after you choose a file. Pages are processed one at a time with progress shown, so a long statement does not freeze a phone.
Going the other way, Excel to PDF turns a spreadsheet back into a printable table, also entirely in the browser.
One last practical tip. If the table you need appears on only three pages of a forty-page report, type those three page numbers rather than converting the lot. The conversion is faster, the spreadsheet has nothing in it you did not ask for, and you avoid the headers, footers and paragraphs of surrounding text that would otherwise arrive as stray rows for you to delete by hand.
Choose the PDF, pick the pages with the table, and press Convert. You get an .xlsx file with one sheet per page.
Not directly - a scan holds no text. Run it through OCR PDF first, then convert the searchable result here.
Because the PDF stores positions, not a table. Wrapped cells, merged cells and stacked headers cannot be rebuilt reliably. The page warns you when a layout looked unreliable.
Yes, including ones with thousands separators. Reference codes, percentages and very long digit strings are deliberately kept as text.
Because 05/04/2026 means different days in different countries. Rather than guess, the date is left exactly as printed for you to convert in Excel.
No. The whole conversion runs in your browser; nothing is sent to a server.
Yes. Choose "everything in one sheet" for a table that continues across pages.
Your answer is stored in this browser only. It is not sent to us and no totals are counted.