Checkpoint: read the Markdown as a projection, not a transcript
MarkItDown's dispatch engine and its format-specific converters are two halves of the same problem: one decides which interpretation can run, and the other decides what source relationships that interpretation can recover. This checkpoint connects those halves into a practical judgment. You will be able to look at a Markdown result and ask whether a line was directly extracted, structurally inferred, retained as fallback text, supplied as metadata, or produced through external enrichment—and then decide what deserves verification.
One result can contain several kinds of evidence
It is tempting to treat Markdown as a transparent window onto the source. The format is plain enough to read, and a successful call returns one coherent string. But the string is the end of a chain that begins with imperfect clues about the input and passes through a converter with its own interpretation rules. The output is coherent because MarkItDown gives different routes a common representation, not because every route observes the source in the same way.
The first layer is the source and its identity. A path, URI, response, or stream arrives with some combination of an extension, MIME type, filename, character set, or URL. MarkItDown can add content-based and encoding guesses, then retain more than one possible interpretation when the clues conflict. This layer answers, “What might this input be?” It does not yet answer, “What does the document mean?” A wrong or incomplete identity can send an otherwise readable source to the wrong converter, while a correct identity still leaves the converter with a difficult structure-recovery task.
The second layer is the converter's evidence. Some sources expose semantic structures directly. HTML has headings, links, lists, and tables in its markup. Office files can expose document objects, slide shapes, sheet boundaries, or chart data. In those cases, a Markdown heading or table is a representation of a structure the converter could inspect in the source. That does not make it lossless, but it gives the output a relatively direct basis.
Other sources require inference. MarkItDown's PDF path examines word positions to decide whether aligned content looks like a form or borderless table. The resulting columns and reading order are an interpretation of page geometry. They can be useful precisely because the original PDF may not label those relationships semantically. They also need more caution: a visually plausible table can be the result of a heuristic decision rather than an explicit table object.
A third outcome is fallback. HTML that is too deeply nested can fall back from Markdown conversion to plain text. A PDF can fall back from a form-oriented pass to ordinary text extraction, or from pdfplumber to pdfminer when the first route fails. Fallback is not synonymous with failure. It can preserve enough content to keep a pipeline useful. But it changes what the output says about structure. A line that appears as ordinary text may be there because the source had no recoverable hierarchy, or because the selected structural path declined to assert one.
A fourth outcome is enrichment from a different evidence source. The built-in document paths can include image descriptions or other optional content, while the OCR plugin can send embedded images or rendered scanned pages to a vision model and insert the returned text into the document. That text is not the same kind of evidence as a text layer extracted directly from the PDF. It may be valuable, especially when the source is made of pixels, but it is model-produced and carries a different verification obligation.