Some documents are mostly prose with a table buried in the middle; some are nothing but tables. Either way, the table is usually the part you need — and it's the part that's hardest to get out. The Docyield table extractor finds the tables in a PDF or image and returns just them, rebuilt as clean rows and columns you can open in Excel or load as CSV, without dragging along the surrounding text.
Tables are deceptively fragile data. On the page they look like a grid, but a PDF only knows the position of each character and an image knows only pixels — neither stores the rows and columns that make a table a table. That's why selecting a table and pasting it almost never works. The extractor's job is to recover that lost structure: detect where the table is, find its column and row boundaries, and reassemble the cells in the right order.
Finding and rebuilding the table
When you upload a file, Docyield reads it — from a native PDF's text layer, or via OCR for a scan or image — and then isolates the tabular regions from everything around them. It detects the column edges, groups characters into cells, and orders the cells into rows, so what comes back is the table on its own rather than the whole page flattened into text.
This works even when the table has no ruled lines. Many tables are held together only by alignment and whitespace, which defeats tools that look for borders. By reasoning about how the content lines up, the extractor recovers the grid whether or not the table was drawn with visible gridlines.
Why a dedicated extractor beats general extraction
A general text extractor reads the entire page, so the table arrives tangled up with headings, paragraphs, and footnotes that you then have to strip out. Worse, reading in raw position order can interleave a table's cells with nearby prose, leaving you to reconstruct rows by hand.
Targeting the table directly avoids both problems. You get only the rows and columns, already aligned, with the narrative text left behind. That's the difference between data you can drop into a pivot table immediately and a wall of text you have to comb through first.
What makes table structure so slippery
Tables look orderly to us, but the orderliness lives entirely in our visual perception, not in the file. A PDF stores each figure at a coordinate with no note of which row or column it belongs to; an image stores only pixels. The grid we see is implied by alignment and spacing, so recovering it means inferring boundaries that were never recorded — deciding, from the way values line up, where one column stops and the next starts.
That is why small irregularities cause outsized trouble. A number that is slightly wider than its neighbours, a column with a few blank cells, or a header that straddles two columns can all blur the boundary a naive tool relies on, and once one boundary is wrong every value after it shifts. Docyield reasons about the whole region's alignment rather than a single row, which is what lets it hold the grid together through the irregularities that defeat simpler approaches.
Who extracts tables
- Analysts lifting figures from reports, filings, and research papers into a working sheet.
- Finance teams pulling transaction tables out of statements for reconciliation.
- Procurement and sales staff extracting price lists and rate cards from supplier PDFs.
- Scientists and researchers capturing tabulated results from published documents.
- Anyone who needs just the table from a document, not the prose around it.
Accuracy and the inputs that help
Results depend on the source. A digital PDF with selectable text gives near-perfect column detection; a clear scan or photo works well; a blurry, dim, or skewed image is harder because OCR must recover the characters before the grid can be rebuilt. A sharp, straight-on capture is the single biggest factor in a clean extraction.
The extractor doesn't fill empty cells with guesses — a blank in the source stays blank — and the layouts most worth a quick review are the genuinely ambiguous ones: borderless tables, heavily merged cells, or cells wrapping across several visual lines. For the small fraction of tables that are awkward, a glance against the original costs far less than a shifted column corrupting your analysis.
Multiple tables, merged cells, and multi-page
Documents often hold more than one table, or a single table that runs across several pages with its header repeated each time. The extractor returns multiple tables in a consistent order so you can separate them, and for multi-page PDFs it joins continuation rows back onto the same table rather than treating each page as its own block.
Merged headers and wrapped cells are common trip hazards, because they can push every following value one column to the left if handled naively. By keeping the row-and-column relationships intact, the extractor keeps merged headers and multi-line descriptions in their proper place rather than letting them cascade an error down the whole table.
Checking a table came out right
Tables reward a quick sanity check more than free text does, because a single misread cell can throw off a calculation. The fastest checks are the obvious ones: does the row count match the original, do columns that should sum to a printed total actually add up, and do the header labels line up with the values beneath them? When those agree, you can usually trust the rest; when they don't, the discrepancy points you straight to the cell worth a closer look.
The trickiest inputs are the ones to scrutinise first — borderless tables, headers spanning several columns, and cells whose text wraps onto two or three visual lines, since these are where a naive extraction is most likely to slip a value sideways. Docyield keeps the row-and-column relationships intact specifically to avoid that cascade, but on an unusual layout a brief side-by-side against the original is cheap insurance against carrying a shifted column into your analysis.
Output formats and scaling up
CSV is the default, and the same extracted table is also available as Excel (XLSX), JSON, or XML from the result view. CSV suits importers and pivot tables; XLSX keeps typed numbers and dates for spreadsheet work; JSON gives you an array of row objects for code; XML fits older systems. They're all the same data in different wrappers, so switching tabs costs nothing, and one extraction can feed a spreadsheet and a script at once.
The free extractor handles one file at a time, which suits ad-hoc jobs. When you need to extract tables in volume — many documents a month, on a schedule, or from your own software — the Docyield API and batch dashboard run the identical extraction with webhook delivery, so the tables you test here come out the same way at scale. The dashboard tracks each file's status and lets you re-run any that need a second pass, which keeps a regular flow of documents from piling up.
How to extract a table
- 1Upload your file — drop a PDF or image (PNG, JPG, WEBP) onto the box above, or click to choose one.
- 2Wait a few seconds while Docyield locates the tables and rebuilds their rows and columns.
- 3Review the extracted table and spot-check the cells against the original page.
- 4Keep the CSV tab selected (the default), or switch to Excel, JSON, or XML instead.
- 5Download the file or copy the data, ready to import into Excel, Sheets, or your database.
Frequently asked questions
Processing documents at scale?
Batch upload, an extraction API, and webhooks for 100+ documents a month.