Turning a screenshot of a table into a spreadsheet

Where PNG came from, and why it is like this

This is optical character recognition with a second problem stacked on top. Reading the characters is the easy half; the hard half is deciding which cell each one belongs to.

A spreadsheet is a grid with meaning: this number is in this row and that column, and its position is what makes it a data point rather than a digit. An image has none of that — it has ink at coordinates. Reconstructing the grid means inferring column boundaries from the horizontal positions of text and row boundaries from the vertical ones, and the inference is only as good as the alignment in the original.

Is this conversion lossy?

Two independent chances to be wrong, and they compound. A character misread is a wrong value; a column boundary misplaced is a value in the wrong place, which is worse, because a number that has moved one column left still looks like a perfectly ordinary number.

What works: tables with clear alignment, consistent spacing, visible ruling lines, and left- or right-aligned columns. What does not: centred columns, merged cells, wrapped text inside a cell, nested headers, and tables photographed at an angle.

Numbers deserve particular suspicion. A misread letter usually produces a visibly odd word. A misread digit produces a plausible number, and a decimal point lost to compression artefacts produces a number a hundred times too large that no spreadsheet will flag.

What happens to metadata, transparency and colour

Formulas do not exist in the output. A screenshot of a spreadsheet shows results, not the formulas that produced them, and no amount of recognition can recover them. What you get is values.

Formatting does not survive. Currency symbols, thousands separators, date formats, cell colours and conditional formatting are visual and are not reconstructed. A column of dates may arrive as text in whatever shape the image showed.

Merged cells break the grid. A merged header spanning three columns has no representation in a simple row-and-column reconstruction, and its content will land in one cell with the others empty.

Types are guessed. Whether a cell is a number, a date or text is inferred from how it looks, and inference gets it wrong at the edges — particularly with dates, where the day-month order is genuinely ambiguous.

Why people actually need this

Data visible on a screen that cannot be exported. A dashboard with no download button, a report delivered as a PDF, a supplier's price list sent as a photograph, a legacy system whose only output is what is on screen. The numbers are right there and completely uncooperative.

The second situation is speed. Retyping a forty-row table takes ten minutes and introduces its own errors; recognising it takes seconds and introduces different ones. When the alternative is manual transcription, this is often the better error rate — but only if the result is checked.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for Image to Excel, the tool that performs it, on the hardware described on the limits page:

Not tested

This page sets no size guard of its own, so what you see below is where the browser itself stopped.

When something else is the better answer

If any export exists — CSV, a copy-to-clipboard button, an API, a print-to-file — use it. Exact beats recognised every time, and it is not close.

If the data can be selected as text rather than captured as an image, pasting it as delimited text skips the recognition step and its entire error class.

If the source is a PDF with a real text layer, extract the text first rather than screenshotting the page — the characters are already there and perfect.

If the table carries numbers that matter — financial, medical, legal — check every value against the image. This is a tool for saving typing, not for handing unverified numbers to something that will act on them.