UltKit

How to Extract Tables from Images and PDFs into Excel or CSV

A text PDF with a real table converts to Excel in seconds; a photo or scan needs OCR first, and a table that is only tab-aligned text needs column splitting rather than recognition. Whatever the route, check row counts and one column total before you trust the result, because the errors that matter are wrong numbers, not ugly formatting.

Tom OkaforTom OkaforPDF and documents editor
Updated 12 min read
Overhead view of printed tax forms with ruled tables, a phone showing a calculator app, a pen and a cup of black coffee on a dark desk
Answer

What is the fastest reliable way to get a table out of an image or PDF?

Work out what the source is first. A PDF made by software already holds the text, so export it straight to XLSX. A photo or scanned page needs OCR with table detection: shoot it straight, at roughly 300 dpi, cropped to the table. Then compare the row count and one column sum with the original before you use the numbers.

Three kinds of table, three different jobs

Before picking a tool, find out what kind of table you actually have, because the three common sources fail in different ways. Open the PDF and try to select a single number with the cursor. If the number highlights on its own, the file is a text PDF: every character is stored as text at an exact position, and extraction is mostly about grouping those characters into rows and columns. If the whole page highlights as one block, or nothing highlights at all, you are holding a picture of a table, and someone has to read the pixels first.

The third case is easy to miss. Many reports exported from older accounting systems, terminal programs and email bodies look like tables but are plain text lined up with tabs or runs of spaces. There are no cells at all, only a monospaced layout. Running OCR on a screenshot of that text throws away information you already have; copying the text and splitting it into columns is faster and exact. The cards below sum up what each source needs.

  1. Text PDF with a real table

    Exported from Excel, an accounting package or a bank portal. The characters are already text, so a converter only rebuilds the grid. Expect near-perfect values and occasional problems with merged headers.

  2. Scanned or photographed table

    A paper invoice, a printed price list or a statement someone scanned. OCR has to read every character before the grid can be found, so image quality decides how many digits come out wrong.

  3. Tab-aligned text that looks like a table

    A fixed-width report or a pasted email. Copy it, paste it into a sheet and split it with Excel's Text to Columns or Google Sheets' Split text to columns, using tab or fixed width.

What table recognition actually does

Table recognition is a second pass that runs after the characters are known. First it finds cells: on ruled tables it traces the horizontal and vertical lines and treats each enclosed box as a cell; on borderless tables it looks for vertical gutters of empty space that run the full height of the block. Then it aligns columns, deciding that a number sitting a few pixels to the right of the one above still belongs to the same column.

Next comes the header row. Recognizers look for a first row that is bold, shaded, or made of words above columns of numbers, and they join headers that wrap over two lines into a single cell. Merged cells are the last step: a label such as Q1 spanning three month columns is detected from the missing internal lines and either rebuilt as a merged cell or copied into each column it covers.

None of this is reading comprehension. The software does not know that a column holds dates or that a row is a subtotal; it only sees geometry and characters. That is why the same tool can be flawless on one statement and scramble the next one from a different bank, and why settings such as Table style and Detect header row exist at all: they hand the recognizer a fact it cannot reliably infer.

Where table recognition goes wrong

Most failures fall into two groups. Geometry failures break the grid, so values land in the wrong row or column. Number failures leave the grid intact but change what a cell means, which is worse because the sheet looks fine. A misplaced column is obvious at a glance; 1.234 read as a decimal instead of a thousand is not.

Locale is the main source of number trouble. The United States and the United Kingdom write 1,234.56; Germany, Brazil and most of continental Europe write 1.234,56; France uses a space as the thousands separator; Switzerland often uses an apostrophe, as in 1'234.56; and India groups digits as 1,23,456. Accounting documents add negative numbers in parentheses and currency symbols glued to the digits. Here is what to watch for and what fixes each case.

  • Borderless table, columns drift

    Set Table style to Whitespace columns so gaps rather than lines mark the columns, and crop away text above and below the table that breaks the gutters.

  • Rotated or skewed page

    A page turned 90 degrees reads as nonsense, and a tilt of a few degrees makes rows merge. Rotate the scan upright and leave Straighten image on.

  • Handwritten entries

    Table recognition is tuned for printed characters. Neat block capitals in boxed forms often work; cursive notes in a ledger usually need retyping or a careful cell-by-cell check.

  • 1.234 read as one point two three four

    The decimal convention was guessed wrong. Set Decimal separator to Comma 1.234,56 or Dot 1,234.56 to match the document instead of leaving it on Auto.

  • Amounts with $, € or ISO codes stay text

    A cell such as EUR 45.00 or 45,00 € may not convert to a number. Strip the symbol with Find and Replace, then reapply a currency format to the column.

  • (250.00) imported as text

    Parentheses mean negative in accounting. Excel reads (250) typed by hand as minus 250, but recognized text with spaces or symbols inside may stay text; replace the brackets with a leading minus sign.

A printed tax form with a ruled table of numbered lines and shaded boxes, a silver pen beside it and a black mug of coffee on a dark table
Photo: Unsplash

Prepare the image before you convert

Every minute spent on the input saves several in the spreadsheet. OCR engines are commonly tuned for text scanned at around 300 dpi, which for an A4 or US Letter page means roughly 2480 × 3508 px or 2550 × 3300 px. A modern phone camera easily beats that if the page fills the frame, but a full-page photo shot from across the desk, then cropped to a small table, can drop well below it.

Contrast matters as much as resolution. Thermal-paper receipts fade, gray table rules on a gray background disappear, and a shadow from your phone across the page can cut a column in half. If the original is a paper document you will extract from regularly, the guide to scanning documents to PDF covers lighting and scanner settings in more detail. Before you upload, run through this list.

  • The page is flat and the camera is directly above it, not at an angle
  • Text is dark on a light background with no shadows or glare across the rows
  • Small digits are sharp when you zoom to 100%, roughly 300 dpi for printed pages
  • The image is cropped to the table, without the letterhead, logos or notes in the margin
  • The page is upright, and each photo holds one table or clearly separated tables
  • Multi-page tables are captured page by page in order, with no page skipped

Five routes from table image or PDF to spreadsheet

Excel's Data from Picture arrived in the Android app in 2019, then on iPhone, and it is now in Excel for Microsoft 365 on Windows and Mac under Data > From Picture. You photograph or load one table, review the recognized cells in a side panel that flags doubtful values, and insert them. Google offers a less direct path: in Drive, right-click an image or PDF and choose Open with > Google Docs. Google's own help page limits this to files of 2 MB or less and reads only the first 10 pages of a PDF, and the result is a document, so the table often arrives as lines of text you then paste into Sheets and split.

Adobe Acrobat Pro exports a PDF to a Microsoft Excel workbook and runs OCR on scanned pages during export. Excel for Microsoft 365 on Windows can also pull tables from a text PDF with Get Data > From File > From PDF, which opens Power Query; it lists every detected table by page, lets you append a statement's monthly pages into one table and refreshes when you swap in next month's file. It does not read scans, and Excel for Mac does not have the connector.

Browser converters cover the rest without installing anything. For a text or scanned PDF, PDF to Excel turns every detected table into its own sheet; for a photo or screenshot, convert the image to Excel or save the table as CSV when another program will import it. The table compares the five routes.

Routes for getting a table into a spreadsheet
RouteReads scans and photosWhere it runsBest for
Excel Data from PictureYesExcel mobile apps; Microsoft 365 on Windows and MacOne printed table, reviewed cell by cell
Google Drive OCRYes, files of 2 MB or lessDrive in any browserShort tables when you already work in Google Sheets
Acrobat export to ExcelYes, in Acrobat ProAcrobat desktop app, paidLong PDFs if you already have a licence
Power Query From PDFNo, text PDFs onlyExcel for Microsoft 365 on WindowsThe same statement layout every month
Browser converterYesAny browser, phone or desktopXLSX or CSV without installing anything

Check the result before you use it

A converted table that looks right is not yet a table you can rely on. Start with the row count: if the statement lists 47 transactions, the sheet should have 47 data rows, not 46 because two lines merged or 49 because a wrapped description became its own row. Then add up one numeric column with SUM and compare it with the total printed on the document. If the document has no total, add a few values by hand and compare.

Next, look for cells that only pretend to be numbers. In Excel, real numbers align right by default and text aligns left, so a column with a few left-aligned amounts is telling you something; ISNUMBER on a helper column finds them all at once. Dates deserve the same suspicion. A date read as text sorts alphabetically, so 10/02 lands before 2/03, and 03/04 can mean 3 April or March 4 depending on who wrote it.

Finally, check what was lost rather than what was changed. Long account and card numbers are a classic trap: Excel stores numbers with 15 significant digits, so a 16-digit card number typed or imported as a number has its last digit turned into a zero.

TipAdd a helper column with =ISNUMBER(C2) next to each amount column and filter it for FALSE. Every row that shows up is a value that will be skipped by SUM, charts and pivot tables.

CSV or XLSX: choosing the output file

Pick XLSX when a person will work with the data in Excel, Google Sheets or Numbers. It keeps several tables on separate sheets, real number and date types, bold header rows and merged cells. Pick CSV when software will import it: budgeting apps, accounting packages, databases and scripts. CSV is plain text with one table per file, described in RFC 4180 from 2005, and the three settings that matter are the delimiter, the encoding and whether numbers are stored as numbers.

The delimiter has to match the importing program; Excel in countries that write decimals with a comma expects semicolons. The encoding decides whether names such as Müller or São Paulo survive: UTF-8 with BOM is what Excel for Windows reads correctly on a double-click. Leading zeros are the classic loss. US ZIP codes such as 02134, employee IDs and product codes are identifiers, not quantities, and become 2134 as soon as anything treats them as numbers. Turn off Store numbers as numbers for tables full of IDs, or import the CSV with those columns set to Text.

Stored as a number

2134

A Boston ZIP code after a CSV is opened by double-click: the leading zero is gone and lookups against the address list fail.

Stored as text

02134

The same cell with Store numbers as numbers turned off, or the column imported as Text.

Batch extraction and sensitive documents

Extracting one table is a lookup; extracting a year of invoices or twelve monthly bank statements is a small data project. Keep the source documents in the same layout where you can, and convert them in one pass so every file gets the same settings. With text PDFs, upload up to 20 at a time, each up to 95 MB, and choose Everything on one sheet in the Sheets option when a statement's transaction table continues across pages. Photos convert one table image at a time, so for a stack of paper invoices it is often quicker to combine the pages with image to PDF first and point PDF pages at the range that holds the tables.

After a batch, append the results into one sheet with a column that records the source file name. If the documents are mostly text with a table or two, converting the PDF to Word keeps the paragraphs and the tables together instead.

Bank statements, payslips and invoices carry account numbers, addresses and spending history, so think about where they go. On UltKit, uploads and the generated files are deleted 30 minutes after processing and are not read by anyone. Still, the safest copy is the one that never leaves your computer: crop or redact columns you do not need, such as full account numbers, before upload, and delete local exports you no longer need.

Do not send statements to a converter you cannot identify

Check that a site states how long it keeps files and that the address bar shows HTTPS before you upload anything with account numbers or tax IDs. If an employer or client contract restricts where financial data may be processed, use desktop software such as Excel's Power Query instead.

Key takeaways

  • Test whether you can select a single number in the PDF: if yes, skip OCR and export the table directly.
  • Photos and scans convert best when they are straight, high contrast, about 300 dpi and cropped to the table.
  • Set the decimal separator to match the document; locale mix-ups change values without breaking the layout.
  • Compare the row count and one column total with the original before using any extracted numbers.
  • Use XLSX for people and CSV for software, and keep ZIP codes and IDs as text so leading zeros survive.

Frequently asked questions

Can I copy a table from a PDF straight into Excel?

Sometimes. Copying from a text PDF and pasting into Excel works for simple tables, but each row often lands in a single cell or columns shift where cells are empty. An export to XLSX rebuilds the grid more reliably.

Why does a screenshot of a table convert better than a photo of the screen?

A screenshot has perfectly straight lines, even lighting and crisp pixels, so OCR reads it almost like a text document. A phone photo of a monitor adds glare, moire patterns and perspective, which cause most misread digits.

How do I extract a table that spans several pages?

Convert the whole page range in one job and put everything on one sheet, then delete the repeated header rows that each page brings with it. Check that the row count matches the total number of lines in the original.

Can table extraction read a table inside a Word or PowerPoint file?

There is no need for recognition there, because Word and PowerPoint tables are already real tables. Select the table, copy it and paste it into Excel or Google Sheets, and each cell keeps its place.

Why did my dates turn into five-digit numbers?

Excel stores dates as serial numbers counted from 1 January 1900, so 45658 is 1 January 2025. The values are correct; apply a date format to the column to show them as dates again.

Is OCR accurate enough for accounting?

It is accurate enough to save the typing, not to skip the checking. Reconcile totals against the source document and spot-check any value that changes a balance before posting it to your books.

Keep reading