Twelve Formats In, Clean Markdown Out, Conversion Engineering
Pull-quote: “Every organization’s knowledge is locked in formats chosen by the tool that created them. Conversion is how you get it back.”
Why this matters
An organization’s knowledge does not live in one format. It lives in Word documents with tracked formatting, Excel workbooks where the table is the content, slide decks whose real substance is in the speaker notes, scanned images, e-books, exported HTML, structured data files, and zip archives holding all of the above. Any pipeline that wants to treat this material as one corpus, for version control, for search, for AI ingestion, needs a normalization step. Conversion looks like a solved, trivial problem until you commit to doing it well, at which point it reveals itself as a series of fidelity decisions.
What must survive, per format
The engineering question for each format is not “can we extract text” but “what structure must survive extraction for the output to be usable.”
| Input | The structure that must survive | The failure if it does not |
|---|---|---|
| Word | Headings, emphasis, lists | A wall of undifferentiated paragraphs |
| Excel | Tables, as tables | Numbers with their meaning stripped |
| PowerPoint | Slide text and speaker notes | The deck’s argument lost, only captions kept |
| Scanned images | Text, via OCR | An opaque binary a pipeline cannot read |
| Zip archives | The whole set, in one pass | Manual unpack-and-convert loops |
This is the reasoning behind MarkForge, an open-source conversion tool built on Microsoft’s MarkItDown engine rather than from zero. The foundation handles the breadth: a dozen formats, including PDF, Word, Excel, PowerPoint, HTML, EPUB, images with OCR, CSV, JSON, XML, and ZIP archives. The engineering effort then goes into what comes out the other side, clean and consistent Markdown, produced the same way whether the tool runs as a desktop application or in the browser.
Why Markdown is the target
.docx .xlsx .pptx version control (diffable)
.pdf .epub .html ──► Clean, ──────► AI pipelines (parseable)
images (OCR) consistent search and retrieval
.csv .json .xml Markdown humans (readable as-is)
.zip archivesMarkdown earns the target position on four properties. It is plain text, so version control can diff it and a reviewer can read the diff. It is structured enough to preserve what matters, headings, tables, lists, code, without embedding a rendering engine’s opinions. It is the de facto interchange format that AI ingestion pipelines already parse. And it stays legible to a human with no tooling at all. Proprietary formats optimize for the authoring tool. Markdown optimizes for everything downstream, which is exactly where converted documents spend the rest of their lives.
Clean is the hard part
The word doing the work in “clean Markdown” is clean. Naive extraction produces artifacts: layout junk masquerading as content, tables flattened into prose, heading levels assigned at random. Consistency is the property that makes a converted corpus usable, because every downstream consumer, a chunking step, a search index, a reviewer, gets to rely on the same conventions across every document regardless of source format. One engine, one set of conventions, every format: that is the design principle, and it is why conversion deserves to be treated as engineering rather than as a utility script that grew.
Closing
Everything becomes plain text you can govern: that is the promise of document-to-Markdown conversion done properly. Twelve formats in, one consistent, diffable, pipeline-ready representation out. The tool is open source on purpose. This plumbing should be free and boring, so the interesting work can happen downstream.