PDF to Excel converter with a grid you can check

There are two different reasons and the tool tells them apart. If the PDF has no text layer (the pages are saved as pictures) there is nothing to read — those pages are flagged and need recognition first. If there is text but no structure, the lines run as a single column, which is prose rather than a table. The tool deliberately refuses to pass a one-column list off as a table: a sheet full of that noise is worse than an honest "none found".

Correct it in the grid, at the place the detector got wrong. Every column head carries a "⋯" menu: merge with the next, split at the widest gap, delete, set the type. Clicking a row number deletes the row. These operations used to work only on the LAST columns — on a nine-column invoice with a mistake in the middle they were useless while looking as though they worked.

Because in a real table the left edges do not line up. In our own test invoice the middle column starts at 143, 155 and 152 and the right one at 198, 184 and 184: numbers right-aligned, headers left-aligned. Left-edge clustering with any tolerance either splits one column into three or merges three into one. What is stable is the empty corridor BETWEEN columns, and that is what the parsing uses.

A PDF holds no formulas at all — only the already-calculated result — so values are what carry over. Merged cells do carry over: text that materially covers several columns is treated as merged, its value stays in the first of them, the grid shows that cell stretched and highlighted, and the .xlsx gets a real merge. Until this, such text silently landed in whichever column its midpoint fell into — A or B depending on the length of the words, with no way to predict it.

XLSX puts every table found into one workbook, a sheet per table, carrying cell types and merges. CSV knows no types — but it opens anywhere, and it now exports ALL the tables too, one file per table: a single table arrives as a single file, several as a folder or an archive. Every file carries an encoding mark, without which Excel reads Cyrillic as gibberish.

The PDF is parsed in your browser: pdf.js reads the pages, and the workbook is assembled by the same XLSX generator used in our Access database recovery tool, verified part by part against Microsoft’s own engine.

It is handled here. Pages with no text layer are flagged and a "Recognise the pages" button appears: the PP-OCRv5 model downloads once (about 12 MB), runs on your device and needs no network afterwards. The recognised text goes into the same table search as an ordinary PDF — there is no second pipeline. One difference remains: a scan has no drawn rules, so its columns come from the gaps alone, and the note under the grid says so.

Yes. Each column is given a type — number, date or text — and values go into the workbook rather than strings, so totals add up and dates sort. The type is decided from the column as a whole (one dash among the amounts does not turn the column into text) and shown in its head, where you can also override it. The parsing is deliberately careful: "+7 999 123 45 67" stays text, because turning a phone number into a number is a loss you cannot spot in a finished sheet.