A table screenshot contains visible text and layout, but no spreadsheet cells. To turn it into an editable table, a recognition system has to recover both: the values and their positions within rows and columns. Reading every number correctly is not enough if a price ends up under the wrong product.
In imgtotable's AI Image to Table tool, a server-side model receives the image and an instruction to represent its table as HTML. The browser then converts that HTML into an editable grid. The model does not return an Excel workbook; the application creates the download afterward.
What the model is asked to produce
The current integration calls a service using the model name HunyuanOCR. Its table instruction translates to “Parse the table in the image into HTML.” The official HunyuanOCR documentation lists table-to-HTML parsing as a supported task.
HTML can express both cell text and table structure. A row is represented by <tr>, a cell by <td> or <th>, and merged cells by rowspan or colspan. That makes it a useful intermediate format between an image and a spreadsheet.
For example, a heading named “Sales” above two columns could be represented as follows. This is an illustrative example, not a recorded model result:
<table>
<tr><th colspan="2">Sales</th></tr>
<tr><th>Product</th><th>Units</th></tr>
<tr><td>Notebook</td><td>12</td></tr>
</table>
Here, colspan="2" tells the application that “Sales” occupies two columns. No pixel coordinates are needed to place it in the spreadsheet: its position follows from the row order, cell order, and span attributes.
How a vision-language model approaches the task
The HunyuanOCR technical report describes an end-to-end vision-language model: a vision encoder connects to a language model through an adapter. At a high level, the image is encoded into visual features, and the model generates an output sequence conditioned on those features and the instruction. For table parsing, that output includes markup and recognized text.
This differs from an application pipeline that separately detects text boxes, predicts a table grid, and matches each text box to a cell. Our AI table integration does not run those separate stages or consume cell bounding boxes. It requests HTML in one recognition call.
The output still has to describe relationships visible in the image: which values share a row, where a new cell begins, and whether a heading spans several columns. But the returned HTML does not expose how the model reached each decision. It would be misleading to describe a particular line detector, coordinate-clustering algorithm, or bounding-box regressor as part of this workflow without evidence.
How HTML becomes an editable spreadsheet
After recognition, the browser extracts the table HTML from the response. Its parser reads the first HTML table, walks through its rows and cells, and builds a grid of text values. It also records merged-cell spans so the editor can recreate them.
This step interprets the model's output; it does not recheck the source image. If the model leaves out a row or assigns the wrong span, the editor can faithfully display an incorrect table. A tidy grid is therefore not proof that recognition succeeded.
Once you have reviewed and edited the result, the browser can generate an Excel file or another supported export format. Excel export supports merged cells. CSV and ordinary Markdown tables cannot preserve those merges in the same way. The export also does not reproduce the screenshot's original fonts, colors, or exact column widths.
How this differs from local table recognition
Both tools use machine learning. The useful distinction is their recognition workflow and where the image is processed.
Local Image to Table combines PaddleOCR text recognition with SLANet+ table structure recognition and browser-side matching. The selected image stays on your device. Model files and runtime assets may need to be downloaded, so local processing does not imply that a first visit works without an internet connection.
The AI tool uploads the image for server-side recognition. Editing and exporting happen in the browser afterward. Use the local tool when your file-handling requirements prohibit uploading the image.
It is also inaccurate to say that conventional OCR only reads continuous paragraphs or ignores layout altogether. Our local pipeline uses text locations explicitly. A vision-language approach does not, by itself, guarantee more accurate results for every table.
Where the result can go wrong
Table recognition has two kinds of errors to check: incorrect text and incorrect structure. A missing minus sign changes a value; a missing blank cell can move a correct value into the wrong column.
Wrapped descriptions, faint separators, and multi-level headings can make row and column relationships ambiguous. Generated HTML may omit cells, repeat content, or describe a merge incorrectly. Large tables can also produce incomplete output when the response reaches a length limit.
Compare the result with the source before exporting:
- Count the data rows and columns, including rows near the bottom.
- Check merged headings against the columns beneath them.
- Look for blank cells that have disappeared or shifted neighboring values.
- Verify decimal points, minus signs, units, and identifiers with leading zeros.
What a screenshot cannot recover
A screenshot of a calculated value does not contain the original spreadsheet formula, cell reference, hidden worksheet, or pivot-table definition. Recognizing “110” cannot reveal whether it came from a sum, a lookup, or manual entry.
If formula text is itself visible, it can be transcribed as text, but that is different from restoring a working workbook. Add and verify any calculations you need after export. The recognized table is a reconstruction of visible content that you can review and edit.