How to Convert PDF to Excel Free: What Works, What Fails, and Why

Convert PDF tables to Excel spreadsheets in your browser. Learn how automatic column detection actually works, why some tables come out mangled, and when manual copy is faster.

6 min read

Why PDF-to-Excel is harder than it sounds

PDF was designed for viewing, not for editing structured data. When you save a spreadsheet as a PDF, the row-and-column structure is thrown away, the tool that generated the PDF just draws each cell's contents at specific x/y coordinates on the page. There is no "table" object stored in the file. There are just numbers and words scattered at pixel positions that happen to visually align.

Converting PDF to Excel is therefore not a straightforward format conversion. It is a reconstruction problem: given a page full of positioned text, guess where the table boundaries were, guess which text belongs to which cell, and produce a spreadsheet that approximates the original structure.

This is the reason your PDF-to-Excel conversion sometimes comes out perfectly and sometimes turns into a mess.

What the tool actually does

Our PDF-to-Excel converter walks through each page of the input document like this:

Step 1: Extract text with coordinates. Using pdfjs-dist, the tool pulls out every text fragment from the page along with its bounding box (x, y, width, height). A typical page has 200-2000 text fragments after this step.

Step 2: Cluster text into rows. Fragments with the same y coordinate (within a small tolerance for line spacing quirks) belong to the same row. This gives an ordered list of rows.

Step 3: Detect column boundaries. For each row, the tool looks at the horizontal gaps between text fragments. When a gap is significantly wider than the average character width in that row, it marks a column boundary. The set of column boundaries becomes the column structure.

Step 4: Consolidate columns. Column boundaries are aggregated across all rows to find the shared column structure of the table. Rows that don't fit the shared column structure are usually merged header rows, spanning notes, or table titles.

Step 5: Write to a worksheet. Each detected table region becomes a worksheet in the output .xlsx file, produced with the SheetJS library.

The result is your data in Excel, ready to sort, filter, or paste into a report. When it works, it feels like magic. When it doesn't, you'll see why below.

What kinds of tables work well

The heuristics above work well when the source PDF has:

  • Clean column alignment: every cell in a column starts at roughly the same x coordinate. Financial reports and generated reports usually meet this.
  • Consistent row spacing: rows are separated by predictable vertical gaps, not by borders drawn as vector graphics.
  • Text-based content: the PDF has an actual text layer, not just images of a scanned document.
  • No merged cells: every logical cell is a distinct text fragment, not a text fragment that visually spans multiple columns.
  • No nested tables: one table at a time, not a table within a table.

Bank statements, invoice line items, financial disclosures, regulatory filings, and inventory lists tend to convert cleanly because they meet all of these criteria. If your table looks like one of those, expect 90%+ accuracy on the first try.

What kinds of tables fail

Failure modes and what causes them:

Scanned PDFs. The tool relies on the text layer. Scanned PDFs have images of text, not text itself, so extraction returns nothing and the output is an empty spreadsheet. Run OCR on the PDF first to add a text layer, then convert.

Multi-line cells. A cell with a long comment wraps to two lines. The tool interprets those two lines as two rows, which fragments the table structure. Post-processing in Excel is usually needed to re-merge.

Merged cells. A cell that spans two columns (like a group header "Q1 2026" above January/February/March columns) shows up as a single text fragment at the position of the first column. Downstream columns are shifted, and the "Q1 2026" cell claims territory it shouldn't.

Right-aligned numbers next to left-aligned labels. Text fragments have coordinates, but the coordinate is the anchor point, not the visual centre. A right-aligned number's anchor is at its right edge, which can be far from where the human eye sees the "middle" of that column. The tool's column boundary detection can place these numbers in an adjacent column.

Tables with borders drawn as vectors. The visual table borders exist as graphics, not as delimiters the tool can see. Cell boundaries are inferred purely from text positions, which sometimes misses cells that have no text (empty cells), the tool has no way to know they existed.

Multi-column page layouts. A page with a two-column newsletter layout containing an embedded table trips up the column detection because it sees columns everywhere.

When manual conversion beats automated

For small tables (10-20 rows), automated conversion is often more work than manual. You upload, convert, review, fix errors, vs. selecting the text in a PDF viewer, copying, and pasting into Excel. Modern PDF viewers preserve column structure surprisingly well on copy.

For larger tables or repeated workflows, automation wins even with errors, because the fix rate scales linearly while the upfront effort is constant.

For messy PDFs, scanned, multi-column, or full of merged cells - neither automated nor manual is fast. Consider whether the data is actually in a machine-readable form somewhere else (the source system that generated the PDF probably has an export option). If the PDF is truly the only source, budget significant cleanup time regardless of tool.

Getting better results

Some tips that help:

Convert one page at a time. Multi-page conversion aggregates tables across pages, which can concatenate two unrelated tables into one worksheet. Single-page conversion preserves each table's identity.

Pick the right pages. If your PDF has a table on pages 5-8 and narrative text elsewhere, extract only those pages first (using a split tool), then convert. This avoids the tool trying to parse narrative text as columns.

Rotate landscape tables to portrait, or the reverse. If a table was designed as landscape but the PDF was rendered as portrait (with the table sideways), rotate the page first. Text positions in a rotated page are hard to reconstruct.

Post-process in Excel. After conversion, expect to:

  • Delete empty rows or columns
  • Merge cells that were fragmented
  • Format numbers (they come in as text; use Excel's "Text to Columns" or VALUE() function to convert)
  • Fix currency symbols that got stripped

Frequently asked questions

Why is my output Excel file empty?

Two common causes: the PDF is a scanned document with no text layer (run OCR first), or the pages you selected have no detectable tables. Try converting a page you know contains a table by itself first, to verify the tool is picking up text.

Can I convert scanned PDF tables?

Not directly. The tool reads the PDF text layer, which scanned PDFs lack. Run OCR to add a text layer, then convert. OCR of tables is imperfect, expect to clean up misread digits, especially 0/O and 1/l/I confusions.

Why did numbers appear as text after conversion?

Excel imports the data as text because the source PDF stored numbers as strings without type information. Fix in Excel with "Text to Columns" (Data tab, no delimiter, format as Number in Step 3) or use =VALUE(A1) in a helper column.

How does the tool detect where columns start and end?

It looks at horizontal gaps between text fragments in each row. When a gap significantly exceeds the average character width for that row, it marks a column boundary. The full set of boundaries across all rows becomes the column structure.

What about tables that span multiple pages?

The tool treats each page separately by default. If your table continues across pages, you get one worksheet per page. Merging in Excel is straightforward (copy from the second worksheet, paste below the first). Some tools try to auto-continue tables across pages; ours does not, because the heuristic is unreliable when the page break lands mid-row.

Can it handle password-protected PDFs?

Only after decryption. Encrypted PDFs are unreadable until the password is applied. Remove the password first, then convert.