Someone sends you a table inside a PDF — a price list, an extract from a report, a statement — and the first thing you want to do is sort it, sum it, or extend it. That's the moment a PDF stops being a document and becomes a container with your data locked inside it. PDFlyHQ's PDF to Excel exists for exactly this: it reads the file in your browser, rebuilds rows and columns into a spreadsheet, and hands you back a working .xlsx — no upload, no account.
This is the data-focused counterpart to pulling a PDF's prose into Word: the goal here isn't editable paragraphs, it's cells — the table structure itself. Here's how the conversion works, and just as importantly, where its honest limits are.
Why tables get trapped in PDFs
PDF is a final-layout format. It records where each piece of text sits on the page — not that these characters form a row, or that that column belongs together, or that this cell was merged in whatever spreadsheet the table was exported from. The table you see is, to the file, an arrangement of positioned text. Recovering it means reconstructing structure the format deliberately flattened.
That's why converting back is always an interpretation, never a perfect reversal — and any tool that promises otherwise is overselling. Knowing that up front makes you a better user of every PDF converter, not just this one: you convert, then you check.
How to convert PDF to Excel
- Open PDF to Excel and drop in your file — up to 100 MB, processed locally in your browser.
- Convert.
- Download the .xlsx and open it in Excel.
There are no options to puzzle over, which is deliberate: the tool reads the text and its position on each page and reconstructs rows and columns as best it can. Your job is the quality check — which is quick once you know what to look for.
What "keeping the table structure" actually means
The output is a standard .xlsx file with one worksheet per PDF page. Each detected row becomes a spreadsheet row, and each column a spreadsheet column. A five-page PDF of tables arrives as a five-worksheet workbook, with the geometry you saw on the page mapped onto the grid you'll work in.
The one-worksheet-per-page detail is worth internalizing before you start totaling: figures that continue across pages land in separate worksheets, so a total that spans pages means consolidating first. It also gives you a natural audit trail — every worksheet corresponds to a page you can flip back to in the original.
The tables that convert cleanly — and the ones that don't
The tool works well on simple, regular tables with clear columns. Rows of data under headers, consistent spacing, one value per cell — that's the sweet spot, and it covers most business tables: price lists, schedules, statements, extracts.
Now the honest limits: merged cells, borderless tables, multi-line cells, and complex layouts may come through imperfectly. That's not a bug unique to this converter — it's the cost of doing the reconstruction entirely in your browser instead of uploading the file to a server that can throw heavier machinery at it. Server-based converters can chase more layout fidelity; the trade-off is that your data leaves your machine. For commercially sensitive tables, a browser-only tool with known limits is a reasonable trade — just budget two minutes to compare the result against the original page.
Scanned tables need OCR first
A scanned PDF contains pictures of pages, not text. There's nothing positioned to read, so there's nothing to extract — converting a scan yields an empty or near-empty worksheet, not a table. The file isn't broken; it's the wrong kind of PDF for this job.
The fix is OCR — optical character recognition — which adds a real text layer on top of the scan. Run an OCR tool first, then convert the result. If you deal with scans regularly, OCR is worth understanding on its own terms; it's the same technology that makes scanned documents searchable.
Setting a table up for a clean conversion
If you control the PDF's origin, or can ask for a better version, the differences that matter are small and knowable. The select-text test tells you the first and most important thing: drag your cursor across the table — if the values highlight as text, the converter has something to read; if the cursor drags a box around an image, you're looking at a screenshot of a table, and no converter can recover data that was never text. (That case needs OCR first, same as a scan.)
Beyond that, the sweet spot is regularity: one header row, consistent column positions, one value per cell, no merged cells. If you're exporting the PDF yourself from a spreadsheet or report writer, simplifying merged headers ("Total Q2" spanning three columns) into repeated plain headers before export buys more accuracy than any conversion setting can. And tables split across many pages convert as separate worksheets — one per page — so a document rebuilt around fewer, longer tables will land as fewer pieces to stitch back together.
Checking the result
Because reconstruction is an interpretation, treat the conversion like data entry by a fast assistant: probably right, worth verifying. Sort a column and watch for values that split across two cells. Pay special attention to numbers that sat in multi-line cells — those are the likeliest to land oddly. And compare each worksheet's row count against its page. Thirty seconds of checking beats emailing a workbook with a silently broken total.
Going the other direction
If you're building rather than recovering — turning a spreadsheet into a PDF to share it — that's the opposite conversion, with its own rules about what survives. And if what you need out of a PDF is prose rather than cells, that's PDF to Word's job: text into an editable document, not data into a grid.