Broden Suffern
A screenshot turns a table into pixels. A useful conversion has to recover not just the words, but the rows, columns, headers, and blank cells that give them meaning.
Short answer: On a Mac, press Snapdown's capture shortcut and select the
visible table. Snapdown 1.1.0 copies compatible rectangular tables to your
clipboard as Markdown. Paste the result into your document, then check its rows,
columns, and values against the source. Recognition runs locally, so the
screenshot does not need to be uploaded for OCR.
The table used for this test
The test table combines six tightly spaced columns, small technical labels, signed decimals, units, wrapped notes, and an intentionally blank cell. These details test whether OCR can read each value and keep it in the correct row and column.
The self-authored calibration table used for the clean extraction test. All identifiers and values are fictional.
I ran both tests with Snapdown 1.1.0 on my 16 GB M4 MacBook Pro using the
default Markdown output with GFM tables.
In both runs, Snapdown preserved all six rows and columns and every table value. The complete results and observed limitation appear below.
Why copying the words is not enough
A table is two-dimensional. The text matters, but so do the relationships between cells. A flat OCR result can read every word and still leave a column of values detached from the header that explains it.
If the source application can export the table directly, use that instead. It avoids OCR and preserves the original structure.
The extraction therefore needs two checks:
- Text fidelity: did it read each label, number, symbol, and unit correctly?
- Structural fidelity: did it keep the correct rows, columns, headers, and intentionally blank cells?
For numerical or operational data, structural errors can be harder to notice than spelling errors. A value shifted one column to the left may still look plausible, so the reconstructed table should always be checked against the source before it is used in a report, calculation, or automated process.
How to copy the table with Snapdown
- Open the page, PDF, slide, or application containing the table.
- Press
Command+Shift+2, Snapdown's default capture shortcut. - Drag tightly around the complete table, including every header and row label.
- Wait for Snapdown to copy the result to your clipboard.
- Paste the result into your document, compare it with the source, and correct any errors.
Tight cropping helps because unrelated headings, sidebars, tooltips, and page controls can be mistaken for part of the table. Keep genuine table notes inside the crop when their relationship to the data matters.
The exact unedited result
# FICTIONAL TEST DATA
## Bench calibration summary
Five fictional sensors measured during a controlled verification run. Values are invented and must not be used as engineering specifications.
| Unit ID | Rated load | Sensitivity | Zero balance | Repeatability | Test note |
| --- | --- | --- | --- | --- | --- |
| LC-A17 | 250 N | 2.01 mV/V | -0.08 %FS | 0.03 %FS | Room-temperature reference run |
| LC-B04 | 1.5 kN | 1.98 mV/V | +0.04 %FS | 0.05 %FS | Cable replaced before test |
| TC-C12 | 20 N·m | 2.12 mV/V | | 0.07 %FS | Low-voltage run; verify zero |
| TC-D09 | 75 N·m | 2.05 mV/V | -0.11 %FS | 0.04 %FS | Two readings averaged |
| LC-E21 | 5.0 kN | 2.00 mV/V | +0.02 %FS | 0.06 %FS | Fixture preload: 0.5 kN |
One blank zero-balance cell is intentional. All identifiers and values were created for Snapdown OCR testing.
What the conversion preserved
Score text and structure separately. A useful table result needs both.
| Check | Source | Result | Corrections required |
|---|---|---|---|
| Non-empty cells with correct text | 35 | 35 | 0 |
| Rows in the correct order | 6 | 6 | 0 |
| Columns in the correct order | 6 | 6 | 0 |
| Correct column headers | 6 | 6 | 0 |
| Correct row headers | 5 | 5 | 0 |
| Intentionally blank cells preserved | 1 | 1 | 0 |
All 35 non-empty table positions matched the source, and the intentionally blank cell remained in the correct row and column. The table needed no text or structural correction in this run; verification time was not measured. This is a result for one controlled fixture, not a general accuracy rate for other tables.
Outside the table, Snapdown transcribed every word correctly but promoted the
FICTIONAL TEST DATA label above the actual title in the Markdown heading
hierarchy. Preserving the source's intended hierarchy would require changing two
heading markers. The table-fidelity counts above do not include that surrounding
document-structure issue.
A second test with a poor scan
Clean screenshots are the easiest case, but many useful tables come from older reports, photocopies, and low-quality scans. We repeated the workflow with a visibly degraded table to see whether the rows and columns remained usable.
The same table after a 2-degree rotation, blur, lower contrast, grain, and JPEG compression.
| Check | Observed result |
|---|---|
| Source quality | 1226 x 802 px; 2-degree rotation with blur, contrast loss, grain, speckles, banding, resampling, and JPEG artifacts |
| Rows and columns preserved | 6 of 6 rows and 6 of 6 columns |
| Text corrections | 0 inside the table |
| Structural corrections | 0 inside the table |
| Difference from clean output | None; the clipboard outputs were byte-for-byte identical |
The degraded source produced the same unedited Markdown as the clean source, including every table value and the intentional blank cell. It introduced no additional recognition or table-structure errors. Both outputs share the two-marker heading-hierarchy issue described above. This one result does not prove that all skewed, damaged, compressed, or low-resolution tables will behave the same.
What still needs review
Table OCR should produce a strong editable draft, not an excuse to skip verification. Check these details before relying on the result:
- Numbers, decimal points, percentages, signs, and units.
- Dates and region-specific date formats.
- Abbreviations, identifiers, and leading zeroes.
- Empty cells that could cause later values to shift.
- Wrapped text that may be assigned to the wrong row.
- Multi-row headers, merged cells, and grouped columns.
- Notes or footers that qualify how the table should be read.
Which screenshots work best?
Clear, tightly cropped screenshots with readable text and visible alignment are the safest starting point. Small text, compression, low contrast, overlapping tooltips, rotation, and incomplete headers increase the likelihood of manual cleanup.
What about merged cells?
Pipe-style Markdown tables cannot represent rowspan or colspan. A complex
table may need to be flattened, split into simpler tables, or retained as HTML
inside the Markdown document. The right choice depends on where the result is
going next.
Should the result be Markdown or HTML?
The best table format is determined by the destination, not by OCR alone.
| Destination or job | Usually suitable | Reason |
|---|---|---|
| README, issue, or simple technical note | GFM pipe table | Compact, readable source for simple rectangular tables. |
| Markdown document with grouped or merged cells | HTML table | Can retain row and column spans that pipe syntax cannot express. |
Snapdown 1.1.0 defaults compatible rectangular tables to GFM pipe syntax and
can retain original HTML for structures that require review. This fixture
produced GFM; it did not test grouped or merged cells.
Keep sensitive tables on your Mac
Tables often contain internal metrics, customer details, research results, or financial information. Snapdown runs recognition locally on Apple silicon, so the screenshot and recognized content are never uploaded for OCR. The result is copied directly to your clipboard.
Try the workflow on your own table
Test Snapdown with the tables you use most often. Start with a clear example, then try layouts that normally need manual cleanup, such as merged headers, wrapped cells, small numbers, and unusual column structures.
Try the first 10 successful captures free. Snapdown is a $12 USD one-time purchase for Apple silicon Macs running macOS 14 or later.