Why does whole-page OCR mangle table structure?

OCR engines like Tesseract read text in lines and paragraphs; a table is neither. The engine returns the recognized text in roughly visual reading order but loses the grid. To preserve structure, you have to segment the page into cell rectangles first and OCR each rectangle independently. The output is then assembled by row and column, not by text flow.

How do I detect cells in a bordered table?

Use morphological line detection — open the binarized image with horizontal and vertical kernels, intersect to find cell corners, then compute cell rectangles between corners. OpenCV plus 30 lines of Python handles most lattice tables. Camelot wraps this pipeline; for one-off use, Camelot is faster than rolling your own.

What about borderless tables?

Detect columns from whitespace gaps in the page image — vertical bands of background pixels separate columns. Detect rows from horizontal gaps. Less reliable than lattice detection; usually requires a column-position hint from a human (or sampling the page to detect consistent column starts).

My OCR mangles digits — 0 vs O, 5 vs S. Fix?

Pass the per-cell crop to OCR with a digit-only character whitelist when you know the cell is numeric (a header tells you). Tesseract supports -c tessedit_char_whitelist=0123456789.,- to constrain. Per-column whitelists raise accuracy a lot on numeric tables.

How do I validate the cell assembly is correct?

Count rows and columns from your detection step, then compare to the source page count (visually or against a known schema). Discrepancies usually mean cell-detection failure — merged cells treated as one, or a column boundary missed. Fix the detection step; do not patch the output CSV by hand because the next page will fail the same way.

Will high-DPI scanning help?

Yes, up to a point — 300 DPI is the OCR sweet spot. Below 200 DPI, recognition accuracy drops fast; above 400 DPI, processing time grows but accuracy plateaus. For scanned tables, scan at 300 DPI grayscale; binarize at the preprocess step rather than scanning bitonal.

How to extract OCR text from PDF table cells

By ScoutMyTool Editorial Team · Last updated: 2026-05-28

I spent an evening trying to get Tesseract to read a financial table from a scanned PDF and the output was a stream of numbers with no row or column structure. The breakthrough was switching from whole-page OCR to a two-pass approach: detect cell rectangles first, then OCR each cell independently with a column-aware character whitelist. The result is a CSV that matches the visual table. Here is the working pipeline — binarize, deskew, detect cell rectangles, OCR per cell, assemble — with the validation step that catches mis-segmented cells before they reach downstream analysis.

Vocabulary, quickly

Term	Meaning
Cell detection	Identifying cell rectangles from the page image
Per-cell OCR	Running OCR on each detected cell rather than the whole page
Lattice	Bordered table where lines define cell boundaries
Stream	Borderless table where whitespace separates columns
Binarization	Image preprocess converting page to high-contrast black/white
Deskew	Rotation correction for scanned pages that were not square on the bed
Confidence score	OCR engine's certainty about each recognized character

Step by step

Render the PDF page to image at 300 DPI. pdftoppm or pdf2image. 300 DPI is the OCR sweet spot.
Binarize and deskew. OpenCV adaptive threshold for binarization; Hough transform or similar for deskew.
Detect cell rectangles. Morphological line detection for lattice tables; whitespace-gap analysis for stream tables.
OCR each cell crop. Tesseract per cell; pass column-aware character whitelist when the cell is numeric.
Assemble by row and column. The detection step ordered cells; preserve that order in the output CSV.
Validate row and column counts. Compare to source page; gaps usually mean a missed cell border.
Spot-check ten cells at random. Compare OCR output to the visible cell content; tune the preprocess pipeline if accuracy is poor.
Persist with provenance. Save the source PDF, the rendered page image, the detected cell rectangles, and the OCR CSV together. Re-running is straightforward if you keep the inputs.

OCR table-extract checklist

Source rendered at 300 DPI; lower DPI hurts accuracy substantially.
Binarization and deskew applied; tables on slanted scans recognize poorly without deskew.
Numeric columns use a digit-only character whitelist.
Row and column counts match the visible table; mismatches indicate detection failure.
OCR confidence scores logged per cell; cells under 60% confidence flagged for human review.
Pipeline inputs (PDF, image, cell rectangles, CSV) archived together for reproducible re-run.

Common pitfalls in OCR table extraction

Skipping the binarize step — color or grayscale scans produce noisier OCR; the threshold pass is cheap and improves accuracy meaningfully.
Treating every page as the same shape — a multi-page report often has different table widths per page; detect per page rather than reusing one bounding box.
Trusting OCR confidence alone — a confident wrong character (8 read as B) still passes; spot-check with a sample of human review.
OCR running before deskew — even a 2-degree rotation drops accuracy substantially; deskew first.
Single-language model on multilingual pages — pass the right language pack(s) to Tesseract; default English on a French page is poor.
Output CSV without provenance — anyone re-running has to rediscover preprocessing parameters; save the pipeline alongside the output.
Numeric columns parsed as strings downstream — emit numeric values and use a downstream type-cast, not a string-to-number conversion that loses leading zeros or thousand-separators.

FAQ

Why does whole-page OCR mangle table structure?: OCR engines like Tesseract read text in lines and paragraphs; a table is neither. The engine returns the recognized text in roughly visual reading order but loses the grid. To preserve structure, you have to segment the page into cell rectangles first and OCR each rectangle independently. The output is then assembled by row and column, not by text flow.
How do I detect cells in a bordered table?: Use morphological line detection — open the binarized image with horizontal and vertical kernels, intersect to find cell corners, then compute cell rectangles between corners. OpenCV plus 30 lines of Python handles most lattice tables. Camelot wraps this pipeline; for one-off use, Camelot is faster than rolling your own.
What about borderless tables?: Detect columns from whitespace gaps in the page image — vertical bands of background pixels separate columns. Detect rows from horizontal gaps. Less reliable than lattice detection; usually requires a column-position hint from a human (or sampling the page to detect consistent column starts).
My OCR mangles digits — 0 vs O, 5 vs S. Fix?: Pass the per-cell crop to OCR with a digit-only character whitelist when you know the cell is numeric (a header tells you). Tesseract supports -c tessedit_char_whitelist=0123456789.,- to constrain. Per-column whitelists raise accuracy a lot on numeric tables.
How do I validate the cell assembly is correct?: Count rows and columns from your detection step, then compare to the source page count (visually or against a known schema). Discrepancies usually mean cell-detection failure — merged cells treated as one, or a column boundary missed. Fix the detection step; do not patch the output CSV by hand because the next page will fail the same way.
Will high-DPI scanning help?: Yes, up to a point — 300 DPI is the OCR sweet spot. Below 200 DPI, recognition accuracy drops fast; above 400 DPI, processing time grows but accuracy plateaus. For scanned tables, scan at 300 DPI grayscale; binarize at the preprocess step rather than scanning bitonal.

Citations

Wikipedia — “Optical character recognition — pipeline and accuracy.” en.wikipedia.org/wiki/Optical_character_recognition
Wikipedia — “Tesseract (software) — engines and modes.” en.wikipedia.org/wiki/Tesseract_(software)
Wikipedia — “Image binarization — preprocessing.” en.wikipedia.org/wiki/Image_thresholding

OCR PDF tables in your browser

Detect cells, OCR per cell with per-column rules, assemble CSV — ScoutMyTool runs the whole pipeline locally so scanned tables never leave your machine.

Open the PDF toolkit →