A screenshot stores the appearance of a table, not its cells. To calculate a total or sort its rows, you need to recognize the text and reconstruct the columns. The useful result is a checked workbook: recognition alone can turn a clear-looking 8 into a 3 without warning.
Start with the best available source
Ask for a CSV or spreadsheet export first. If the table is selectable text, copy it into Text to Excel; that avoids recognition errors. Use Image to Excel when an image is the only source. Inserting the screenshot into a worksheet would keep it as a picture and would not make the values editable.
Crop to one table and keep its headers. Use the original-resolution screenshot rather than a thumbnail forwarded through a messaging app. For a camera photo, straighten the page and avoid glare across numbers. Separate unrelated tables into different images instead of expecting the converter to infer their relationship.
Read the image, then repair the cells
- Select the screenshot and wait for recognition to finish. Keep the tab open while the OCR language data loads.
- Inspect the preview row by row. Correct broken words, joined columns and extra rows before export.
- Check the column headers and whether one source row still corresponds to one spreadsheet row.
- Download the XLSX and open it in a spreadsheet application. Apply number, date or text formatting deliberately.
Preserve account codes, postal codes and identifiers as text. A leading zero is part of an identifier, not an optional formatting choice. OCR does not understand which column contains money and which contains a reference number.
A small reconciliation catches large mistakes
Example: a three-line invoice
Suppose the image shows amounts 12.50, 7.00 and 3.25, with a total of 22.75. Compare each amount, then calculate the total from the exported cells. A matching total is useful, but still check the item codes: two offsetting errors can leave the same total.
Count the rows independently, inspect minus signs and decimal separators, and compare the first and last record. Dates such as 03/04/2026 need the source’s day/month convention. Do not let an automatic date conversion decide the meaning for you.
When to stop fixing the output
Dense tables with merged headings, handwriting and faint scans need more correction. If several rows are misaligned, return to the source: a tighter, straightened crop is often faster than moving hundreds of cells. Enlarging a blurry image adds pixels but does not restore missing character detail.
For payroll, invoices or records used in decisions, compare every critical field. The browser performs the recognition locally, but privacy does not establish accuracy. Keep the source next to the corrected workbook so another person can trace any disputed value.
Sources and checks
Microsoft asks users to review recognition results before inserting them. Apply the same check to OCR here: compare every amount and identifier with the source image. Microsoft: Data from Picture.
Skew, noise and page segmentation can affect recognition. A sharper, straightened crop can help, but does not guarantee correct cells. Tesseract: improving OCR input.
A checked example
Synthetic examples checked in Chromium on Linux, September 9, 2026. The HEIC input is a licensed sample.
The original synthetic table has four columns and four rows, including headers. The 16 expected positions were defined before comparing OCR. In this one run, 14 positions matched exactly. The empty Memo cell in Amina’s row was lost: 12.50 shifted from Amount into Memo. This is a positional comparison, not an OCR benchmark.

Compare actual OCR text with the image. Insert one tab between 00127 and 12.50 to restore the empty Memo cell. In the corrected workbook, IDs remain text and the three numeric amounts total 22.75. Text fallback was not used to validate recognition.

Frequently asked questions
Why did everything end up in one column?
The recognizer may not have found consistent spacing between columns. Crop to a single table, check alignment, then separate the preview columns before export.
Can it read a handwritten table?
Handwriting is outside the dependable workflow described here. Transcribe and check it manually if recognition does not produce reliable cells.
Does the output include the original formulas?
No. A screenshot contains displayed values, so the formulas and calculation history are not available to recover.
Before you finish
Keep the screenshot until the row count, critical values and calculated totals agree. That is the point at which an OCR draft becomes a usable spreadsheet.Content revised .
Added inspected example outputs and corrected the relevant workflow limitations.