MarkItDown wordt vaak in hetzelfde hokje gezet als webscrapers, maar dat klopt niet. Er zit geen crawler in, geen JavaScript-engine en geen manier om een URL op te halen en de rommel er netjes af te halen. Wat het wél doet: bytes die je al hebt — een PDF, Word-document, spreadsheet, dia’s — omzetten naar Markdown dat een taalmodel kan lezen.
Ik heb Microsofts MarkItDown een paar weken lang losgelaten op echte documenten op één Mac. Daarbij heb ik elke tabel vergeleken met een manifest dat ik vooraf had opgesteld en de conversietijd bijgehouden. De korte versie: op schone input is het snel en nauwkeurig, de verpakking verstopt een machine-learning runtime van 73 MB waar je niet om hebt gevraagd, en tabellen gaan op een manier stuk die doorstaat bij een check als “is de tekst nog aanwezig?” maar faalt bij “staat de data nog in de juiste kolom?”. Hieronder het volledige plaatje, met cijfers.
Wat MarkItDown nu eigenlijk is
MarkItDown is een Python-hulpprogramma van Microsoft dat bestanden en Office-documenten omzet naar Markdown, geoptimaliseerd voor LLM’s. Geef het een PDF, .docx, .xlsx, .pptx, een afbeelding, een HTML-bestand of een paar andere formaten, en je krijgt Markdown terug. Je kunt het op drie manieren gebruiken: via de CLI (markitdown file.pdf -o out.md, of via stdin), via de Python API (MarkItDown().convert(...)) en via een optionele MCP-server voor agent-workflows.
Wat vooral belangrijk is, is wat het niet doet — en dat is ook meteen bevestigd in mijn tests en niet door de README weersproken: geen crawling, geen JS-rendering, geen link-volging, geen pagination en geen main-content-extractie zoals bij readability-tools. Het is een converter voor hele documenten. Jij levert de bytes aan; MarkItDown maakt er een gestandaardiseerde versie van. Dat ene verschil bepaalt of dit hulpmiddel in je stack thuishoort of niet, dus daar kom ik steeds op terug.
De repository zelf scoort indrukwekkend in GitHub-cijfers — 165.282 sterren en 11.790 forks halverwege juli 2026, onder MIT-licentie, met de nieuwste release (v0.1.6) op 2026-05-26. Maar die sterren zeggen vooral iets over Microsofts naam en de algemene hype rond LLM-tools, niet over de volwassenheid van de conversie-internals. Er zijn ook 833 open issues, en een paar daarvan wil je kennen vóór je installeert (daarover verderop meer).
HTML naar Markdown: snel en compleet, inclusief boilerplate
Omdat de rest van mijn scraper-reviewreeks dezelfde vier web-fixtures gebruikt, heb ik MarkItDown exact dezelfde lokale HTML-bestanden gevoerd — niet om het als scraper te beoordelen, maar om te zien hoe goed de HTML-naar-Markdown-conversie is. Op goed gestructureerde pagina’s doet het het echt goed.
Alle vier pagina’s werden met de basisinstallatie geconverteerd zonder extra’s, en elke probe voor body-content bleef behouden. Het Wikipedia-artikel over “Web scraping” (226 KB) kwam eruit met een spiegel van de koppenstructuur — één h1, zeven h2’s, twaalf h3’s, precies passend bij de echte sectiestructuur — en 418 links netjes als [tekst](url). De tabel met 26×9 hockey-statistieken op de Scrape This Site forms-pagina werd een nette GFM-pipetabel met 27 rijen (kop + scheidingslijn + 26 datarijen), inclusief lege cellen. Snelheid was hier geen probleem: een mediaan van 48 ms voor de kleine quotes-pagina tot 352 ms voor de Wikipedia-pagina van 226 KB.
Maar hier zit de adder onder het gras — en dat is een ontwerpkeuze, geen bug. MarkItDown haalt boilerplate niet weg. Het converteert de volledige <body>, dus paginarand-elementen gaan gewoon mee — en hoeveel rommel je overhoudt, hangt af van hoeveel chrome de pagina bevat.
| Pagina | Outputtekens | Koppen (h1/h2/h3) | Links | Site-chrome-regels |
|---|---|---|---|---|
| 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) |
Op de bijna chrome-vrije Books-homepage is 0,6% van de outputregels chrome. Op Wikipedia is dat 12,4% — 42 van de 338 niet-lege regels bestaan uit zaken als “jump to content”, “toggle the table of contents”, “22 languages”, “retrieved from”, cookies en licentie-voetteksten. Die Wikipedia-meldingen (“This article needs additional citations”) worden zelfs trouw als tweekolomstabellen weergegeven, en zo kom je aan negen tablerijen op een pagina zonder echte datatabel.
Dat betekent niet dat MarkItDown iets verkeerd doet. Het is een hele-document-converter, geen readability-extractor: trouw HTML naar Markdown omzetten is iets anders dan schoon artikelmateriaal extraheren. Trafilatura en Firecrawl-achtige tools proberen alleen de hoofdinhoud terug te geven; MarkItDown geeft de hele pagina terug. Intern verwijdert de _html_converter.py alleen <script> en <style>, en geeft daarna de volledige body door aan de markdownify-bibliotheek — zonder main-content-heuristiek in de keten. Als je alleen het artikel wilt, zit je met dit hulpmiddel op de verkeerde laag.
Het eigen terrein: PDF, DOCX, XLSX, PPTX
Documenten zijn waar MarkItDown voor gebouwd is. Ik heb het losgelaten op echte publieke bestanden: een arXiv-paper met tekstlaag, de Bitcoin-whitepaper, een gescande PDF alleen uit afbeeldingen die ik zelf had gerenderd zodat er echt nul tekst in zat, en de DOCX/XLSX/PPTX-bestanden uit MarkItDowns eigen testsuite (met UUID’s gevuld zodat ik stille contentverlies kon detecteren).
| Document | Input | Outputtekens | Probes | Mediaan tijd | Opmerking |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF met tekstlaag) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | titel, "Transformer", "BLEU", "References" allemaal aanwezig |
| Bitcoin-whitepaper (9 pagina’s PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" aanwezig |
| Gescande PDF (geen tekstlaag) | 89 KB | 0 | 0/4 | 15 ms | lege output, geen fout, geen OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | koppen + GFM-tabel; ingebedde UUID’s blijven behouden |
| DOCX met vergelijkingen | 15 KB | 240 | — | 101 ms | Office Math behouden als LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | elk werkblad → ## SheetName + GFM-tabel |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | markeringen voor dianummers, tabellen, grafiek → tabel |
De tekst-herkenning op PDF’s met tekstlaag was uitstekend — 7 van de 7 vooraf vastgelegde probes op het arXiv-artikel “Attention Is All You Need”, 6 van de 6 op de Bitcoin-whitepaper — en geen enkel Office-bestand verloor ook maar één UUID-sentinel, dus geen stil contentverlies op de regressie-fixtures van de maintainers zelf. Een mooie, gerichte winst: het DOCX-pad (via mammoth) behoudt Office Math-vergelijkingen als LaTeX en zet equations.docx dus om naar echte $$...$$-wiskunde. Als je wiskundige Word-documenten naar een LLM stuurt, is dat een heel specifieke, maar echt waardevolle kracht die ik nergens goed uitgelegd zag.
Er zijn twee bevindingen op dit terrein die extra aandacht verdienen, omdat dit precies de dingen zijn waar je op stuk kunt lopen.
De gescande PDF die verdwijnt
Voer MarkItDown een PDF zonder tekstlaag, alleen afbeeldingen, en je krijgt een lege string terug. Nul tekens, geen uitzondering, geen waarschuwing — in ongeveer 15 ms geconverteerd, omdat er simpelweg niets uit te lezen valt. Het PDF-pad van MarkItDown doet alleen tekstextractie (pdfminer en pdfplumber onder de motorkap) en bevat geen OCR in de basisinstallatie, noch als pip-extra.
Dat maakt uit in batchverwerking. Een developer die een map met PDF’s verwerkt waarin ook scans zitten, krijgt voor die bestanden stilletjes lege resultaten terug zonder enig signaal dat er iets is overgeslagen. Ik heb gecontroleerd of de fixture niet kapot was door pdfminers extract_text er rechtstreeks op los te laten — nul gestript tekens, geen tekstlaag, bevestigd — dus de lege output is echt MarkItDowns gedrag op een echte scan. Dat reproduceert een al lang open OCR-fallback-gat (#1268) dat al een tijd upstream wordt gevolgd. De gedocumenteerde route is de optionele Azure Document Intelligence-backend of een plugin; geen van beide zit in de standaardinstallatie.
PDF’s komen uit als platte tekst, niet als structuur
Bij beide PDF’s met tekstlaag produceerde MarkItDown nul Markdown-kopmarkeringen. Een PDF bevat nu eenmaal geen semantische heading-tags, en MarkItDown leidt die ook niet af uit lettergrootte, dus elke regel belandt op body-niveau. Tekst is dus goed terug te halen; de structuur blijft vlak.
Dit is niet alleen mijn uitkomst. Publieke benchmarks van derden geven MarkItDown voor de PDF-headinghiërarchie ongeveer 0,0 en voor tabelgetrouwheid rond 0,27, duidelijk lager dan Doclings op TableFormer gebaseerde 0,88 (zie de MarkItDown vs Docling vs Marker-vergelijking en de READoc-benchmark). Mijn fixtures reproduceren hun resultaten, en dat versterkt het bewijs: mijn cijfers komen overeen met een externe bron. De trade-off die diezelfde benchmarks laten zien, is dat MarkItDown ongeveer 100× sneller draait dan Docling, en dat past bij mijn resultaten van seconden in plaats van minuten op documenten waar een layout-model-tool minuten over doet. De conclusie: MarkItDown geeft je schone, snelle PDF-tekst; het geeft je niet de PDF-structuur. Als koppen en tabellen intact moeten blijven, is een layout-model-tool zoals Docling of Marker de juiste laag.
Tabellen: de tekst blijft, de structuur soms niet
Tabellen zijn precies het punt waar “is de tekst behouden?” en “is de data bruikbaar?” uit elkaar lopen, dus ik heb een matrix met 13 gevallen gebouwd — per geval één <table>, elk vergeleken met een manifest dat vóór de run was geschreven — om exact te zien welke vormen overeind blijven en welke breken.
De hoofdconclusie: MarkItDown verloor nooit tabelinhoud. Alle 13 gevallen behielden 100% van de vooraf vastgelegde tokens. Maar structurele getrouwheid viel uiteen in drie groepen. Zeven van de dertien leverden een netjes gevormde GFM-rastertabel op (plain, header-colspan, 24-kolommen-breed, headerloos, lege-cellen, block-in-cell en rechts-naar-links Arabisch). Vier werden rafelig, omdat Markdown geen concept heeft voor een samengevoegde cel, waardoor rowspan, colspan en rommelige bronbestanden korte rijen opleveren. En twee waren ronduit kapot.
Die twee kapotte gevallen verdienen een naam. Een geneste tabel (een <table> binnen een <td>) wordt inline platgeslagen, waarbij de eigen pipes en scheidingsrij in de oudercel terechtkomen en zo een rommelige rij met 14 “kolommen” produceren. En een letterlijke | in een cel wordt niet ge-escapet — celtekst a | b wordt twee kolommen, x || y wordt drie — waardoor een tweekolomstabel rijen met twee, drie en vier kolommen oplevert, en elke Markdown-parser stroomafwaarts de verkeerde grenzen leest. Opvallend genoeg worden sterretjes en backticks in de cel wel ge-escapet; alleen pipes niet. De onderliggende oorzaak is dat MarkItDowns HTML-pad de standaard tabelafhandeling van markdownify gebruikt, en de eigen subclass wel links, afbeeldingen en koppen overschrijft, maar niet tabelcellen. Dezelfde bugklasse rond pipe-escaping is overigens een open issue voor de CSV-converter (#2019), al raakt die fix niet het HTML-pad dat ik heb getest.
De subtiele, en voor een data engineer misschien belangrijkste, bevinding is rowspan. Geval t03 wordt niet alleen rafelig; de data verschuift stilletjes. Een label met rowspan=2 (“Fruit”) verschijnt één keer, en de rij daaronder wordt een korte twee-kolomsrij (| Banana | 8 |), waardoor “Banana” onder de Group-kolom terechtkomt in plaats van onder Item. Alle tokens zijn aanwezig. Een naïeve consument die “de tweede kolom lezen” wil, krijgt dus de verkeerde waarde. Dat is precies het soort bug dat een tekst-check doorstaat en een dataset stilletjes corrumpeert.
De beperking van spans zelf is een bekende, geregistreerde ontwerpkeuze (#1211, #1248) — een vlakke GFM-pipetabel kan spans of nesting nu eenmaal niet goed weergeven, dus de converter ruilt structuur in voor volledige inhoud. Er zitten ook goede dingen tussen: headerloze tabellen krijgen een gegenereerde lege koprij (zodat data niet stilletjes tot kop wordt gepromoveerd), lege cellen blijven behouden en <caption> blijft bewaard als tekstregel boven de tabel.
Installatie en opstart: de belasting waar een “lichtgewicht hulpprogramma” je niet voor waarschuwt
Nergens verraste dit me meer, en hier overbelooft het label “lightweight Python utility” stilletjes het een en ander.
Ten eerste: draai niet pip install 'markitdown[all]'. Op Python 3.14 valt dat stilletjes terug naar markitdown 0.0.2 — een release van twee jaar oud — en dat heb ik live gereproduceerd in een schone venv. Vastpinnen laat zien waarom: pip install 'markitdown[all]==0.1.6' geeft een fout, omdat de [all]-extra youtube-transcript-api~=1.0.0 vastzet, en op de huidige PyPI zijn alle builds in die reeks alleen toegestaan voor Python <3.14, terwijl de enige 3.14-compatibele builds buiten die pin vallen. De resolver loopt dus helemaal terug naar de laatste release waarvan de afhankelijkheden wél oplosbaar zijn. Dit komt overeen met een open upstream issue (#2179). De oplossing is simpel: pin de versie en installeer de extra’s apart: pip install 'markitdown==0.1.6', gevolgd door pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Die lossen allemaal netjes op; alleen de gecombineerde [all]-bundel bevat de problematische pin. (Deze valkuil hangt af van de Python-versie — op Python 3.13 of ouder kan het gedrag anders zijn, dus [all] kan daar anders uitpakken.)
Ten tweede: de footprint. De core-installatie is 161 MB (een lege venv van 13 MB plus 148 MB). Daarvan nemen onnxruntime (73 MB) en numpy (34 MB) samen 107 MB in beslag — 66% van de totale core-footprint — en die worden beide meegetrokken door één harde afhankelijkheid: magika, Googles ML-bestandstypeherkenner. Dus een tekstconverter levert standaard al een 73 MB ONNX-inferentieruntime mee, nog vóór je ook maar één document-extra toevoegt. Met de document-extra’s erbij groeit de venv naar 310 MB. Dat is nog altijd veel lichter dan een headless-browserstack, maar als je had verwacht dat dit gewoon een kleine pip install-en-klaar-tool was, moet je weten dat er een ONNX-runtime meeloopt.
Ten derde — en dit is de bevinding in mijn hele set die elke novelty-check doorstaat die ik heb gedaan — zelfs na een schone installatie kost import markitdown op deze machine ongeveer 3,35 seconden. Die kosten zitten bijna volledig in de importfase: markitdown._markitdown importeert de volledige converterregistratie meteen (2,56 s cumulatief, 76% van het totaal), wat pandas (594 ms, via de XLSX-converter), python-pptx (427 ms), magika (354 ms) en requests (270 ms) mee naar binnen trekt — of je die formaten nu gebruikt of niet. Voor een langlopende service is die importkost eenmalig en dus onbelangrijk. Voor een CLI-call of een serverless cold start is het een echte per-procesbelasting waar het label “lichtgewicht” je niet op voorbereidt. (Eerlijk voorbehoud: dit is één geprofileerde run, dus één observatie, geen distributie over meerdere runs.)
Schaal: het crasht niet, maar reserveer CPU voor PDF’s en RAM voor spreadsheets
Ik heb vier grote onderwerpen erdoorheen gejaagd, elk in een eigen proces zodat het piekgeheugen niet vervuild was door een eerdere run. Niets crashte. Het kostenprofiel is wel scheef.
| Onderwerp | Input | Outputtekens | Mediaan tijd | Piek RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF van 492 pagina’s) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50.000 rijen × 8 kolommen | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15-pagina’s PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 rijen × 64 kolommen | 46 KB | 120,129 | 2.9 s | +22 MB |
De NIST-PDF van 492 pagina’s duurde mediaan 192,5 seconden — ongeveer 3,2 minuten, oftewel 0,39 s/pagina — omdat pdfplumber op elke pagina woordpositie-gebaseerde formulierdetectie uitvoert. De piek-RSS bleef op +40 MB, dus dit is CPU-gebonden en niet geheugen-gebonden. Zelfs de arXiv-PDF van 15 pagina’s duurde 12,6 seconden in een geïsoleerd proces; dat is ongeveer 3,4× de 3,7 seconden die hetzelfde bestand warm liet zien binnen mijn documentset. Dat verschil is de cold-process-kost, en bevestigt dat het werk per pagina de drijvende factor is, niet de ruwe bestandsgrootte. Als je één overdraagbare waarde voor die PDF wilt, gebruik dan die geïsoleerde 12,6 s.
Het spreadsheet-pad draait het bottleneck om. Een XLSX van 2,1 MB met 50.000 rijen groeide uit naar +374 MB piek-RSS (en 3,7 miljoen outputtekens), omdat de converter het hele werkblad inlaadt en één grote Markdown-string bouwt. De praktische vuistregel is dus vrij direct: grote PDF’s → reken op minuten CPU; grote spreadsheets → reken op honderden MB RAM. Dit zijn cijfers van één machine op macOS arm64 en Python 3.14, en de constante waarden per pagina en per rij zijn platformafhankelijk — maar de vorm van het gedrag (PDF is traag en CPU-zwaar, XLSX is geheugenintensief, niets crasht) is juist het deel dat overdraagbaar is.
Waar Thunderbit past — en waar niet
Probeer Thunderbit voor webdata-extractie
Dit is de vergelijking waar je makkelijk te veel van kunt maken, dus ik trek de grens zorgvuldig. MarkItDown en Thunderbit lossen verwante, maar niet dezelfde problemen op.
MarkItDown zet bestanden om die je al hebt. Thunderbit haalt eerst de pagina op. Thunderbits /distill-endpoint zet een live webpagina om naar schone, LLM-klare Markdown — inclusief JS-rendering, anti-botmaatregelen en dynamische content waarvoor MarkItDown geen enkele mechanismen heeft — en het /extract-endpoint geeft schema-gebonden gestructureerde JSON terug, niet alleen ruwe Markdown. Voor developers is dat beschikbaar via een API (POST /distill / POST /extract), een MCP-server en een CLI (npx @thunderbit/thunderbit-cli) bovenop één AI-engine, dezelfde die achter de extension met 100.000+ gebruikers zit.
Ze overlappen dus maar op één punt — allebei kunnen ze “LLM-ready Markdown” leveren — maar het invoerdomein is anders: Thunderbits distill neemt een URL op het open web, MarkItDown neemt een lokaal bestand. Het zijn geen inwisselbare alternatieven, en dat ga ik ook niet doen alsof. In de praktijk gebruik je vaak beide: haal en crawl het web met Thunderbit (of een Firecrawl-achtige service), en normaliseer daarna de gemengde lokale documenten die je óók hebt — PDF’s, decks en spreadsheets — met MarkItDown. De één handelt het netwerk af; de ander de bestandskast.
Plus- en minpunten
Sterke punten
- Volledige body-herkenning op schone HTML (4/4 pagina’s), met koppenstructuur en links trouw behouden
- Hoge tekstherkenning voor PDF/DOCX (arXiv 7/7 probes, Bitcoin 6/6) en geen stil contentverlies op de Office-fixtures van de maintainers zelf
- Office Math-vergelijkingen blijven behouden als LaTeX — een echte niche-winst
- Geen crashes bij welke schaaltest dan ook, tot een PDF van 492 pagina’s en een XLSX van 50.000 rijen
- Makkelijk aan te roepen: CLI,
convert(), stdin-piping en optioneel een MCP-server - MIT-licentie, actief onderhouden door Microsoft, en een responsieve issue-tracker
Zwakke punten
- Laat boilerplate staan — tot 12,4% chrome-regels op Wikipedia; geen artikel-extractor
- Tabellen breken bij spans, nesting en pipes in cellen (2/13 kapot, 4/13 rafelig), en rowspan zet data stilletjes in de verkeerde kolom
- Gescande/afbeeldings-PDF’s geven lege output terug zonder OCR en zonder foutmelding
- PDF-output heeft nul kopstructuur (sluit aan bij publieke benchmarks)
- 161 MB core-installatie met een ONNX-runtime van 73 MB; ~3,35 s koude import
- De
[all]-extra valt op Python 3.14 stilletjes terug naar een twee jaar oude 0.0.2
Wie het wel en niet moet gebruiken
Pak MarkItDown erbij als je een stapel gemengde lokale documenten — Word, Excel, PowerPoint, tekstlaag-PDF’s — wilt standaardiseren naar Markdown voor een LLM-pipeline, en je meer geeft om volledige tekst dan om behouden structuur. Als laatste conversiestap in een batchjob, om schone tekst aan een model door te geven, is het snel, trouw en gratis.
Sla het over, of combineer het met iets anders, als je taak een van deze is: je wilt alleen het hoofdartikel van een webpagina (gebruik dan een readability- of Firecrawl-achtig hulpmiddel); je wilt dat koppen en tabellen in een PDF intact blijven (dan zit je in het domein van Docling of Marker); of je input bevat gescande documenten waarvoor OCR nodig is (dan heb je de Azure-backend of een volledig ander hulpmiddel nodig). En als je eigenlijk op zoek was naar een scraper — iets dat haalt en crawlt — dan is dit dat absoluut niet.
De voorlopige score die ik op een scraper-achtig beoordelingskader heb berekend komt uit op 60/100, en die lage totaalscore is vooral een artefact van een converter beoordelen met een crawler-test. Op zijn eigen terrein zijn de tekstgetrouwheidsscores hoog; de zwakke plekken zitten vooral in structuur (tabellen, PDF-koppen) en verpakking (footprint, import, de [all]-valkuil), niet in tekstkwaliteit. Beoordeel je het als wat het is — een bestand-naar-Markdown-converter — dan is het een solide, goed onderhouden tool met een paar scherpe randjes die je beter kent voordat je het in productie hangt.
Veelgestelde vragen
Is MarkItDown een webscraper?
Nee. Er zit geen crawler in, geen JavaScript-rendering, geen link-volging en geen pagination. Het zet bestanden en documenten die je al hebt — PDF, DOCX, XLSX, PPTX, afbeeldingen, HTML — om naar Markdown. Als je live webpagina’s wilt ophalen en crawlen, heb je een scraping-tool zoals Thunderbit of Firecrawl nodig; MarkItDown komt pas daarna, om opgehaalde of lokale bestanden om te zetten naar schone Markdown.
Waarom installeert pip install markitdown[all] een oude versie?
Op Python 3.14 zet de [all]-extra youtube-transcript-api~=1.0.0 vast, en elke build in die reeks is alleen toegestaan voor Python-versies onder 3.14. De resolver kan die pin niet vervullen en valt daarom stilletjes terug naar markitdown 0.0.2, een release van twee jaar oud. De oplossing is om de versie vast te pinnen en extra’s los te installeren: pip install 'markitdown==0.1.6', en daarna pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Dit staat geregistreerd als issue #2179.
Doet MarkItDown OCR op gescande PDF’s?
Niet in de standaardinstallatie. Het PDF-pad doet alleen tekstextractie, dus een PDF met alleen afbeeldingen en zonder tekstlaag levert een lege string op — geen fout, geen waarschuwing. OCR vereist de optionele Azure Document Intelligence-backend of een plugin, en die worden standaard niet meegeleverd. Dit is een al lang bekende lacune (issue #1268).
Hoe goed gaat MarkItDown om met tabellen?
Qua inhoud heel goed — in mijn test met 13 gevallen bleef in elk geval 100% van de tabelinhoud behouden. Qua structuur hangt het af van de vorm: simpele, brede, headerloze en leeg-cellen-tabellen komen netjes als GFM-raster terug, maar rowspan en colspan worden rafelig (en rowspan kan data stilletjes in de verkeerde kolom zetten), geneste tabellen worden platgeslagen tot rommelige rijen, en letterlijke pipe-tekens in cellen worden niet ge-escapet. De platte tabelvorm van Markdown kan spans en nesting gewoon niet goed weergeven.
Is MarkItDown snel genoeg voor grote documenten?
Het crasht niet op grote bestanden, maar reserveer je resources per type. Een PDF van 492 pagina’s duurde ongeveer 3,2 minuten (ongeveer 0,39 s/pagina), omdat er per pagina formulierdetectie gebeurt en het dus CPU-gebonden is. Een spreadsheet met 50.000 rijen was in ongeveer een minuut klaar, maar gebruikte +374 MB RAM omdat er in geheugen één grote Markdown-string wordt opgebouwd. Voor grote PDF’s: plan minuten CPU. Voor grote spreadsheets: plan honderden MB RAM.
Probeer Thunderbit voor webdata-extractie Get Started Free
