MarkItDown wird oft in dieselbe Schublade wie Web-Scraper gesteckt – und das ist schlicht falsch. Es hat keinen Crawler, keine JavaScript-Engine und auch keine Möglichkeit, eine URL abzurufen und das Seiten-Grundgerüst herauszuschneiden. Stattdessen nimmt es Bytes, die Sie schon haben – also ein PDF, ein Word-Dokument, eine Tabelle oder eine Präsentation – und wandelt das Ganze in Markdown um, das ein Sprachmodell lesen kann.
Ich habe Microsofts MarkItDown über zwei Wochen lang auf einem einzelnen Mac mit echten Dokumenten getestet, jede Tabelle gegen ein vorab erstelltes Manifest geprüft und jede Konvertierung gestoppt. Die Kurzfassung: Bei sauberen Eingaben ist das Tool schnell und zuverlässig, aber das Paket bringt eine 73-MB-Machine-Learning-Laufzeit mit, die man so nicht erwartet, und seine Tabellen brechen auf eine Art, die einen „Ist der Text noch da?“-Check bestehen kann, aber einen „Stehen die Daten in der richtigen Spalte?“-Check nicht. Hier ist das vollständige Bild – mit Zahlen.
Was MarkItDown eigentlich ist
MarkItDown ist ein Python-Tool von Microsoft, das Dateien und Office-Dokumente in Markdown umwandelt, optimiert für LLMs. Gib ihm ein PDF, eine .docx, .xlsx, .pptx, ein Bild, eine HTML-Datei oder einige andere Formate, und es liefert Markdown zurück. Drei Zugangswege sind vorgesehen: eine CLI (markitdown file.pdf -o out.md oder per stdin), eine Python-API (MarkItDown().convert(...)) und optional ein MCP-Server für Agenten-Workflows.
Am wichtigsten ist aber, was es nicht tut – und genau das steht so auch nicht im README, was ich in Tests bestätigt habe: kein Crawling, kein JS-Rendering, kein Folgen von Links, kein Paginieren und auch keine Main-Content-Extraktion wie bei Readability-Tools. Es ist ein Konverter für ganze Dokumente. Du bringst die Bytes mit, es standardisiert sie. Genau dieser Unterschied entscheidet, ob das Tool in deinen Stack passt oder nicht – deshalb komme ich immer wieder darauf zurück.
Das Repo selbst ist nach GitHubs Popularitätsmetriken ein Schwergewicht: 165.282 Sterne und 11.790 Forks Mitte Juli 2026, unter MIT-Lizenz, mit dem neuesten Release (v0.1.6) vom 26.05.2026. Diese Sternzahl zeigt aber eher ein Microsoft-Repo, das von der allgemeinen LLM-Tooling-Euphorie mitgezogen wird, als die Reife der eigentlichen Konvertierungslogik. Es gibt außerdem 833 offene Issues – und einige davon solltest du vor der Installation kennen (mehr dazu unten).
HTML zu Markdown: schnell und vollständig, Boilerplate inklusive
Da der Rest meiner Scraper-Testreihe auf denselben vier Web-Fixtures basiert, habe ich MarkItDown dieselben lokalen HTML-Dateien gegeben – nicht um es als Scraper zu bewerten, sondern um zu sehen, wie gut die HTML-zu-Markdown-Konvertierung ist. Auf sauber ausgezeichneten Seiten ist sie wirklich gut.
Alle vier Seiten ließen sich mit der Grundinstallation ohne Zusatzpakete konvertieren, und jeder Inhaltstest bestand. Der Wikipedia-Artikel „Web scraping“ (226 KB) kam mit sauber gespiegelt Strukturbaum heraus – ein h1, sieben h2s, zwölf h3s, passend zur echten Abschnittsstruktur des Artikels – und 418 Links wurden korrekt als [Text](url) erhalten. Die 26×9-Hockey-Statistik-Tabelle auf der Scrape This Site forms page wurde zu einer sauberen GFM-Pipetabelle mit 27 Zeilen (Kopf + Trennzeile + 26 Datenzeilen), inklusive leerer Zellen. Bei der Geschwindigkeit gab es ebenfalls keine Probleme: Median 48 ms für die kleine Quotes-Seite bis 352 ms für die 226-KB-Wikipedia-Seite.
Der Haken ist allerdings eine bewusste Designentscheidung, kein Bug. MarkItDown entfernt kein Boilerplate. Es konvertiert den gesamten <body>, also läuft Seiten-Chrome mit durch – und der Rest wird umso größer, je mehr Chrome die Seite hat.
| Seite | Ausgabezeichen | Überschriften (h1/h2/h3) | Links | Zeilen mit Seiten-Chrome |
|---|---|---|---|---|
| Books to Scrape | 10.478 | 1 / 0 / 0 | 94 | 0,6% (1/159) |
| Quotes to Scrape | 2.973 | 1 / 1 / 0 | 55 | 1,2% (1/86) |
| ScrapeThisSite forms | 3.385 | 1 / 0 / 0 | 31 | 6,7% (5/75) |
| Wikipedia Web scraping | 60.159 | 1 / 7 / 12 | 418 | 12,4% (42/338) |
Auf der fast chrome-freien Books-Startseite bestehen nur 0,6% der Ausgabezeilen aus Seiten-Chrome. Auf Wikipedia sind es 12,4% – 42 von 338 nicht-leeren Zeilen sind Dinge wie „zum Inhalt springen“, „Inhaltsverzeichnis ein-/ausblenden“, „22 Sprachen“, „abgerufen von“, Cookie- und Lizenz-Footer. Diese Wikipedia-Wartungsbanner („Dieser Artikel benötigt zusätzliche Quellen“) werden sogar sauber in zweispaltige Pipe-Tabellen gerendert – daher kommen auf einer Seite ohne echte Datentabelle neun Tabellenzeilen zustande.
Das ist kein Fehlverhalten von MarkItDown. Es ist ein Konverter für ganze Dokumente, kein Readability-Extractor: sauberes HTML-zu-Markdown ist etwas anderes als eine saubere Artikel-Extraktion. Tools wie Trafilatura oder Firecrawl zielen darauf ab, nur den Hauptinhalt zu liefern; MarkItDown liefert die ganze Seite. Intern entfernt _html_converter.py <script> und <style>, gibt den gesamten Body dann an die Bibliothek markdownify weiter – ohne irgendeine Main-Content-Heuristik. Wenn du nur den Artikel willst, ist das die falsche Ebene.
Das eigentliche Einsatzgebiet: PDF, DOCX, XLSX, PPTX
Für Dokumente ist MarkItDown gebaut. Ich habe es an echten öffentlichen Dateien getestet – einem arXiv-Paper mit Textlayer, dem Bitcoin-Whitepaper, einem reinen Bild-Scan-PDF ohne Text, das ich so gerendert habe, und den DOCX/XLSX/PPTX-Dateien aus dem eigenen Test-Set von MarkItDown (mit UUIDs als Sentinel, damit ich stillen Inhaltsverlust erkennen konnte).
| Dokument | Input | Ausgabezeichen | Prüfungen | Medianzeit | Hinweis |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF mit Textlayer) | 2,2 MB | 40.174 | 7/7 | 3,7 s (warm) | Titel, „Transformer“, „BLEU“, „References“ alle vorhanden |
| Bitcoin-Whitepaper (9 Seiten PDF) | 184 KB | 22.485 | 6/6 | 1,4 s | „Satoshi Nakamoto“, „proof-of-work“, „Conclusion“ vorhanden |
| Gescanntes PDF (ohne Textlayer) | 89 KB | 0 | 0/4 | 15 ms | leere Ausgabe, kein Fehler, kein OCR |
| DOCX (test.docx) | 136 KB | 4.651 | — | 70 ms | Überschriften + GFM-Tabelle; eingebettete UUIDs bleiben erhalten |
| DOCX mit Gleichungen | 15 KB | 240 | — | 101 ms | Office Math als LaTeX erhalten |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | jedes Sheet → ## SheetName + GFM-Tabelle |
| PPTX (test.pptx) | 278 KB | 2.047 | — | 52 ms | Marker für Foliennummern, Tabellen, Diagramm → Tabelle |
Der Texterhalt bei den PDFs mit Textlayer war exzellent – 7 von 7 vorab definierten Prüfungen beim arXiv-Paper „Attention Is All You Need“, 6 von 6 beim Bitcoin-Whitepaper – und keines der Office-Dokumente verlor auch nur einen UUID-Sentinel. Also kein stiller Inhaltsverlust bei den Regression-Fixtures der Maintainer. Ein schöner, sehr spezieller Pluspunkt: Der DOCX-Pfad (über mammoth) erhält Office-Math-Gleichungen als LaTeX und wandelt equations.docx in echtes $$...$$-Math um. Wenn du mathematisch schwere Word-Dokumente in ein LLM schickst, ist das ein echter – wenn auch sehr spezifischer – Vorteil, den ich sonst nirgends gut dokumentiert gefunden habe.
Zwei Ergebnisse auf diesem Gebiet verdienen besondere Aufmerksamkeit, weil sie dir am ehesten auf die Füße fallen.
Das gescannte PDF, das verschwindet
Wenn du MarkItDown ein bildbasiertes PDF ohne Textlayer gibst, kommt nur ein leerer String zurück. Null Zeichen, keine Ausnahme, keine Warnung – in etwa 15 ms konvertiert, weil nichts extrahiert werden kann. Der PDF-Pfad von MarkItDown macht nur Textextraktion (unter der Haube pdfminer und pdfplumber) und liefert im Core-Setup sowie in keinem der pip-Extras OCR mit.
Das ist in Batch-Szenarien ein Problem. Wer einen Ordner mit PDFs verarbeitet, in dem einige Dateien Scans sind, bekommt für genau diese Dateien still und leise leere Ergebnisse – ohne Hinweis, dass etwas übersprungen wurde. Ich habe ausgeschlossen, dass das Testobjekt kaputt ist, indem ich pdfminers extract_text direkt darauf ausgeführt habe – ebenfalls null erkennbare Zeichen, kein Textlayer, bestätigt. Die leere Ausgabe ist also das reale Verhalten von MarkItDown bei einem echten Scan. Das entspricht der seit langem offenen OCR-Fallback-Lücke (#1268), die upstream schon länger verfolgt wird. Der dokumentierte Weg führt über das optionale Azure Document Intelligence Backend oder ein Plugin – beides ist in der Standardinstallation nicht enthalten.
PDFs kommen als Fließtext heraus, nicht als Struktur
Über beide PDFs mit Textlayer hinweg erzeugte MarkItDown null Markdown-Überschriftenmarker. Ein PDF enthält keine semantischen Heading-Tags, und MarkItDown leitet sie auch nicht aus der Schriftgröße ab; daher landet jede Zeile auf Body-Ebene. Der Texterhalt ist hoch, die Struktur flach.
Das ist nicht nur mein Befund. Öffentliche Drittanbieter-Benchmarks geben MarkItDown bei der PDF-Überschriftenhierarchie etwa 0,0 und bei der Tabellenqualität ungefähr 0,27 – deutlich unter Doclings 0,88 mit TableFormer (siehe den Vergleich MarkItDown vs Docling vs Marker und den READoc-Benchmark). Meine Tests reproduzieren das, was die Evidenz stärkt: Meine Zahlen stimmen mit einer externen Quelle überein. Der gleiche Benchmark-Vergleich zeigt aber auch den Trade-off: MarkItDown ist ungefähr 100-mal schneller als Docling, was zu meinen Laufzeiten in Sekunden statt Minuten passt, während Layout-Modelle minutenlang rechnen. Die Quintessenz: MarkItDown liefert sauberen, schnellen PDF-Text; die PDF-Struktur liefert es nicht. Wenn Überschriften und Tabellen erhalten bleiben müssen, ist ein Layout-Tool wie Docling oder Marker die richtige Ebene.
Tabellen: Inhalt bleibt meist erhalten, Struktur nicht immer
Bei Tabellen trennen sich „Ist der Text noch da?“ und „Ist die Datenstruktur noch brauchbar?“, deshalb habe ich eine Matrix aus 13 Fällen gebaut – pro Fall eine <table>, jeweils gegen ein vor dem Lauf geschriebenes Manifest bewertet – um genau zu sehen, welche Formen funktionieren und welche brechen.
Die wichtigste Aussage: MarkItDown verlor nie Tabelleninhalt. In allen 13 Fällen blieben 100% der vorab registrierten Tokens erhalten. Die strukturelle Treue teilte sich allerdings in drei Gruppen. Sieben von 13 Fällen wurden zu einem sauberen GFM-Raster (einfache Tabellen, Kopfzeilen mit colspan, 24 Spalten breit, Tabellen ohne Kopfzeile, leere Zellen, Block-in-Zelle und rechts-nach-links-Arabisch). Vier wurden unordentlich, weil Markdown kein Konzept für zusammengefasste Zellen hat – daher führen rowspan, colspan und fehlerhafte Quellen zu kurzen Zeilen. Und zwei waren schlicht kaputt.
Die beiden Fehler sind erwähnenswert. Eine verschachtelte Tabelle (<table> in einem <td>) wird inline plattgezogen, inklusive ihrer eigenen Pipes und Trennzeile in der Elternzelle, was eine 14-„spaltige“ Müllzeile erzeugt. Und ein literales | in einer Zelle wird nicht escaped – Zelltext a | b wird zu zwei Spalten, x || y zu drei – dadurch erzeugt eine zweispaltige Tabelle Zeilen mit zwei, drei und vier Spalten, und jeder nachgelagerte Markdown-Parser liest die Grenzen falsch. Kurioserweise werden Sternchen und Backticks in Zellen doch escaped; nur Pipes nicht. Die Ursache: Der HTML-Pfad von MarkItDown nutzt das Standardverhalten von markdownify für Tabellen, und die eigene Unterklasse überschreibt Links, Bilder und Überschriften, aber nicht Tabellenzellen. Dieselbe Bug-Klasse beim Pipe-Escaping ist auch als offenes Issue für den CSV-Konverter (#2019) erfasst – allerdings betrifft der Fix nicht den HTML-Pfad, den ich getestet habe.
Der heikle Punkt – und der Befund, den ich am liebsten einem Data Engineer zeigen würde – ist rowspan. Fall t03 wird nicht nur unordentlich; er richtet Daten stillschweigend falsch aus. Ein rowspan=2-Label („Fruit“) wird nur einmal ausgegeben, und die Zeile darunter wird zu einer kurzen Zwei-Spalten-Zeile (| Banana | 8 |), sodass „Banana“ unter der Spalte Group statt Item landet. Alle Tokens sind vorhanden. Ein naiver Verbraucher, der einfach die zweite Spalte liest, bekommt den falschen Wert. Genau das ist die Art Fehler, die einen Text-Check besteht und Daten unbemerkt korrumpiert.
Die span-bezogene Einschränkung selbst ist eine bekannte, dokumentierte Designgrenze (#1211, #1248) – ein flaches GFM-Piperaster kann Spans oder Verschachtelungen tatsächlich nicht abbilden, also tauscht der Konverter Struktur gegen Vollständigkeit des Inhalts. Es gibt aber auch gute Verhaltensweisen: Tabellen ohne Kopfzeile erhalten eine synthetische leere Kopfzeile, damit keine Daten stillschweigend zu Überschriften werden; leere Zellen bleiben erhalten; und <caption> erscheint als Textzeile über der Tabelle.
Installation und Start: die Rechnung, die eine „leichte Utility“ verschweigt
Nichts hat mich hier mehr überrascht – und genau hier verspricht das Label „leichtes Python-Utility“ still und leise zu viel.
Erstens: Installiere nicht pip install 'markitdown[all]'. Unter Python 3.14 fällt die Auflösung still auf markitdown 0.0.2 zurück – ein Release von vor zwei Jahren. Das habe ich in einer sauberen venv live reproduziert. Warum, zeigt ein genauerer Blick: pip install 'markitdown[all]==0.1.6' schlägt fehl, weil das [all]-Extra youtube-transcript-api~=1.0.0 festpinnt. Auf PyPI sind in diesem Bereich inzwischen alle Builds für Python <3.14 gesperrt, während die einzigen 3.14-kompatiblen Builds außerhalb dieser Pin-Grenze liegen. Also weicht der Resolver bis zu dem letzten Release zurück, dessen Abhängigkeiten noch auflösbar sind. Das entspricht einem offenen Upstream-Issue (#2179). Der einfache Workaround: Version fest pinnen und Extras einzeln installieren – pip install 'markitdown==0.1.6', dann pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Diese Kombinationen lösen sauber auf; nur das gebündelte [all]-Paket enthält den problematischen Pin. (Dieser Fall hängt von der Python-Version ab – unter Python 3.13 oder älter greift die Sperre möglicherweise nicht, daher kann sich [all] anders verhalten.)
Zweitens: der Footprint. Die Core-Installation beträgt 161 MB (eine leere venv mit 13 MB plus 148 MB). Davon entfallen auf onnxruntime (73 MB) und numpy (34 MB) zusammen 107 MB – also 66% des gesamten Core-Footprints – und beides wird durch eine einzige harte Abhängigkeit hereingezogen: magika, Googles ML-Dateityp-Erkennung. Ein Textkonverter bringt also schon im Basis-Setup eine 73-MB-ONNX-Inferenzruntime mit, noch bevor du auch nur ein Dokument-Extra installierst. Mit den Dokument-Extras wächst die venv auf 310 MB. Das ist deutlich leichter als ein Headless-Browser-Stack, aber wenn du ein pip install-und-fertig-Mikrowerkzeug erwartet hast, solltest du wissen, dass eine ONNX-Runtime mitgeliefert wird.
Drittens – und das ist die einzige Beobachtung in meinem gesamten Testpaket, die jeden Neuheitscheck bestanden hat – kostet schon import markitdown nach einer sauberen Installation auf dieser Maschine rund 3,35 Sekunden. Die Kosten fallen fast komplett beim Import an: markitdown._markitdown lädt sofort das gesamte Konverter-Register (kumuliert 2,56 s, also 76% der Gesamtzeit), was pandas (594 ms, über den XLSX-Konverter), python-pptx (427 ms), magika (354 ms) und requests (270 ms) nachzieht – selbst wenn du keines dieser Formate überhaupt konvertierst. Für einen langlaufenden Dienst ist diese Zeit amortisiert und egal. Für einen CLI-Aufruf oder einen Serverless-Cold-Start ist es aber eine echte prozessbezogene Steuer, die man bei einem „leichten Utility“ nicht erwarten würde. (Fairer Hinweis: Das ist ein einzelner Profiling-Lauf, also eine einzelne Beobachtung und keine Verteilung aus vielen Runs.)
Skalierung: kein Crash, aber CPU für PDFs und RAM für Tabellen einkalkulieren
Ich habe vier große Fälle durchgeschoben, jeweils in einem eigenen Prozess, damit der Peak-RAM nicht durch einen vorherigen Lauf verfälscht wurde. Nichts ist abgestürzt. Das Kostenprofil ist aber eindeutig schief.
| Fall | Input | Ausgabezeichen | Medianzeit | Peak-RSS-Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF mit 492 Seiten) | 5,9 MB | 1.625.365 | 192,5 s | +40 MB |
| XLSX 50.000 Zeilen × 8 Spalten | 2,1 MB | 3.722.955 | 62,1 s | +374 MB |
| arXiv 1706.03762 (~15-seitiges PDF) | 2,2 MB | 40.174 | 12,6 s | +25 MB |
| XLSX 200 Zeilen × 64 Spalten | 46 KB | 120.129 | 2,9 s | +22 MB |
Das 492-seitige NIST-PDF brauchte im Median 192,5 Sekunden – also rund 3,2 Minuten bzw. 0,39 s/Seite – weil pdfplumber auf jeder Seite eine Formular-/Layout-Erkennung über Wortpositionen ausführt. Der Peak-RAM blieb bei +40 MB, es ist also CPU- und nicht speichergebunden. Selbst das 15-seitige arXiv-PDF brauchte in einem isolierten Prozess 12,6 Sekunden, also etwa 3,4-mal so lange wie die 3,7 Sekunden, die dieselbe Datei in meinem Dokument-Set im Warmzustand zeigte. Diese Differenz ist die Kosten des kalten Prozesses und bestätigt, dass die Seitenarbeit der Treiber ist – nicht die reine Byte-Menge. Wenn du für dieses PDF eine einzelne übertragbare Zahl willst, nimm die isolierten 12,6 Sekunden.
Der Tabellenpfad dreht den Engpass um. Ein 2,1-MB-XLSX mit 50.000 Zeilen explodierte auf +374 MB Peak-RSS (und 3,7 Millionen Ausgabezeichen), weil der Konverter das ganze Sheet lädt und einen großen Markdown-String im Speicher aufbaut. Die praktische Empfehlung ist also klar: Für große PDFs Minuten an CPU einplanen; für große Tabellen mehrere hundert MB RAM. Das sind Einzelmaschinenwerte auf macOS arm64 und Python 3.14, und die Konstanten pro Seite bzw. pro Zeile sind plattformspezifisch – aber die Form des Ergebnisses (PDF ist langsam und CPU-lastig, XLSX ist speicherhungrig, nichts crasht) überträgt sich.
Wo Thunderbit passt – und wo nicht
Thunderbit für Web-Datenextraktion testen
Das ist der Vergleich, bei dem man sich leicht zu weit aus dem Fenster lehnen könnte, also ziehe ich die Grenze bewusst sauber. MarkItDown und Thunderbit lösen verwandte, aber nicht dieselben Probleme.
MarkItDown konvertiert Dateien, die Sie bereits haben. Thunderbit ruft zuerst die Seite ab. Der /distill-Endpunkt von Thunderbit verwandelt eine Live-Webseite in sauberes, LLM-taugliches Markdown – inklusive JS-Rendering, Anti-Bot-Hürden und dynamischer Inhalte, für die MarkItDown keine Mechanik hat – und der /extract-Endpunkt liefert schematisch passende, strukturierte JSON-Daten statt nur rohem Markdown. Für Entwickler ist das als API (POST /distill / POST /extract), MCP-Server und CLI (npx @thunderbit/thunderbit-cli) über eine einzige AI-Engine verfügbar – dieselbe, die auch hinter der Extension mit über 100.000 Nutzern steht.
Die Überschneidung besteht also nur in einem Punkt: Beide können „LLM-ready Markdown“ ausgeben. Der Eingabebereich ist aber unterschiedlich: Thunderbits Distill nimmt eine URL aus dem offenen Web, MarkItDown nimmt eine lokale Datei. Sie sind keine 1:1-Ersatzprodukte, und ich tue auch nicht so. Ein realistischer Stack nutzt beide: Das Web mit Thunderbit (oder einem Firecrawl-ähnlichen Dienst) abrufen und crawlen, dann die gemischten lokalen Dokumente, die Sie ebenfalls haben – also PDFs, Decks und Tabellen – mit MarkItDown normalisieren. Das eine erledigt das Netzwerk, das andere den Aktenschrank.
Vor- und Nachteile
Stärken
- Vollständiger Inhaltserhalt bei sauberem HTML (4/4 Seiten), inklusive Überschriftenstruktur und Links
- Hoher PDF-/DOCX-Texterhalt (arXiv 7/7 Prüfungen, Bitcoin 6/6) und kein stiller Inhaltsverlust bei den Office-Fixtures der Maintainer
- Office-Math-Gleichungen bleiben als LaTeX erhalten – ein echter Nischenvorteil
- Kein Absturz bei den getesteten Größen, bis hin zu einem 492-seitigen PDF und einem XLSX mit 50.000 Zeilen
- Einfach anzusprechen: CLI,
convert(), stdin-Piping und optionaler MCP-Server - MIT-lizenziert, aktiv von Microsoft gepflegt, reagierender Issue-Tracker
Schwächen
- Lässt Boilerplate drin – auf Wikipedia bis zu 12,4% Chrome-Zeilen; kein Artikel-Extractor
- Tabellen brechen bei Spans, Verschachtelung und Pipes in Zellen (2/13 kaputt, 4/13 unruhig), und rowspan kann Daten stillschweigend in die falsche Spalte schieben
- Gescannte/bildbasierte PDFs liefern leere Ausgabe ohne OCR und ohne Fehler
- PDF-Ausgabe hat keine Überschriftenstruktur (entspricht öffentlichen Benchmarks)
- 161-MB-Core-Installation mit 73-MB-ONNX-Runtime; rund 3,35 s Kaltimport
- Das
[all]-Extra fällt unter Python 3.14 still auf die zwei Jahre alte Version 0.0.2 zurück
Für wen es geeignet ist – und für wen nicht
Greif zu MarkItDown, wenn du einen Stapel gemischter lokaler Dokumente – Word, Excel, PowerPoint, PDFs mit Textlayer – für eine LLM-Pipeline in Markdown standardisieren willst und dir vollständiger Text wichtiger ist als eine exakt erhaltene Struktur. Als Last-Mile-Konverter in einem Batch-Job, der sauber textbasierte Eingaben an ein Modell liefert, ist es schnell, zuverlässig und kostenlos.
Lass es lieber weg – oder kombiniere es mit einem anderen Tool –, wenn deine Aufgabe eine dieser ist: Du willst nur den Hauptartikel aus einer Webseite (dafür nimmt man ein Readability- oder Firecrawl-ähnliches Tool); du brauchst, dass die Überschriften und Tabellen eines PDFs vollständig erhalten bleiben (dafür ist eher Docling oder Marker zuständig); oder deine Eingaben enthalten gescannte Dokumente, die OCR erfordern (dafür brauchst du das Azure-Backend oder ein ganz anderes Tool). Und falls du eigentlich einen Scraper gesucht hast – also etwas, das abruft und crawlt –, dann ist das hier nicht gemeint.
Die vorläufige Bewertung, die ich mit einem scraper-artigen Raster vorgenommen habe, landet für MarkItDown bei 60/100 – und dieses niedrige Ergebnis ist ein Artefakt davon, dass ein Konverter mit den Prüfungen eines Crawlers bewertet wird. Auf dem eigenen Terrain sind die Texttreue-Werte hoch; die Schwächen liegen eher in der Struktur (Tabellen, PDF-Überschriften) und im Packaging (Footprint, Import, [all]-Falle) als in der Textqualität. Wenn man es so beurteilt, wie es ist – ein Datei-zu-Markdown-Konverter –, ist es ein solides, gut gepflegtes Tool mit ein paar scharfen Kanten, die man kennen sollte, bevor man es produktiv einsetzt.
Häufig gestellte Fragen
Ist MarkItDown ein Web-Scraper?
Nein. Es hat keinen Crawler, kein JavaScript-Rendering, kein Link-Following und kein Paginieren. Es konvertiert Dateien und Dokumente, die Sie bereits haben – PDF, DOCX, XLSX, PPTX, Bilder, HTML – in Markdown. Wenn du Live-Webseiten abrufen und crawlen musst, brauchst du ein Scraping-Tool wie Thunderbit oder Firecrawl; MarkItDown ist der Schritt danach und macht aus abgerufenen oder lokalen Dateien sauberes Markdown.
Warum installiert pip install markitdown[all] eine alte Version?
Unter Python 3.14 pinnt das [all]-Extra youtube-transcript-api~=1.0.0, und alle Builds in diesem Bereich sind für Python-Versionen unter 3.14 freigegeben. Der Resolver kann diesen Pin nicht erfüllen und fällt deshalb still auf markitdown 0.0.2 zurück, ein Release von vor zwei Jahren. Die Lösung: Version fest pinnen und Extras einzeln installieren: pip install 'markitdown==0.1.6', danach pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Das ist als Issue #2179 erfasst.
Macht MarkItDown OCR bei gescannten PDFs?
Nicht in der Standardinstallation. Der PDF-Pfad macht nur Textextraktion, daher liefert ein bildbasiertes PDF ohne Textlayer einen leeren String – ohne Fehler, ohne Warnung. OCR erfordert das optionale Azure Document Intelligence Backend oder ein Plugin, von denen keines standardmäßig mitgeliefert wird. Auch das ist eine seit Langem bekannte Lücke (Issue #1268).
Wie gut kommt MarkItDown mit Tabellen klar?
Inhaltlich sehr gut – in meinem 13-Fälle-Test blieb in jedem Fall 100% des Tabelleninhalts erhalten. Strukturell hängt es von der Form ab: Einfache, breite, kopflose Tabellen und Tabellen mit leeren Zellen kommen als saubere GFM-Raster heraus, aber rowspan und colspan werden unordentlich (und rowspan kann Daten stillschweigend in die falsche Spalte verschieben), verschachtelte Tabellen werden zu Müllzeilen plattgezogen, und echte Pipe-Zeichen in Zellen werden nicht escaped. Das flache Markdown-Tabellenformat kann Spans oder Verschachtelungen schlicht nicht darstellen.
Ist MarkItDown schnell genug für große Dokumente?
Es stürzt bei großen Dateien nicht ab, aber du solltest die Ressourcen nach Typ budgetieren. Ein PDF mit 492 Seiten brauchte etwa 3,2 Minuten (rund 0,39 s/Seite), weil pro Seite eine Formularerkennung läuft und das Ganze CPU-lastig ist. Eine Tabelle mit 50.000 Zeilen war in etwa einer Minute fertig, verbrauchte aber +374 MB RAM, weil ein großer Markdown-String im Speicher aufgebaut wird. Für große PDFs also Minuten an CPU einplanen; für große Tabellen mehrere hundert MB RAM.
Thunderbit für Web-Datenextraktion testen Get Started Free
