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 overbodige rommel eruit te filteren. Wat het wél doet: bytes die je al hebt — een PDF, Word-document, spreadsheet, slide deck — omzetten naar Markdown dat een taalmodel kan lezen.
Ik heb Microsofts MarkItDown een paar weken getest met echte documenten op één Mac, waarbij ik elke tabel afzette tegen een manifest dat ik vóór de test had opgesteld en de tijd van elke conversie heb gemeten. De korte versie: op schone input is het snel en betrouwbaar, de verpakking verbergt een machine-learning runtime van 73 MB die je niet per se had gevraagd, en tabellen breken op manieren die slagen op de vraag “is de tekst bewaard gebleven?” maar falen op “staat de data nog in de juiste kolom?”. Hieronder staat het volledige beeld, inclusief de cijfers.
Wat MarkItDown 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, een .docx, een .xlsx, een .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 een Python API (MarkItDown().convert(...)), en via een optionele MCP-server voor agent-workflows.
De belangrijkste nuance is wat het niet doet, want dat claimt de README ook niet en ik heb het zelf bevestigd in de test: geen crawling, geen JS-rendering, geen links volgen, geen paginatie en geen hoofdtekst-extractie zoals bij readability-tools. Het is een converter voor complete documenten. Jij levert de bytes aan; het normaliseert ze. Dat ene verschil bepaalt of dit tooltje in jouw stack thuishoort, dus daar kom ik straks steeds op terug.
De repo zelf is qua GitHub-cijfers een zwaargewicht — 165.282 sterren en 11.790 forks medio juli 2026, MIT-licentie, met de nieuwste release (v0.1.6) op 2026-05-26. Die sterrenscore zegt echter vooral iets over de algemene hype rond LLM-tools en dat het van Microsoft komt, niet over de volwassenheid van de conversiekern. Er staan ook 833 open issues, en een paar daarvan zijn relevant voordat je installeert (daar kom ik zo op terug).
HTML naar Markdown: snel en volledig, inclusief boilerplate
Omdat de rest van mijn scraper-reviewreeks dezelfde vier webvoorbeelden gebruikt, heb ik MarkItDown exact die 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 is het echt sterk.
Alle vier de pagina’s werden geconverteerd met alleen de basisinstallatie, zonder extra’s, en elke body-content-probe bleef behouden. Het Wikipedia-artikel “Web scraping” (226 KB) kwam terug met de heading-structuur netjes gespiegeld — één h1, zeven h2’s, twaalf h3’s, precies passend bij de echte sectie-opbouw van het artikel — en 418 links bleven behouden als nette [tekst](url)-links. De 25×9 hockeystatistiekentabel op de Scrape This Site forms-pagina werd een nette GFM-pijplijntabel met 27 rijen (kop + scheidingslijn + 26 datarijen), inclusief lege cellen. Snelheid was hier geen probleem: mediaan 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 bewuste ontwerpkeuze, geen bug. MarkItDown haalt boilerplate niet weg. Het zet de volledige <body> om, dus sitechrome reist gewoon mee — en die restlaag groeit mee met hoeveel chrome de pagina heeft.
| Pagina | Uitvoertekens | Koppen (h1/h2/h3) | Links | Sitechrome-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 vrijwel chrome-vrije Books-homepage is 0,6% van de uitvoerregels chrome. Op Wikipedia is dat 12,4% — 42 van de 338 niet-lege regels zijn dingen als “jump to content”, de inhoudsopgave tonen/verbergen, “22 languages”, “retrieved from”, cookie- en licentievoetteksten. Die onderhoudsbanners van Wikipedia (“This article needs additional citations”) worden zelfs keurig in tweekoloms pijltabellen weergegeven, en zo komen er negen tabelrijen terecht op een pagina zonder echte datatabel.
Dat is niet omdat MarkItDown iets fout doet. Het is een converter voor complete documenten, geen readability-extractor: trouw HTML-naar-Markdown is een andere taak dan schone artikel-extractie. Trafilatura- en Firecrawl-achtige tools proberen alleen de hoofdinhoud terug te geven; MarkItDown geeft de pagina terug. Onder de motorkap haalt zijn _html_converter.py <script> en <style> eruit en geeft vervolgens de volledige body door aan de markdownify-library — zonder enige heuristiek voor hoofdinhoud. Als je alleen het artikel wilt, zit je op de verkeerde laag.
Het thuisdomein: PDF, DOCX, XLSX, PPTX
Documenten zijn precies waarvoor MarkItDown gebouwd is. Ik heb het losgelaten op echte publieke bestanden — een arXiv-paper met tekstlaag, de Bitcoin-whitepaper, een scan-achtige PDF zonder tekstlaag die ik had gerenderd zodat er nul tekst in zat, en de DOCX/XLSX/PPTX-bestanden uit MarkItDowns eigen testsuite (met UUID’s als seeding zodat ik stille dataverlies kon opsporen).
| Document | Input | Uitvoertekens | Probes | Mediaantijd | 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 uitvoer, 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 sheet → ## SheetName + GFM-tabel |
| PPTX (test.pptx) | 278 KB | 2.047 | — | 52 ms | markers voor dianummers, tabellen, grafiek → tabel |
De tekstherkenning op de PDF’s met tekstlaag was uitstekend — 7 van 7 vooraf vastgelegde probes op het arXiv-paper “Attention Is All You Need”, 6 van 6 op de Bitcoin-whitepaper — en geen enkel Office-bestand verloor ook maar één UUID-sentinel, dus geen stil dataverlies op de regressiefixtures van de beheerders zelf. Een mooie niche-overwinning: de DOCX-route (via mammoth) bewaart Office Math-vergelijkingen als LaTeX en zet equations.docx om in echte $$...$$-math. Als je wiskunde-intensieve Word-documenten aan een LLM voert, is dat een reële, zij het specifieke, plus die ik nergens anders zo expliciet beschreven vond.
Twee bevindingen op dit terrein verdienen extra aandacht, omdat juist die je waarschijnlijk kunnen bijten.
De gescande PDF die verdwijnt
Voer MarkItDown een image-only PDF zonder tekstlaag, en je krijgt een lege string terug. Nul tekens, geen uitzondering, geen waarschuwing — in ongeveer 15 ms geconverteerd, omdat er niets te extraheren valt. De PDF-route van MarkItDown doet alleen tekstextractie (pdfminer en pdfplumber onder de motorkap) en bevat geen OCR in de core-installatie of via een pip-extra.
Dat is een probleem in batchverwerking. Een developer die een map met PDF’s verwerkt waarin sommige bestanden scans zijn, krijgt voor die bestanden stilletjes lege resultaten, zonder signaal dat iets is overgeslagen. Ik heb gecheckt dat de testfixture niet stuk was door pdfminer’s extract_text er rechtstreeks op los te laten — nul gestript tekens, geen tekstlaag, bevestigd — dus de lege uitvoer is echt MarkItDowns gedrag op een echte scan. Dit reproduceert een al lang openstaande OCR-fallback-kloof (#1268) die upstream al een tijd 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 eruit als platte tekst, niet als structuur
Over beide PDF’s met tekstlaag heen produceerde MarkItDown nul Markdown-headingmarkeringen. Een PDF bevat geen semantische heading-tags, en MarkItDown leidt ze ook niet af uit lettergrootte, dus elke regel eindigt op body-niveau. Tekstherkenning is hoog; de structuur is vlak.
Dat is niet alleen mijn resultaat. Publieke benchmarks van derden scoren MarkItDowns PDF-headinghiërarchie rond 0,0 en de tabelgetrouwheid rond 0,27, ruim onder Doclings 0,88 met TableFormer-ondersteuning (zie de vergelijking MarkItDown vs Docling vs Marker en de READoc-benchmark). Mijn fixtures reproduceren dat, en dat versterkt juist het bewijs: mijn cijfers komen overeen met een externe bron. Dezelfde benchmarks laten ook zien dat MarkItDown ongeveer 100× sneller draait dan Docling, wat overeenkomt met mijn metingen in seconden in plaats van minuten op documenten waar een layout-modeltool minuten over doet. De conclusie: MarkItDown geeft je schone, snelle PDF-tekst; het geeft je niet de structuur van de PDF. Als koppen en tabellen intact moeten blijven, is een layout-modeltool zoals Docling of Marker de juiste laag.
Tabellen: inhoud blijft, structuur niet altijd
Tabellen zijn precies waar “is de tekst bewaard gebleven?” en “is de data bruikbaar?” uit elkaar gaan lopen, dus heb ik een matrix met 13 cases gebouwd — één <table> per case, elk vergeleken met een manifest dat vóór de run was geschreven — om exact in kaart te brengen welke vormen overeind blijven en welke breken.
De hoofduitkomst: MarkItDown verloor nooit tabelinhoud. Alle 13 cases behielden 100% van hun vooraf vastgelegde tokens. Maar de structurele nauwkeurigheid viel uiteen in drie groepen. Zeven van de dertien leverden een nette GFM-grid op (plain, header-colspan, 24 kolommen breed, zonder header, lege cellen, block-in-cell en rechts-naar-links Arabisch). Vier werden rommelig, omdat Markdown geen concept heeft voor een samengevoegde cel, dus rowspan, colspan en foutieve bronnen korte rijen opleveren. En twee gingen volledig mis.
Die twee missers zijn het benoemen waard. Een geneste tabel (een <table> in een <td>) wordt inline afgeplat, waardoor de eigen pipes en scheidingsrij van die tabel in de oudercel belanden en een rommelige 14-“koloms” rij ontstaat. En een letterlijke | in een cel wordt niet ge-escaped — celtekst a | b wordt twee kolommen, x || y wordt drie — waardoor een tabel met twee kolommen rijen oplevert met twee, drie en vier kolommen, en elke downstream Markdown-parser de verkeerde grenzen leest. Opmerkelijk genoeg worden asterisken en backticks in cellen wél ge-escaped; pipes dus niet. De oorzaak is dat MarkItDowns HTML-pad de standaard tabelafhandeling van markdownify gebruikt, en de eigen subclass wel links, afbeeldingen en koppen overschrijft, maar niet de tabelcellen. Dezelfde bugklasse rond pipe-escaping is een open issue voor de CSV-converter (#2019), al raakt die oplossing niet het HTML-pad dat ik hier testte.
De subtiele bevinding — en degene die ik een data-engineer het liefst zou laten zien — is rowspan. Case t03 wordt niet alleen rommelig; de data raakt stilletjes mis uitgelijnd. Een label met rowspan=2 (“Fruit”) wordt één keer uitgegeven, en de rij eronder wordt een korte tabelrij met twee kolommen (| Banana | 8 |), waardoor “Banana” onder de kolom Group terechtkomt in plaats van Item. Alle tokens zijn aanwezig. Een naïeve consument die “geef me de tweede kolom” leest, krijgt de verkeerde waarde. Dat is precies het soort bug dat een tekstbehoud-check haalt en ondertussen stilletjes een dataset corrumpeert.
De beperking rond spans zelf is een bekende, vastgelegde ontwerpkeuze (#1211, #1248) — een vlakke GFM-pijltabel kan spans of nesting nu eenmaal niet echt weergeven, dus de converter ruilt structuur in voor volledigheid van de inhoud. Er zitten ook goede eigenschappen in: tabellen zonder header krijgen een gegenereerde lege headerregel (zodat geen data stilletjes tot header wordt gepromoveerd), lege cellen blijven behouden, en <caption> blijft staan als tekstregel boven de tabel.
Installatie en opstart: de belasting waar een “lichtgewicht utility” je niet voor waarschuwt
Niets verraste me hier meer, en dit is de plek waar het frame van “lichte Python-hulpprogramma” stiekem te veel belooft.
Ten eerste: draai niet pip install 'markitdown[all]'. Op Python 3.14 valt die stilletjes terug naar markitdown 0.0.2 — een release van twee jaar geleden — 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 is elke build in dat bereik alleen geschikt 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 dependencies wel te vervullen zijn. Dit komt overeen met een open upstream issue (#2179). De oplossing is simpel: pin de versie en installeer de extras apart: pip install 'markitdown==0.1.6', en daarna pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Die lossen allemaal netjes op; alleen het gecombineerde [all]-pakket bevat de giftige pin. (Deze val is Python-versie-afhankelijk — op Python 3.13 of ouder kan de beperking anders uitpakken, dus [all] kan dan anders resolven.)
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 voor hun rekening — 66% van de volledige core-footprint — en beide komen mee door één harde dependency: magika, Google’s ML-detector voor bestandstypen. Dus een tekstconverter sleept een ONNX-inferentieruntime van 73 MB mee in de basisinstallatie, nog vóór je ook maar één document-extra toevoegt. Met de document-extras groeit de venv naar 310 MB. Dat is nog altijd veel lichter dan een headless-browserstack, maar als je een “pip install en klaar”-microtool verwachtte, moet je weten dat er een ONNX-runtime meekomt.
Ten derde — en dit is de ene bevinding in mijn hele set die bij elke novelty-check die ik deed overeind blijft — zelfs na een schone installatie kost import markitdown op deze machine ongeveer 3,35 seconden. De kost zit vrijwel volledig in de importfase: markitdown._markitdown importeert agressief de volledige converterregistry (cumulatief 2,56 s, 76% van het totaal), waardoor pandas (1,21 s, via de XLSX-converter), python-pptx (427 ms), magika (354 ms) en requests (270 ms) meekomen — óók als je geen enkel bestand van die typen converteert. Voor een langlopende service is die importkost geamortiseerd en dus minder relevant. Voor een CLI-aanroep of een serverless cold start is het echter een echte per-process-belasting die je niet verwacht als iemand het een “lichtgewicht utility” noemt. (Eerlijke kanttekening: dit is één geprofileerde run, behandeld als één observatie, niet als een verdelingsanalyse 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 werd beĂŻnvloed door een eerdere run. Niets crashte. Het kostenprofiel is echter scheef.
| Onderwerp | Input | Uitvoertekens | Mediaantijd | Piek-RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF van 492 pagina’s) | 6,07 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 deed er mediaan 192,5 seconden over — ongeveer 3,2 minuten, of 0,39 s/pagina — omdat pdfplumber op elke pagina detectie van formulierachtige woordposities uitvoert. De piek-RSS bleef op +40 MB, dus dit is CPU-gebonden, niet geheugen-gebonden. Zelfs de arXiv-PDF van 15 pagina’s deed er in zijn eigen geïsoleerde proces 12,6 seconden over, ongeveer 3,4× de 3,7 seconden die hetzelfde bestand warm liet zien binnen mijn documentensuite. Dat verschil is de koude-proceskost en bevestigt dat het werk per pagina de bottleneck is, niet de ruwe bestandsgrootte. Wil je één overdraagbaar getal voor die PDF, gebruik dan de geïsoleerde 12,6 s.
De spreadsheet-route draait het knelpunt om. Een XLSX van 2,1 MB met 50.000 rijen groeide uit naar +374 MB piek-RSS (en 3,7 miljoen uitvoertekens), omdat de converter het hele werkblad inlaadt en één grote Markdown-string bouwt. De praktische vuistregel is dus simpel: grote PDF’s vragen om minuten CPU; grote spreadsheets om honderden MB RAM. Dit zijn cijfers van één machine op macOS arm64 en Python 3.14, en de per-pagina- en per-rijconstanten zijn platformafhankelijk — maar de vorm van het resultaat (PDF is traag en CPU-gebonden, XLSX is geheugenintensief, niets crasht) is precies wat overeind blijft.
Waar Thunderbit past — en waar niet
Probeer Thunderbit voor webdata-extractie
Dit is de vergelijking waar je snel te veel van kunt maken, dus ik trek de lijn 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-bot en dynamische content waar MarkItDown helemaal geen gereedschap voor heeft — en het /extract-endpoint levert gestructureerde JSON die overeenkomt met een schema, niet alleen ruwe Markdown. Voor developers is dat beschikbaar als API (POST /distill / POST /extract), een MCP-server en een CLI (npx @thunderbit/thunderbit-cli), allemaal op één AI-engine, dezelfde achter de extensie met meer dan 100.000 gebruikers.
Er is dus precies één overlap — beide kunnen “LLM-ready Markdown” leveren — maar het invoerdomein is anders: Thunderbits distill neemt een URL op het open web, MarkItDown neemt een lokaal bestand. Ze zijn geen inwisselbare alternatieven, en dat ga ik ook niet doen alsof. De realistische stack gebruikt beide: het web ophalen en crawlen met Thunderbit (of een Firecrawl-achtige dienst), en daarna de gemengde lokale documenten die je óók hebt — PDF’s, presentaties en spreadsheets — normaliseren met MarkItDown. De ene doet het netwerk; de andere doet de documentenmap.
Voor- en nadelen
Sterktes
- Volledige body-recall op schone HTML (4/4 pagina’s), met heading-structuren en links netjes behouden
- Hoge PDF/DOCX-tekstrecall (arXiv 7/7 probes, Bitcoin 6/6) en geen stil dataverlies op de eigen Office-fixtures van de maintainers
- Office Math-vergelijkingen behouden als LaTeX — een echte niche-overwinning
- Geen crashes op enige schaaltest, tot een PDF van 492 pagina’s en een XLSX van 50k rijen
- Heel eenvoudig aan te roepen: CLI,
convert(), piping via stdin en een optionele MCP-server - MIT-licentie, actief onderhouden door Microsoft, en een responsieve issue tracker
Zwaktes
- 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 rommelig), en rowspan zet data stilletjes in de verkeerde kolom
- Gescande/beeldgebaseerde PDF’s leveren lege uitvoer op zonder OCR en zonder foutmelding
- PDF-uitvoer heeft nul heading-structuur (komt overeen met 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 moet gebruiken, en wie niet
Pak MarkItDown erbij als je een stapel gemengde lokale documenten — Word, Excel, PowerPoint, PDF’s met tekstlaag — wilt standaardiseren naar Markdown voor een LLM-pipeline, en als je meer hecht aan volledige tekst dan aan behouden structuur. Als laatste stap in een batchjob, om schone tekst aan een model te voeren, is het snel, betrouwbaar en gratis.
Sla het over, of combineer het met iets anders, als je taak een van deze dingen is: je wilt alleen het hoofdartikel van een webpagina (gebruik een readability- of Firecrawl-achtige tool); je wilt dat de koppen en tabellen van 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 ander tool nodig). En als je dacht dat je een scraper kocht — iets dat webpagina’s ophaalt en crawlt — dan is dit het absoluut niet.
De voorlopige score die ik op een scraper-gebaseerd beoordelingsmodel haalde, komt voor MarkItDown uit op 60/100, en die lage score is het gevolg van een converter te beoordelen met een crawler-test. Op zijn eigen terrein zijn de tekstgetrouwheidsscores hoog; de zwakke plekken zitten in structuur (tabellen, PDF-koppen) en packaging (footprint, import, de [all]-val), niet in tekstkwaliteit. Beoordeel het als wat het is — een file-to-Markdown-converter — en je krijgt een solide, goed onderhouden tool met een paar scherpe randjes die je moet kennen voordat je hem in productie hangt.
Veelgestelde vragen
Is MarkItDown een webscraper?
Nee. Er zit geen crawler in, geen JavaScript-rendering, geen links volgen en geen paginatie. 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 scrapingtool nodig zoals Thunderbit of Firecrawl; MarkItDown is juist de stap erna, waarbij opgehaalde of lokale bestanden in schone Markdown worden omgezet.
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 dat bereik is alleen geschikt voor Python-versies onder 3.14. De resolver kan aan die pin niet voldoen en valt daarom stilletjes terug op markitdown 0.0.2, een release van twee jaar oud. De oplossing is om de versie vast te pinnen en de extras apart te installeren: pip install 'markitdown==0.1.6', en daarna 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6' toevoegen. Dit wordt gevolgd in issue #2179.
Doet MarkItDown OCR op gescande PDF’s?
Niet in de standaardinstallatie. De PDF-route doet alleen tekstextractie, dus een image-only PDF zonder tekstlaag geeft een lege string terug — geen fout, geen waarschuwing. OCR vereist de optionele Azure Document Intelligence-backend of een plugin, en die worden niet standaard meegeleverd. Dit is een langdurig bekend gat (issue #1268).
Hoe goed gaat MarkItDown om met tabellen?
Qua inhoud heel goed — in mijn test met 13 cases bleef in elk geval 100% van de tabelinhoud behouden. Structureel hangt het af van de vorm: eenvoudige, brede, headerloze en lege-cell-tabellen komen er netjes uit als GFM-grids, maar rowspan en colspan worden rommelig (en rowspan kan data stilletjes in de verkeerde kolom zetten), geneste tabellen worden afgeplat tot rommelige rijen, en letterlijke pipe-tekens in cellen worden niet ge-escaped. Markdown’s platte tabelvorm kan spans en nesting simpelweg niet representeren.
Is MarkItDown snel genoeg voor grote documenten?
Het crasht niet op grote bestanden, maar reserveer wel middelen per type. Een PDF van 492 pagina’s deed er ongeveer 3,2 minuten over (ongeveer 0,39 s/pagina), omdat het per pagina form-detectie doet en dus CPU-gebonden is. Een spreadsheet met 50.000 rijen was in ongeveer een minuut klaar, maar gebruikte +374 MB RAM omdat het één grote Markdown-string in geheugen opbouwt. Voor grote PDF’s moet je minuten CPU inplannen; voor grote spreadsheets honderden MB RAM.
Probeer Thunderbit voor webdata-extractie Get Started Free
