How the conversion works
The PDF is opened in the browser with the pdf.js engine and every text item on the selected pages is read along with its position on the page. Items are then grouped into rows by their vertical coordinate, and within each row a new column begins wherever there is a wide horizontal gap between one item and the next. Rows are padded to a consistent width, blank rows are dropped, and the result is written to a spreadsheet.
The workbook is a real one. It is built with a spreadsheet library and written in the Open XML format Excel actually uses, with the sheet named for the export, so it opens in Excel, Numbers, LibreOffice, and Google Sheets without a warning about the file not matching its extension. CSV output uses proper quoting, so a cell containing a comma, a quote mark, or a newline survives intact.
Everything happens in the tab. The PDF is read into memory, parsed on the main thread, and the finished file is handed to you as a download from an in-memory blob. That matters for the documents people usually convert here: bank statements, invoices, payroll exports, and internal reports that have no business being uploaded to a stranger server.
- Text position drives the row and column inference
- Output is a genuine .xlsx workbook or a properly quoted CSV
- Parsing and assembly both happen locally in the browser tab
When to use XLSX and when to use CSV
Auto mode looks at what it found. If no detected row has content in a second column, the data is really a list rather than a table, and a spreadsheet with one populated column is a worse artifact than a plain CSV. In that case the export switches to CSV and says why, which is more useful than silently producing a workbook that misrepresents the source.
Force XLSX is there for when you know the structure is a table even if the layout confused the detector, typically because columns are close together. Force CSV is there for the opposite case, and for feeding another program that would rather read text than parse a workbook.
Page range selection is the other lever. A fifty page report with the table on pages twelve to fifteen converts far better when you say so, because everything else on those other pages, headers, footers, body paragraphs, would otherwise flow into the same sheet as more rows.
What positional table detection can and cannot do
This is heuristic extraction, and being clear about that saves disappointment. The detector works from coordinates, not from an understanding of the document. It does not read ruling lines or cell borders, it does not identify a header row, it does not handle merged cells, and it puts every selected page into one sheet rather than one sheet per page.
The consequence is predictable. A clean, well-spaced financial table converts almost perfectly. A dense table where columns nearly touch may merge two columns into one cell, because the gap between them was not wide enough to read as a boundary. A table with wrapped text in a cell will split that wrap across two rows, because the second line sits at a different vertical position.
The other hard limit is scanned documents. If a PDF is an image of a page rather than text, there is nothing to extract, and the tool says so plainly instead of returning an empty sheet. Run it through OCR first to produce a text layer, then convert. Password-protected files need the password supplied before the text can be read at all.
- No ruling-line detection, no header detection, no merged cells
- All selected pages flow into a single sheet
- Scan-only PDFs have no text to extract and need OCR first