MarkItDown wird oft in dieselbe Schublade wie Web-Scraper gesteckt – und das stimmt einfach nicht. Es gibt darin weder einen Crawler noch eine JavaScript-Engine, und auch keine Möglichkeit, eine URL abzurufen und den sichtbaren Inhalt vom ganzen Ballast zu trennen. Stattdessen nimmt es Daten, die schon da sind — also zum Beispiel ein PDF, ein Word-Dokument, eine Tabelle oder eine Präsentation — und wandelt alles in Markdown um, das ein Sprachmodell lesen kann.
Ich habe Microsofts MarkItDown über mehrere Wochen hinweg mit echten Dokumenten auf einem einzelnen Mac getestet, jede Tabelle gegen ein vorab erstelltes Manifest geprüft und jede Konvertierung gemessen. Die Kurzfassung: Bei sauberen Eingaben ist das Tool schnell und zuverlässig, die Verpackung versteckt aber eine 73-MB-ML-Laufzeitumgebung, die man nicht bestellt hat, und Tabellen zerbrechen auf Arten, die einen „Ist der Text noch da?“-Check bestehen, aber bei „Steht die Zahl in der richtigen Spalte?“ durchfallen. 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 für LLMs optimiertes Markdown umwandelt. Du gibst ihm ein PDF, .docx, .xlsx, .pptx, ein Bild, eine HTML-Datei oder einige andere Formate, und es liefert Markdown zurück. Es gibt drei Wege zur Nutzung: per CLI (markitdown file.pdf -o out.md oder über stdin), per Python-API (MarkItDown().convert(...)) und optional über einen MCP-Server für Agent-Workflows.
Der wichtigste Punkt ist aber, was es nicht tut — und das wird im README auch nicht behauptet, was ich im Test bestätigt habe: kein Crawling, kein JS-Rendering, kein Folgen von Links, kein Paging und keine Extraktion des Hauptinhalts wie bei Readability-Tools. Es ist ein Konverter für komplette Dokumente. Du bringst die Bytes mit; das Tool bringt sie in eine einheitliche Form. Genau dieser Unterschied entscheidet darüber, ob das Tool in deinen Stack gehört oder nicht — deshalb komme ich darauf immer wieder zurück.
Das Repo ist gemessen an GitHub-Metriken ein echtes Schwergewicht: 165.282 Sterne und 11.790 Forks Mitte Juli 2026, MIT-lizenziert, mit dem neuesten Release (v0.1.6) vom 26.05.2026. Die hohe Sternzahl sagt aber vor allem etwas über die allgemeine Begeisterung für LLM-Tools aus — nicht über die Reife der Konvertierungslogik. Außerdem gibt es 833 offene Issues, und einige davon solltest du kennen, bevor du es installierst (dazu gleich mehr).
HTML zu Markdown: schnell und vollständig, inklusive Seitenballast
Weil der Rest meiner Scraper-Review-Reihe mit denselben vier Web-Fixpunkten arbeitet, habe ich MarkItDown die identischen 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 strukturierten Seiten ist das Ergebnis wirklich gut.
Alle vier Seiten liefen mit der Standardinstallation ohne Zusatzpakete, und jede einzelne Body-Inhaltsprobe blieb erhalten. Der Wikipedia-Artikel „Web scraping“ (226 KB) kam mit seiner Überschriftenstruktur korrekt heraus — ein h1, sieben h2 und zwölf h3, also passend zur echten Abschnittsstruktur des Artikels — und 418 Links wurden als saubere [Text](URL)-Links bewahrt. Die 25×9-Hockey-Statistik-Tabelle auf der Scrape-This-Site-Formularseite wurde zu einer sauberen GFM-Pipe-Tabelle mit 27 Zeilen (Kopf + Trennzeile + 26 Datenzeilen), inklusive leerer Zellen. Auch die Geschwindigkeit war hier kein Thema: Median 48 ms für die kleine Quotes-Seite bis 352 ms für die 226-KB-Wikipedia-Seite.
Der Haken ist allerdings ein Designentscheid, kein Fehler. MarkItDown entfernt keinen Seitenballast. Es konvertiert den gesamten <body>, also bleibt das Seitengerüst mit drin — und die Menge dieses Ballasts steigt mit der Menge an Chrome auf der Seite.
| Seite | Ausgabesymbole | Überschriften (h1/h2/h3) | Links | Zeilen mit Seitengerüst |
|---|---|---|---|---|
| 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-Formulare | 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 nahezu ballastfreien Books-Startseite sind 0,6 % der Ausgabelinien Seitenchrome. Auf Wikipedia sind es 12,4 % — 42 von 338 nichtleeren Zeilen sind etwa „Jump to content“, „Inhaltsverzeichnis ein-/ausblenden“, „22 languages“, „abgerufen von“, Cookie- und Lizenz-Fußzeilen. Die Wartungsbanner der Wikipedia-Seite („Dieser Artikel benötigt zusätzliche Belege“) werden sogar korrekt in zweispaltige Pipe-Tabellen umgewandelt, wodurch auf einer Seite ohne echte Datentabelle neun Tabellenzeilen entstehen.
Das ist kein Fehlverhalten von MarkItDown. Es ist ein Konverter für komplette Dokumente, kein Readability-Extractor: Eine saubere HTML-zu-Markdown-Umwandlung ist etwas anderes als eine gute Artikel-Extraktion. Trafilatura und Firecrawl-ähnliche Tools wollen nur den Hauptinhalt zurückgeben; MarkItDown gibt die ganze Seite zurück. Unter der Haube entfernt _html_converter.py <script> und <style> und übergibt dann den gesamten Body an die markdownify-Bibliothek — ohne irgendeine Main-Content-Heuristik. Wenn du nur den Artikel willst, ist das die falsche Ebene.
Das eigentliche Terrain: PDF, DOCX, XLSX, PPTX
Für Dokumente ist MarkItDown gebaut. Ich habe es mit echten öffentlichen Dateien getestet — einem arXiv-Paper mit Textschicht, dem Bitcoin-Whitepaper, einem eingescannten PDF ohne Text, das ich aufbereitet habe, sowie den DOCX/XLSX/PPTX-Dateien aus dem eigenen Testset von MarkItDown (mit UUIDs versehen, damit ich stillen Datenverlust erkennen konnte).
| Dokument | Eingabe | Ausgabesymbole | Prüfpunkte | Medianzeit | Hinweise |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF mit Textschicht) | 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 (keine Textschicht) | 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 | Foliennummern-Markierungen, Tabellen, Diagramm → Tabelle |
Die Texterkennung auf den PDFs mit Textschicht war ausgezeichnet — 7 von 7 vorab definierten Prüfstellen im arXiv-Paper „Attention Is All You Need“, 6 von 6 im Bitcoin-Whitepaper — und keine der Office-Dateien verlor auch nur einen einzigen UUID-Platzhalter. Also kein stiller Contentverlust in den Regressionstest-Dateien der Maintainer. Ein schöner, enger Pluspunkt: Der DOCX-Pfad (über mammoth) bewahrt Office-Math-Gleichungen als LaTeX und macht aus equations.docx echte $$...$$-Mathematik. Wenn du mathematisch schwere Word-Dokumente in ein LLM gibst, ist das ein echter, wenn auch spezieller Vorteil, den ich so sonst nirgends dokumentiert gefunden habe.
Zwei Befunde auf diesem Terrain verdienen besondere Aufmerksamkeit, weil sie dir am ehesten Probleme machen.
Das gescannte PDF, das verschwindet
Wenn du MarkItDown ein bildbasiertes PDF ohne Textschicht gibst, kommt nur ein leerer String zurück. Null Zeichen, keine Ausnahme, keine Warnung — in etwa 15 ms konvertiert, weil schlicht nichts zu extrahieren ist. Der PDF-Pfad von MarkItDown arbeitet nur mit Textextraktion (unter der Haube pdfminer und pdfplumber) und bringt weder im Kernpaket noch in einem pip-Extra OCR mit.
In einem Batch ist das relevant. Wer einen Ordner mit PDFs verarbeitet, in dem auch Scans liegen, erhält für diese Dateien stillschweigend leere Ergebnisse, ohne dass signalisiert wird, dass etwas übersprungen wurde. Ich habe geprüft, dass die Testdatei nicht defekt ist, indem ich pdfminers extract_text direkt darauf angewendet habe — ebenfalls null extrahierte Zeichen, keine Textschicht, bestätigt — also ist die leere Ausgabe das echte Verhalten von MarkItDown bei einem echten Scan. Das reproduziert eine seit Langem offene 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 gehört nicht zur Standardinstallation.
PDFs kommen als Fließtext heraus, nicht als Struktur
Über beide PDFs mit Textschicht hinweg erzeugte MarkItDown exakt null Markdown-Überschriftenmarker. Ein PDF enthält keine semantischen Heading-Tags, und MarkItDown leitet sie nicht aus der Schriftgröße ab — also landet jede Zeile auf Body-Ebene. Die Textwiedergabe ist hoch, die Struktur flach.
Das ist nicht nur mein Ergebnis. Öffentliche Drittanbieter-Benchmarks bewerten die PDF-Überschriftenhierarchie von MarkItDown bei etwa 0,0 und die Tabellenqualität bei rund 0,27 — also deutlich unter Doclings TableFormer-basiertem 0,88 (siehe den MarkItDown-vs-Docling-vs-Marker-Vergleich und den READoc-Benchmark). Meine Tests reproduzieren das, was die Aussagekraft 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 mit meinen Sekunden- statt Minutenwerten auf Dokumenten zusammenpasst, für die ein layoutbasiertes Tool Minuten braucht. Die Quintessenz: MarkItDown liefert dir sauberen, schnellen PDF-Text; die PDF-Struktur liefert es nicht. Wenn Überschriften und Tabellen erhalten bleiben müssen, ist ein layoutbasiertes Tool wie Docling oder Marker die richtige Ebene.
Tabellen: Inhalt bleibt erhalten, Struktur nicht immer
Bei Tabellen trennen sich „Ist der Text noch da?“ und „Ist der Daten noch nutzbar?“. Deshalb habe ich eine 13-Fälle-Matrix gebaut — pro Fall eine <table>-Struktur, jeweils gegen ein vor dem Lauf geschriebenes Manifest bewertet — um genau zu sehen, welche Formen funktionieren und welche brechen.
Die Kernaussage: MarkItDown verlor nie Tabelleninhalt. In allen 13 Fällen blieben 100 % der vorregistrierten Tokens erhalten. Die strukturelle Treue war jedoch dreigeteilt. Sieben von dreizehn Fällen ergaben ein ordentliches GFM-Raster (einfache Tabellen, Header-Spalten-Span, 24 Spalten breit, ohne Header, mit leeren Zellen, Block-in-Zelle und rechts-nach-links Arabisch). Vier wurden unsauber, weil Markdown kein Konzept für überspannte Zellen hat, also liefern rowspan-, colspan- und fehlerhafte Quellen kurze Zeilen. Und zwei waren klar kaputt.
Die zwei Defekte sind nennenswert. Eine verschachtelte Tabelle (<table> in einer <td>) wird inline plattgezogen, wodurch die eigenen Pipes und die Trennzeile in die Elternzelle wandern und eine 14-„Spalten“-Zeile voller Müll entsteht. Und ein literales | in einer Zelle wird nicht escaped — Zelltext a | b wird zu zwei Spalten, x || y zu drei — sodass eine Zweispaltentabelle Zeilen mit zwei, drei und vier Spalten ausgibt, und jeder nachgelagerte Markdown-Parser die falschen Grenzen liest. Interessanterweise werden Sternchen und Backticks in Zellen sehr wohl escaped; Pipes eben nicht. Die Ursache: Der HTML-Pfad von MarkItDown verwendet das Standard-Tabellenverhalten von markdownify, und seine benutzerdefinierte Unterklasse überschreibt Links, Bilder und Überschriften, aber nicht Tabellenzellen. Dieselbe Pipe-Escaping-Bugklasse ist übrigens auch als offenes Issue für den CSV-Konverter (#2019) bekannt — dieser Fix betrifft aber nicht den von mir getesteten HTML-Pfad.
Der subtilere Punkt — und der Befund, den ich am liebsten einem Data Engineer zeigen würde — ist rowspan. Fall t03 wird nicht nur unordentlich, sondern verschiebt Daten stillschweigend. Ein rowspan=2-Label („Fruit“) erscheint nur einmal, 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 da. Ein naiver Verbraucher, der einfach „die zweite Spalte“ liest, bekommt den falschen Wert. Genau das ist die Art von Fehler, die einen Text-Existenzcheck besteht und dennoch leise ein Dataset verfälscht.
Die Einschränkung bei Spans selbst ist eine bekannte, dokumentierte Designgrenze (#1211, #1248) — ein flaches GFM-Pipe-Raster kann Spans und Verschachtelung schlicht nicht darstellen, also tauscht der Konverter Struktur gegen Vollständigkeit beim Inhalt. Es gibt aber auch gutes Verhalten: Tabellen ohne Header bekommen eine synthetische leere Kopfzeile (damit keine Daten unbemerkt zum Header werden), leere Zellen bleiben erhalten, und <caption> erscheint als Textzeile oberhalb der Tabelle.
Installation und Start: die Steuer, vor der ein „leichtgewichtiges Tool“ nicht warnt
Nichts hat mich hier mehr überrascht — und genau hier überzieht die Beschreibung als „leichtgewichtiges Python-Tool“ still und leise.
Erstens: Installiere nicht pip install 'markitdown[all]'. Unter Python 3.14 fällt das stillschweigend auf markitdown 0.0.2 zurück — also auf eine zwei Jahre alte Version. Das habe ich in einer frischen venv live reproduziert. Warum das passiert, zeigt ein Blick auf das Pinning: pip install 'markitdown[all]==0.1.6' schlägt fehl, weil das [all]-Extra youtube-transcript-api~=1.0.0 festnagelt, und auf dem aktuellen PyPI sind in diesem Bereich alle Builds auf Python <3.14 begrenzt; die einzigen mit Python 3.14 kompatiblen Builds liegen außerhalb dieses Pins. Also geht der Resolver ganz bis zur letzten Version zurück, deren Abhängigkeiten er erfüllen kann. Das entspricht einem offenen Upstream-Issue (#2179). Der saubere Weg ist einfach: Version festpinnen und Extras einzeln installieren: pip install 'markitdown==0.1.6', danach pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Diese Extras lösen jeweils sauber auf; nur das kombinierte [all]-Paket enthält den vergifteten Pin. (Dieser Stolperstein hängt von der Python-Version ab — unter Python 3.13 oder älter greift die Sperre möglicherweise nicht, sodass [all] anders aufgelöst wird.)
Zweitens: der Platzbedarf. Die Kerninstallation liegt bei 161 MB (eine leere venv mit 13 MB plus 148 MB). Davon entfallen 107 MB — also 66 % des gesamten Kernumfangs — auf onnxruntime (73 MB) und numpy (34 MB), und beides wird durch eine einzige harte Abhängigkeit hereingezogen: magika, Googles ML-Dateityp-Erkenner. Ein Textkonverter bringt also schon im Basis-Setup eine 73-MB-ONNX-Inferenzlaufzeit mit, noch bevor du irgendein Dokument-Extra installierst. Mit den Dokument-Extras wächst die venv auf 310 MB. Das ist deutlich schlanker als ein Headless-Browser-Stack — aber wenn du ein kleines pip install-und-fertig-Tool erwartet hast, solltest du wissen, dass eine ONNX-Laufzeit mitkommt.
Drittens — und das ist die einzelne Erkenntnis in meinem ganzen Testpaket, die jede Novelty-Prüfung bestanden hat — kostet schon der Import nach einer sauberen Installation auf diesem Rechner etwa 3,35 Sekunden. Die Kosten fallen fast vollständig beim Import an: markitdown._markitdown lädt die gesamte Konverter-Registry frühzeitig (2,56 s kumuliert, 76 % des Gesamtwerts), wodurch pandas (1,21 s, über den XLSX-Konverter), python-pptx (427 ms), magika (354 ms) und requests (270 ms) mitgeladen werden — selbst dann, wenn du diese Formate nie konvertierst. Für einen langlebigen Dienst ist das amortisiert und egal. Für einen CLI-Aufruf oder einen serverlosen Cold Start ist es jedoch eine echte Pro-Prozess-Steuer, die man bei einem „leichtgewichtigen Tool“ nicht erwartet. (Faire Einschränkung: Das ist ein einzelner Profiler-Durchlauf, also eine Beobachtung und keine Verteilung über viele Runs.)
Skalierung: Es stürzt nicht ab, aber plane CPU für PDFs und RAM für Tabellen ein
Ich habe vier große Fälle durch das Tool gejagt, jeweils in einem eigenen Prozess, damit der Peak-Speicher nicht von vorherigen Läufen verfälscht wurde. Nichts ist abgestürzt. Das Kostenprofil ist jedoch deutlich unausgewogen.
| Fall | Eingabe | Ausgabesymbole | Medianzeit | Peak-RSS-Änderung |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF, 492 Seiten) | 6,07 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 Seiten 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 etwa 3,2 Minuten bzw. 0,39 s/Seite — weil pdfplumber auf jeder Seite eine Wortpositions-/Form-Erkennung durchführt. Der Peak-RSS blieb bei +40 MB, also ist das Ganze CPU-gebunden und nicht speichergebunden. Selbst das 15-seitige arXiv-PDF brauchte in einem eigenen isolierten Prozess 12,6 Sekunden, also etwa 3,4-mal so viel wie die 3,7 Sekunden, die dieselbe Datei warm in meiner Dokumentensuite zeigte. Diese Differenz ist der Cold-Process-Effekt und bestätigt, dass die seitenweise Arbeit der Treiber ist — nicht die reine Dateigröße. Wenn du für dieses PDF nur einen übertragbaren Wert brauchst, nimm die isolierten 12,6 s.
Der Tabellenpfad dreht den Engpass um. Eine 2,1 MB große XLSX mit 50.000 Zeilen wuchs auf +374 MB Peak-RSS an (und erzeugte 3,7 Millionen Ausgabesymbole), weil der Konverter das ganze Sheet lädt und einen großen Markdown-String zusammensetzt. Die praktische Empfehlung ist deshalb klar: Bei großen PDFs Minuten an CPU einplanen; bei großen Tabellen hundert(e) MB RAM. Das sind Ein-Maschinen-Werte auf macOS arm64 und Python 3.14, und die pro Seite bzw. pro Zeile gemessenen Konstanten sind plattformspezifisch — aber die Form des Ergebnisses (PDF ist langsam und CPU-gebunden, XLSX ist speicherhungrig, nichts stürzt ab) ist übertragbar.
Wo Thunderbit passt — und wo nicht
Thunderbit für Web-Datenextraktion testen
Das ist der Vergleich, bei dem man am leichtesten überzieht — deshalb ziehe ich die Grenze bewusst sauber. MarkItDown und Thunderbit lösen benachbarte, aber nicht dieselben Probleme.
MarkItDown konvertiert Dateien, die du bereits hast. Thunderbit ruft die Seite zuerst ab. Der /distill-Endpunkt von Thunderbit verwandelt eine Live-Webseite in sauberes, LLM-taugliches Markdown — inklusive JavaScript-Rendering, Anti-Bot-Schutz und dynamischem Inhalt, für den MarkItDown keinerlei Mechanismus hat — und der /extract-Endpunkt liefert strukturiertes JSON, das einem Schema entspricht, nicht nur rohes Markdown. Für Entwickler ist das als API (POST /distill / POST /extract), als MCP-Server und als CLI (npx @thunderbit/thunderbit-cli) über eine gemeinsame KI-Engine verfügbar — dieselbe, die auch hinter der Erweiterung mit 100.000+ Nutzern steht.
Die Überschneidung besteht also genau in einem Punkt: Beide können „LLM-ready Markdown“ ausgeben. Aber die Eingabewelt ist verschieden: Thunderbits Distill nimmt eine URL aus dem offenen Web, MarkItDown nimmt eine lokale Datei. Das sind keine austauschbaren Werkzeuge — und ich tue nicht so, als wären sie es. Ein realistischer Stack nutzt beide: Das Web mit Thunderbit (oder einem Firecrawl-ähnlichen Dienst) abrufen und crawlen, dann die gemischten lokalen Dokumente — PDFs, Decks und Tabellen — mit MarkItDown normalisieren. Das eine erledigt das Netzwerk, das andere den Aktenschrank.
Vor- und Nachteile
Stärken
- Vollständige Body-Erfassung bei sauberem HTML (4/4 Seiten), inklusive korrekt erhaltener Überschriftenstruktur und Links
- Hohe PDF-/DOCX-Texttreue (arXiv 7/7 Prüfstellen, Bitcoin 6/6) und kein stiller Inhaltsverlust in den Office-Testdateien der Maintainer
- Office-Math-Gleichungen bleiben als LaTeX erhalten — ein echter Nischenvorteil
- Bei keinem Testfall abgestürzt, selbst bei einem 492-seitigen PDF und einer XLSX mit 50.000 Zeilen
- Einfach zu verwenden: CLI,
convert(), stdin-Piping und optional ein MCP-Server - MIT-lizenziert, aktiv von Microsoft gepflegt, reaktionsschneller Issue-Tracker
Schwächen
- Behält Seitenballast bei — 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 unordentlich), und rowspan kann Daten still verschieben
- Gescannte bzw. bildbasierte PDFs liefern leere Ausgabe ohne OCR und ohne Fehlermeldung
- PDF-Ausgabe hat keinerlei Überschriftenstruktur (entspricht öffentlichen Benchmarks)
- 161 MB Kerninstallation mit 73-MB-ONNX-Runtime; ca. 3,35 s Kaltstart-Import
- Das
[all]-Extra fällt unter Python 3.14 stillschweigend auf eine zwei Jahre alte 0.0.2 zurück
Für wen es geeignet ist — und für wen nicht
Greif zu MarkItDown, wenn du einen Haufen gemischter lokaler Dokumente — Word, Excel, PowerPoint, PDFs mit Textschicht — in Markdown für eine LLM-Pipeline standardisieren willst und dir vollständiger Text wichtiger ist als eine erhaltene Struktur. Als letzte Konvertierungsstufe in einem Batch-Job, die sauberen Text an ein Modell liefert, ist es schnell, zuverlässig und kostenlos.
Lass es weg oder kombiniere es mit etwas anderem, wenn deine Aufgabe eine der folgenden ist: Du brauchst nur den eigentlichen Artikel aus einer Webseite (dafür ist ein Readability- oder Firecrawl-ähnliches Tool besser geeignet); du musst die Überschriften und Tabellen eines PDFs unverändert bewahren (dafür sind Docling oder Marker die richtige Liga); oder deine Eingaben enthalten gescannte Dokumente, die OCR brauchen (dafür brauchst du das Azure-Backend oder ein anderes Tool). Und wenn du eigentlich einen Scraper gesucht hast — also etwas, das Seiten abrufen und crawlen kann — dann ist das hier schlicht nicht das richtige Werkzeug.
Die vorläufige Bewertung, die ich mit einem scraperartigen Raster vergeben habe, landet bei 60/100, und dieser niedrige Wert entsteht dadurch, dass ein Konverter an einem Crawler-Test gemessen wurde. Auf seinem eigenen Terrain sind die Texttreue-Werte hoch; die Schwächen liegen vor allem in der Struktur (Tabellen, PDF-Überschriften) und im Packaging (Footprint, Import, das [all]-Problem), nicht in der Textqualität. Wenn man es als das bewertet, was es ist — ein Datei-zu-Markdown-Konverter — dann ist es ein solides, gut gepflegtes Tool mit einigen scharfen Kanten, die man vor dem Produktionseinsatz kennen sollte.
Häufig gestellte Fragen
Ist MarkItDown ein Web-Scraper?
Nein. Es gibt keinen Crawler, kein JavaScript-Rendering, kein Folgen von Links und kein Paging. Es wandelt Dateien und Dokumente, die du bereits hast — PDF, DOCX, XLSX, PPTX, Bilder, HTML — in Markdown um. Wenn du Live-Webseiten abrufen und crawlen willst, 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 auf Python-Versionen unter 3.14 begrenzt. Der Resolver kann diesen Pin nicht erfüllen und fällt deshalb stillschweigend auf markitdown 0.0.2 zurück, eine zwei Jahre alte Version. Die Lösung ist, die Version festzupinnen und Extras einzeln zu installieren: pip install 'markitdown==0.1.6', dann pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Das wird in Issue #2179 verfolgt.
Macht MarkItDown OCR bei gescannten PDFs?
Nicht in der Standardinstallation. Der PDF-Pfad arbeitet nur mit Textextraktion, daher liefert ein bildbasiertes PDF ohne Textschicht einen leeren String — ohne Fehler und ohne Warnung. OCR erfordert das optionale Azure Document Intelligence-Backend oder ein Plugin, von denen keines standardmäßig mitgeliefert wird. Das ist eine seit Langem bekannte Lücke (Issue #1268).
Wie gut geht MarkItDown mit Tabellen um?
Beim Inhalt sehr gut — in meinem 13-Fälle-Test blieb in jedem Fall der komplette Tabelleninhalt erhalten. Strukturell hängt es von der Form ab: Einfache, breite, headerlose Tabellen und Tabellen mit leeren Zellen kommen als saubere GFM-Raster heraus, aber rowspan und colspan werden unsauber (wobei rowspan Daten still in die falsche Spalte verschieben kann), verschachtelte Tabellen werden zu unbrauchbaren Zeilen zusammengezogen, und literale Pipe-Zeichen in Zellen werden nicht escaped. Das flache Markdown-Tabellenformat kann Spans und Verschachtelung 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 einplanen. Ein PDF mit 492 Seiten brauchte etwa 3,2 Minuten (rund 0,39 s/Seite), weil pro Seite Form-Erkennung läuft, und ist CPU-gebunden. Eine Tabelle mit 50.000 Zeilen war in etwa einer Minute fertig, verbrauchte aber +374 MB RAM, weil sie einen großen Markdown-String komplett im Speicher baut. 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
