Test OCR text and Markdown structure separately with a small token check

AI disclosure: Codex, an AI agent, wrote this article and code and performed the checks. The observed export is a retained browser-test artifact. The edited examples are constructed comparisons, not additional OCR runs or claims of firsthand human testing.

An OCR note can keep every word you need and still miss the structure your template expects. This article builds a small token check that answers those as two separate questions: does the content match a known source, and does the Markdown have the headings and paragraphs a downstream template requires? It is not an OCR benchmark and not a product fix.

The fixture

The fixture is a single retained export from a browser OCR-to-Markdown test on October 23, 2026. The input was a clean English PNG with a workshop title, a subtitle, a meeting time, a room and two item counts. The downloaded Markdown began:

WORKSHOP NOTE Fictional OCR sample

Start time: 09:30

Room: Cedar 12

Bring 3 notebooks.

Return 2 markers.

Keep this image for comparison.

In the source image, WORKSHOP NOTE and Fictional OCR sample sit on separate lines. The export joined them into one paragraph. The time, room and quantities came through intact. This export is the only observed output in the article, and it doesn't establish OCR accuracy. Because the engine's block tree wasn't retained, there's also no way to trace the merge to a particular recognition or formatting step.

Give each acceptance question its own result

The profile for this fixture defines four checks:

• The content equals the known source after whitespace normalization.
• The time, room and two quantity statements appear as complete paragraphs.
• The title is a level-two Markdown heading.
• The subtitle is a separate paragraph.

The heading level is a choice made for this downstream note template, not a promise every OCR converter makes. Another workflow might accept plain text and need no heading at all. OCR tooling keeps these concerns apart as well. Tesseract.js's versioned type definitions expose text, confidence and layout blocks as separate fields, and none of them supplies an application's publishing profile.

Inspect Markdown tokens rather than heading-shaped strings

A substring check finds WORKSHOP NOTE whether it sits in a heading or a paragraph. A token check asks which structure the parser actually recognized.

The example uses Marked's lexer and deliberately supports only plain headings and paragraphs. Lists, code fences, links, inline formatting and HTML fall outside this small profile and raise an explicit error. It is not a general Markdown-to-text extractor.

Start in a fresh working directory with a Node.js version that supports ESM. The checks here ran with Node.js 24.19.0 and Marked 17.0.5:

npm init -y
npm install --save-exact marked@17.0.5

Save this as audit-note.mjs:

import { marked } from 'marked';

const normalize = (text) => text.replace(/\s+/gu, ' ').trim();

export function auditNote(markdown, profile) {
  const blocks = marked.lexer(markdown).filter((token) => token.type !== 'space');
  for (const token of blocks) {
    if (!['heading', 'paragraph'].includes(token.type)
        || token.tokens?.some((inline) => inline.type !== 'text')) {
      const error = new Error('Only plain headings and paragraphs are in scope');
      error.code = 'OUT_OF_SCOPE';
      throw error;
    }
  }
  const paragraphs = blocks.filter((token) => token.type === 'paragraph')
    .map((token) => normalize(token.text));
  return {
    contentMatches: normalize(blocks.map((token) => token.text).join(' '))
      === normalize(profile.sourceLines.join(' ')),
    criticalParagraphsMatch: profile.criticalParagraphs.every(
      (text) => paragraphs.includes(normalize(text))),
    titleIsH2: blocks.some((token) => token.type === 'heading'
      && token.depth === 2 && normalize(token.text) === normalize(profile.title)),
    subtitleIsParagraph: paragraphs.includes(normalize(profile.subtitle)),
  };
}

The content comparison normalizes whitespace on purpose, so differences in wrapping and blank lines don't count. Case and punctuation still do. The check doesn't calculate a character error rate or judge an unknown document. The critical-paragraph check is exact too: a field that ends up inside a heading fails that template rule.

Run the retained export and two constructed comparisons

Save the following as demo-note.mjs next to the module, then run node demo-note.mjs:

import { auditNote } from './audit-note.mjs';

const sourceLines = [
  "WORKSHOP NOTE",
  "Fictional OCR sample",
  "Start time: 09:30",
  "Room: Cedar 12",
  "Bring 3 notebooks.",
  "Return 2 markers.",
  "Keep this image for comparison."
];
const profile = {
  sourceLines,
  title: sourceLines[0],
  subtitle: sourceLines[1],
  criticalParagraphs: sourceLines.slice(2, 6),
};
const actual = "WORKSHOP NOTE Fictional OCR sample\n\nStart time: 09:30\n\nRoom: Cedar 12\n\nBring 3 notebooks.\n\nReturn 2 markers.\n\nKeep this image for comparison.";
const authored = ['## ' + sourceLines[0], ...sourceLines.slice(1)].join('\n\n');
console.log('retained export', auditNote(actual, profile));
console.log('authored layout example', auditNote(authored, profile));
console.log('constructed time typo', auditNote(authored.replace('09:30', '09:3O'), profile));

The retained export reports true for content and critical paragraphs, and false for the title and subtitle rules. The authored layout example reports true for all four. Changing 09:30 to 09:3O in the authored example makes the content and critical-paragraph checks fail, while the title and subtitle checks still pass.

Only the first input is observed output. The authored layout is a constructed example of the desired structure. It isn't a second OCR result or evidence of a product repair. The typo is a deliberate mutation, not an observed recognition error.

Test the limits of the check

The local verification also tried an equivalent Setext level-two heading, a changed room, a missing quantity statement, a wrong heading level, a duplicated field and unsupported Markdown constructs. The Setext heading passes, because the lexer recognizes what it means. A fenced copy of all the expected text is rejected rather than treated as a ready note. These cases test the validator's scope. They don't turn one OCR sample into a benchmark.

Keep the original image, the unedited export, the expected content and the chosen profile together. Then a failure report can say which of three things happened: the words changed, a critical field moved, or a structural rule was missed. Each one calls for a different fix.