Why this is the hardest conversion there is
The failure mode is the problem. A prose conversion that goes wrong looks wrong. A table conversion that goes wrong looks fine — the numbers are all there, one column to the left of where they belong. Nothing about the output announces it.
What makes a table easy or hard
Every cell drawn with visible lines — most financial statements, most invoices.
PDFnoted: Line positions give the grid directly. Cells are mapped from the intersections, and merged spans are read from the geometry.
Columns implied only by alignment — common in reports exported from design tools.
PDFnoted: Column boundaries are inferred from whitespace and alignment. Usually right, occasionally off by one column, which is exactly why totals need checking.
A long statement continuing across page breaks, often repeating the header row.
PDFnoted: Pages are stitched so rows continue rather than break, and repeated header rows are recognised as headers instead of being inserted as data.
A photocopied or photographed statement — pixels, no text.
PDFnoted: A positional text layer is built first, then the same grid detection runs. Recognition accuracy on digits becomes the limiting factor, not the table detection.
How PDFnoted converts a table
- Check for a text layerScanned input is detected before extraction — there is nothing to map from pixels until OCR has run.
- OCR if neededA positional text layer is built, preserving where each recognised value sits on the page.
- Recover the gridRuling lines where they exist; alignment-based inference where they do not; multi-page tables stitched across breaks.
- Export as .xlsxValues are written into real cells as numbers, dates and currency where they are recognised as such.
Three checks that catch almost everything
Row count matches
The fastest signal. A repeated header inserted as data, or a dropped page, shows up here immediately.
Column count matches
A merged cell that split, or two columns that ran together, changes the count.
Sum one column and compare with the printed total
The single best check. It takes seconds and catches a figure that shifted one column — the error that reading the output will never reveal.
Spot-check dates and long identifiers
Recognition is strongest on words and weakest on long numeric strings. Reference numbers and account numbers deserve a look.
Compared with the usual options
| Copy and paste | Typical online converter | PDFnoted | |
|---|---|---|---|
| Where the file goes | Local | Uploaded to a server | Your browser |
| Ruled tables | Sometimes | Usually | Yes |
| Borderless tables | Manual | Rarely handled | Inferred — verify |
| Multi-page stitching | Manual | Sometimes | Yes |
| Scanned tables | Retype | Empty or image only | OCR first, then mapped |
| Numbers as real numbers | Sometimes | Text strings | Typed where recognised |
Frequently asked questions
Why is PDF to Excel harder than PDF to Word?
Because a table demands precise two-dimensional structure. Prose can survive a wrong paragraph break; a figure in the wrong column is simply a wrong figure. The converter has to recover row and column boundaries — which the PDF never recorded — and then put every value in the right cell.
Why do my numbers end up in the wrong column?
Usually one of three causes: columns that were only implied by alignment rather than drawn with lines, merged or multi-line cells, or a number that OCR misread and pushed into the neighbouring field. Comparing totals is the fastest way to catch all three.
Will merged cells and multi-line cells survive?
Merged cells are usually detected and recreated. Multi-line cells — a long description wrapping over three lines inside one row — are the harder case, because the wrap looks like three separate rows until the row structure is understood. Check any row where a description wrapped.
My table spans several pages. Does it come out as one?
It should. Page-spanning tables are stitched so the header row is not repeated as data and rows are not broken at page boundaries. Confirm the row count against the original — a repeated header silently added to the middle of the data is a common artefact.
The PDF is a scan. What then?
Run OCR first. Without a text layer there is nothing to extract but pixels. PDFnoted detects the missing layer, builds one with positional information, and then maps the table — the same pipeline as a text-based file, with recognition accuracy on top.
Are numbers formatted as numbers?
Values are exported as numbers, dates and currency where they can be recognised as such, rather than as text strings you then have to clean. Thousands separators and decimal commas vary by locale, so check one formatted column before trusting a sum.
How accurate is it?
Good enough that routine tables need no correction, and not good enough to skip verification on anything financial. Treat the output as a draft that is much faster than retyping, and check the totals against the source.
How should I verify the result?
Three checks catch almost everything: compare the row count, compare the column count, and check one total — sum a column in the spreadsheet and compare it with the total printed on the original page. That last one takes seconds and catches a shifted figure that reading would miss.
Try it on your own file
Upload a document and see what comes back. Free to start, nothing to install.
Convert PDF to Excel now — free to startKeep going
Sources and further reading: ISO 32000 (PDF specification); Adobe PDF Reference; Schema.org structured data; Aggarwal et al., GEO: Generative Engine Optimization (arXiv:2311.09735). This page is a technical guide, not legal advice.