Is there really no table structure at all in a PDF?

In the vast majority of standard PDF files there genuinely isn't. The file records only which character is drawn at which coordinate on the page and which line runs from where to where. What your eye perceives as a table is a visual impression arising from the combination of neatly aligned text and lines drawn around it. There is one exception: in tagged PDFs produced in line with accessibility rules, table structure is explicitly marked, and extraction from those files is far more accurate. In practice, though, most files you encounter are untagged.

How does the converter guess the cell boundaries?

Two basic clues are used. The first is lines: if there are horizontal and vertical lines drawn on the page, their intersections give the cell grid directly and the result is quite reliable. The second is alignment: when there are no lines, the algorithm looks at whether text fragments on different rows start at similar horizontal positions, and interprets vertically aligned clusters of text as columns. The second method is inherently based on guesswork and can go wrong, particularly with tables that have empty cells or content aligned differently.

Why aren't there any formulas in the table I exported to Excel?

Because formulas are never present in a PDF file. When you save an Excel file as a PDF, the results of the calculations are drawn onto the page, but the formulas that produced those results are never written to the file. A PDF stores only the appearance, not the calculation logic. So after conversion you have the correct numbers, but they're static values. The only way to recover the formulas is to ask the person who produced the document for the original Excel file; conversion cannot regenerate this information because it doesn't exist in the source.

Why do different tools extract the same table differently?

Because the threshold values used to guess cell boundaries differ in every tool. Decisions like how wide the gap between two text fragments must be before they count as separate cells, or how much alignment deviation still counts as the same column, are design choices. These differences aren't noticeable at all with ruled, regular tables, because no guessing is required there. With borderless tables of irregular spacing, however, the same file can give visibly different results in different tools.

Why Are Tables in PDFs So Hard to Extract? The Logic Behind Excel Conversion

The table your eye sees isn't in the file

What do you see when you open a PDF and look at a table inside it? Rows, columns, cells, perhaps borders and a shaded header row. The structure is perfectly clear; at a glance you know which value belongs to which column.

Now let's look inside the same file. A PDF file contains commands of this kind: draw these characters at this point, run a line from here to there, fill this rectangle with light grey. That's all. Nowhere in the file does it say "there's a three-column table here". There's no concept of a cell. There's no concept of a row.

What you perceive as a table is the impression created in your eye by neatly aligned text combined with lines drawn around it. The human brain interprets that pattern as a table instantly; an algorithm has to guess it from scratch.

In this article we explain how that guessing process works, why some tables are extracted flawlessly, and why others fall apart.

How does a converter find a table?

A table extraction algorithm actually solves two separate problems. First it finds the regions on the page that could be tables, then it derives the cell grid for that region. There are two basic strategies for the second step, and which one is available largely determines conversion quality.

The line-based approach

If the table has real borders, the job is fairly easy. The algorithm collects the horizontal and vertical lines on the page, finds their intersection points, and treats the resulting grid as the cell structure. It then assigns the text fragments falling within each cell's boundaries to that cell.

This approach is reliable because there's little guesswork; the lines are explicitly written in the file. Fully bordered, neatly drawn tables are therefore extracted almost flawlessly.

The whitespace-based approach

If the table is borderless, which is very common in modern document design, the algorithm has no lines to work with. In that case the only clue is alignment. The algorithm does this: it looks at the horizontal starting positions of text fragments on different rows and treats those aligned with each other as belonging to the same column. Similarly, it looks at vertical positions to group cells on the same row.

This approach works, but it's fragile. If a cell is empty, the alignment pattern is interrupted. If text in one cell is right-aligned while others are left-aligned, the algorithm may think they're different columns. If text in a cell wraps onto two lines, the second line may be interpreted as a separate table row.

The most common failures and their causes

Understanding why some tables fall apart also shows you what to expect from which documents.

Merged cells. A heading spanning two columns breaks the grid logic. The algorithm has to decide which column that text belongs to, and it generally assigns it to the first, which creates misalignment with the data below.

Multi-line text within a cell. If a long description wraps onto three lines inside a cell, the whitespace-based approach may take it for three separate table rows, throwing it out of alignment with single-line values in the other columns.

Empty cells. An empty cell means no text was drawn at that position. The algorithm may not realise there's a column there, and the values to the right settle one column to the left. This is the most dangerous kind of error, as it silently produces wrong data.

Tables spanning pages. In a PDF each page is independent. If a table continues on the next page, the algorithm treats it as a separate table. Intervening page headers, page numbers, and repeated column headings get mixed into the data.

Nested headings. Two-tier structures with a broad category heading on top and sub-headings beneath can't be translated directly into Excel's flat table model and are generally flattened.

Why don't the formulas come through?

This is what surprises users most, but the reason is extremely simple: formulas aren't in the PDF file at all.

What happens when you save an Excel file as a PDF? Excel first calculates all the formulas, finds the results, and draws those results onto the page. What gets written to the PDF file is the number 1,250; not the SUM formula that produced it. The formula was permanently lost at the moment of saving.

Consequently no converter can extract formulas from a PDF, because there are no formulas to extract. After conversion you have the correct numbers, but they're static values; you have to rebuild the calculation logic yourself. The same logic applies to cell formatting, conditional formatting rules, and data validation settings; all are lost when written to PDF.

This isn't a shortcoming of conversion, it's the nature of the format. If you need the formulas, the only route is to ask the person who produced the document for the original file.

Scanned tables: an extra layer of error

In a scanned document the page is essentially a photograph, and there are no text commands inside to read. With these files, OCR, meaning optical character recognition, has to run first.

OCR carries a particular risk with tables: character confusion in numerical data. Pairs like zero and capital O, the digit one and lowercase l, six and eight, or three and eight are easily misrecognised in low-resolution scans. In a text document such an error is spotted immediately because the word becomes nonsense. In a table, 63 appearing instead of 68 doesn't stand out at all, and it enters your calculations silently and incorrectly.

That's why checking the output with scanned tables isn't an optional step. If there's a total row in the original, taking the same total in Excel and comparing is the fastest and most effective verification method.

Which tables export cleanly?

Let's turn this knowledge into a practical map of expectations. Tables with the following characteristics export almost completely: fully bordered, with a single line of text in each cell, containing no merged cells, fitting on a single page, and text-based. Bank statements, simple price lists, and plain data dumps generally fall into this category.

These characteristics, on the other hand, require correction: borderless tables aligned only with whitespace, multi-line cells, nested headings, long tables spanning pages, and scanned documents. With such files, treating conversion as a starting point is still far faster than manual entry; but you shouldn't use the result without verifying it. To see what comes out of your own file, you can try the PDF to Excel tool.

In summary

Table structure is usually not stored in PDF files at all; there are only text coordinates and lines. Converters derive the cell grid either by reading the lines or by guessing from alignment patterns. With ruled, regular tables the result is reliable; with borderless tables, merged cells, or tables spanning pages the guesswork grows and correction is needed. Formulas never come through under any circumstances, because they were never written to the PDF. And with scanned tables, OCR adds a separate layer of error, making numerical verification mandatory.