Why plain OCR isn't enough

Plain OCR solves one part of copying from a screenshot: it recovers the characters. That is enough for a sentence, address, or serial number. It falls short when meaning depends on rows, headings, lists, or the boundary between body copy and a note.

When the content has structure, the useful result is a document you can review, edit, and paste into the tool where the work continues. Snapdown captures a selected screen region as structured Markdown so rows, headings, lists, and notes can move with the text.

The table and documentation comparisons below show where Apple Live Text and Snapdown both worked, where their outputs differed, and what still needed review.

Text and structure are separate

Text fidelity asks whether labels, numbers, punctuation, signs, and symbols match the source. Structural fidelity asks whether those characters stay in the rows, headings, lists, and notes that explain them.

Markdown makes those relationships explicit and gives the reader a visible result to inspect before the document moves into another tool.

A table is more than its words

A table is the clearest example because its meaning is two-dimensional. A number is useful only when it remains attached to the row and column that explain it.

The calibration table below contains six columns, five data rows, signed decimals, units, wrapped notes, and one intentionally blank cell.

Apple Live Text did more than return a wall of text in this clean example. When pasted into the Markdown destination, it produced a six-column pipe table and retained the intentional blank cell. This was its final unedited output:

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|201 m|-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.12mV/V||0.07 %FS|Low-voltage run; verify zero|
|TC-D09|75 N-m|2.05mV/|-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.

Snapdown 1.1.0 produced this final unedited Markdown:

# 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.

The clean table stayed usable

Both methods retained all six source columns, all six source rows in order, and the intentional blank cell. The difference was in the exact text and the table's Markdown header structure.

Apple inserted an empty Markdown header row and placed the six source headers in the first body row. Five cells also differed from the source, including a missing decimal and unit in 2.01 mV/V, both middle dots changing to hyphens, and an incomplete 2.05 mV/V value.

Snapdown matched all 35 non-empty table cells and used the source headers as the Markdown header. The table needed no text or structural correction for this image.

Outside the table, Snapdown promoted the FICTIONAL TEST DATA label above the actual title. Preserving the intended heading hierarchy required changing two Markdown markers. That issue did not alter the table, but it shows why text and structure should be checked separately.

Apple Live Text still produced a usable pipe-table draft rather than flat text. Snapdown produced the more accurate table and header structure for this clean image.

A degraded source tests the boundary

The clean image is the easiest case. We repeated the comparison with a degraded copy containing a 2-degree rotation, blur, lower contrast, grain, speckles, banding, resampling, and JPEG artifacts. The underlying table content did not change.

Apple Live Text produced this final unedited output:

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                      |
|                      | 250 N                | 2.01 mVV    | -0.08 %FS    | 0.03 %FS      | Room-temperature reference run |
| LC-A 17              |                      | 1.98 mV/    | +0.04 %FS    | 0.05 %FS      | Cable replaced before test     |
| LC-B04               | 1.5 kN               | 2.12 mVN    |              | 0.07 %FS      | Low-voltage run; verify zero   |
| TC-C12<br><br>TC-D09 | 20 N-m<br><br>75 N-m | 2.05 mVN    | -0.11 %FS    | 0.04 %FS      | Two readings averaged          |
| LC-E21               | 5.0 kN               | 2.00 mVN    | +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 OR testing.

Snapdown returned the same output for the clean and degraded sources, so it is not repeated here.

Apple retained a six-column table, but several row relationships became incorrect. The first data row lost its unit ID. The next two rows mixed identifiers and values from adjacent source rows. The TC-C12 and TC-D09 identifiers and rated loads were merged into shared cells. Only the LC-E21 row retained one complete source-row association, and OCR became OR in the final sentence.

Snapdown retained all 35 non-empty cells, all five data-row associations, the intentional blank cell, and the six source headers as the Markdown header. The table needed no corrections. The same two heading markers outside it still needed changing.

If the source application offers a CSV or spreadsheet export, use that instead. It avoids recognition entirely and preserves more of the original data. For screenshots without an export, the complete table test shows the source, a degraded version, the output, and the limits of pipe-style Markdown.

Documentation has structure too

We used the same region from the Kubernetes documentation page Deprecating parts of the API. The excerpt combines a heading, prose, a two-column API-version table, a five-item list, an emphasized rule, and a note.

Apple Live Text retained the surrounding prose and all five list items. It omitted the complete API-version table, changed two I characters to l, added a paragraph break within the list, and flattened the heading, rule, and note. This was its final unedited plain-text output:

Deprecating parts of the API

Since Kubernetes is an API-driven system, the API has evolved over time to reflect the evolving understanding of the problem space. The Kubernetes API is actually a set of APls, called "API groups", and each API group is independently versioned. API versions fall into 3 main tracks, each of which has different policies for deprecation:

A given release of Kubernetes can support any number of API groups and any number of versions of each.

The following rules govern the deprecation of elements of the API. This includes:

- REST resources (aka API objects)
- Fields of REST resources
- Annotations on REST resources, including "beta" annotations but not including "alpha" annotations.

- Enumerated or constant values
- Component config structures

These rules are enforced between official releases, not between arbitrary commits to master or release branches.

Rule #1: API elements may only be removed by incrementing the version of the APl group.

Once an API element has been added to an API group at a particular version, it can not be removed from that version or have its behavior significantly changed, regardless of track.

Note:

For historical reasons, there are 2 "monolithic" API groups - "core" (no group name) and "extensions". Resources will incrementally be moved from these legacy API groups into more domain-specific API groups.

Snapdown retained the visible text, table, five-item list, emphasized rule, and note block as structured Markdown. The standalone Obsidian note needed no text or structural correction. This was its final unedited output:

# Deprecating parts of the API

Since Kubernetes is an API-driven system, the API has evolved over time to reflect the evolving understanding of the problem space. The Kubernetes API is actually a set of APIs, called "API groups", and each API group is independently versioned. API versions fall into 3 main tracks, each of which has different policies for deprecation:

| Example | Track |
| --- | --- |
| v1 | GA (generally available, stable) |
| v1beta1 | Beta (pre-release) |
| v1alpha1 | Alpha (experimental) |

A given release of Kubernetes can support any number of API groups and any number of versions of each.

The following rules govern the deprecation of elements of the API. This includes:

- REST resources (aka API objects)
- Fields of REST resources
- Annotations on REST resources, including "beta" annotations but not including "alpha" annotations.
- Enumerated or constant values
- Component config structures

These rules are enforced between official releases, not between arbitrary commits to master or release branches.

**Rule #1: API elements may only be removed by incrementing the version of the API group.**

Once an API element has been added to an API group at a particular version, it can not be removed from that version or have its behavior significantly changed, regardless of track.

> **Note:**
> For historical reasons, there are 2 "monolithic" API groups - "core" (no group name) and "extensions". Resources will incrementally be moved from these legacy API groups into more domain-specific API groups.

Losing one table removed the definitions of the three API-version tracks while the surrounding sentences still looked complete.

When plain OCR is the better choice

Structure is useful only when the job needs it. Adding a document workflow to a one-line copy task creates work instead of removing it.

Use Apple Live Text when you occasionally need selectable text that is already visible in an image. Use a lightweight plain-text tool when the words alone are the result. If the source offers a text, spreadsheet, or document export, prefer the original data over any OCR path.

Specialist tools are also the better choice when math, full PDFs, handwriting, or difficult document ingestion is the main job. Structured Markdown is not a replacement for every source format or recognition tool.

Snapdown is designed for the cases where visible content needs to retain useful structure as a Markdown document on a Mac.

Use the result where the work continues

The difference between plain text and structured Markdown matters after recognition. The output should survive the handoff into the issue, note, document, or prompt where someone needs to understand it.

If your screenshots depend on more than the words alone, test the complete workflow: capture the source, inspect the Markdown, and paste it into the place where the work continues.

Try the first 10 successful captures free, then pay $12 USD once. Snapdown runs on Apple silicon Macs with macOS 14 or later.

Source note: Excerpt from Kubernetes documentation, by the Kubernetes Authors and licensed under CC BY 4.0. The excerpt was reproduced without changing its wording.