Docling wordt nog altijd in hetzelfde vakje gezet als webscrapers, maar dat is het niet. Het is een documentconversietoolkit van IBM Research — inmiddels een project van de LF AI & Data Foundation — die bestanden die je al hebt (PDF, DOCX, PPTX, XLSX, HTML, afbeeldingen) omzet naar Markdown of JSON. Hun eigen slogan is letterlijk: "Get your documents ready for gen AI."
Dit is dus een praktijkgerichte review van een converter, niet van een crawler. Alles hieronder is gemeten op één machine met alleen CPU (macOS arm64, Python 3.14.2, Docling 2.111.0), op basis van scripts, met fouten gewoon als fouten meegeteld. De repository is enorm en verandert dagelijks — 63.069 sterren, 4.449 forks, en nog dezelfde dag een commit op het moment dat ik de metadata ophaalde — dus zie elk getal hier als een momentopname, niet als een constante.
Wat Docling wel is (en niet is)
De basiseenheid in Docling is het DoclingDocument: parse een bestand naar die structuur en exporteer het daarna naar Markdown, HTML, DocTags of lossless JSON. De code is MIT-licensed (individuele modellicenties kunnen verschillen), het project is ontstaan bij IBM Research Zurich, en op het moment van schrijven is de nieuwste release v2.112.0, gepubliceerd twee dagen voordat ik deze test draaide.
De belangrijkste functionaliteit zit in het PDF- en afbeeldingstraject. Dat is geen simpele string parsing, maar een stapel machinelearningmodellen: een RT-DETR layoutmodel, het TableFormer-model voor tabelstructuur, een optioneel vision-language model en RapidOCR voor scans. Die modellen reconstrueren paginalay-out, leesvolgorde en tabelstructuur. Dát is het deel dat het waard is om te beoordelen, en precies het deel dat je met een test die alleen HTML gebruikt nooit zou zien.
Eén onderscheid voorkomt een week aan verwarring. Docling haalt zelf niets op. Het rendert geen JavaScript, breekt niet door anti-botlagen heen en crawlt niet. Jij levert het bestand aan; Docling doet het begrip. Crawlen is werk voor een ander type tool, en dat wordt later belangrijk wanneer mensen vragen of Docling Firecrawl vervangt (dat doet het niet — ze vullen elkaar aan, en straks leg ik uit waarom).
De eerste run waar niemand je voor waarschuwt
pip install docling verloopt schoon op Python 3.14.2. Daarna kijk je naar je venv, en die is 1,3 GB groot. Docling trekt de volledige ML-stack mee als harde afhankelijkheid, zelfs als je uiteindelijk alleen een HTML-bestand omzet:
| Afhankelijkheid | Grootte op schijf (MiB, du) |
|---|---|
| torch (2.13.0) | 536 |
| opencv (cv2) | 119 |
| transformers (5.8.1) | 101 |
| scipy | 99 |
| sympy | 76 |
| pandas | 72 |
| rapidocr (+ meegeleverde modellen) | 72.1 |
| docling_parse | 30 |
En dan heb je nog geen enkele PDF omgezet. De echte frictie komt pas bij de eerste PDF-conversie, want dan worden de modellen gedownload. In een verse, geïsoleerde HuggingFace-cache duurde de eerste PDF-conversie ~224 seconden — en bijna al die tijd was downloaden, niet rekenen. De layout- en TableFormer-modellen nemen samen ~506 MiB op schijf in beslag (342 MiB TableFormer + 164 MiB layout, geverifieerd met du), en RapidOCR haalt ongeveer 40 MB aan PP-OCRv4-weights binnen in site-packages. De tweede conversie van hetzelfde bestand? 0,55 seconden. De modellen zijn gecachet; je betaalt die tol maar één keer.
Eén getal moet je negeren: het coldstart-script print een model_download_mb van 1060.2. Gebruik dat niet als footprint. Die komt uit een os.walk die symlinks volgt, en de HuggingFace-cache bewaart elk modelbestand één keer onder blobs/ en toont het daarna opnieuw via snapshots/ als symlink — de walk telt dus de 14 modelbestanden dubbel. De correcte, op du gebaseerde en symlink-deduplicated waarde is ~506 MiB (alleen blobs: 505,4 MiB). De les voor iedereen die Docling benchmarkt: rapporteer download-bytes en bytes op schijf als twee aparte cijfers, want dat zijn het ook.
Er is nog een tweede valkuil voor iedereen die een Docling-container bouwt. De weights worden op twee plekken en volgens twee schema’s opgeslagen. De layout- en TableFormer-modellen houden rekening met HF_HOME en downloaden pas bij de eerste PDF-conversie. RapidOCR’s modellen doen dat niet — die belanden in …/site-packages/rapidocr/models/ en omzeilen je cacheconfiguratie volledig. Als je een image vooraf vult of air-gap inzet, moet je beide caches afhandelen, en geen enkele HF_HOME-instelling vangt die tweede af.
Dan het eerlijke deel. Sinds eerdere releases heeft het project docling-slim uitgebracht — een core van ongeveer 50 MB waarmee je pip install docling-slim[format-html] kunt gebruiken voor HTML zonder torch mee te trekken. Dus die 1,3 GB is echt voor de standaard docling-metapackage, maar het is inmiddels een opt-in probleem geworden. Ik testte het standaardpakket omdat dat nog steeds is wat pip install docling oplevert, maar de zwaarte is geen onbehandeld gebrek — de modulaire oplossing bestaat en staat in issue #2393.
Tijdens het opzetten stuitte ik op een klein irritatiepunt dat het noemen waard is: import docling; docling.__version__ geeft AttributeError: module 'docling' has no attribute '__version__'. De module expose’t het simpelweg niet. De werkende manier is importlib.metadata.version("docling"), en die geeft '2.111.0'. Geen ramp, wel een kleine DX-frustratie, sinds juli 2026 open als issue #3733.
Tabelnauwkeurigheid: waar TableFormer zijn waarde bewijst
Tabellen zijn precies de reden waarom je Docling boven een simpele PDF-naar-tekst-dump zou kiezen, dus ik maakte zeven tabel-PDF’s met machineleesbare ground truth en beoordeelde de output cel voor cel. Twee metrics zijn hier relevant, en dat zijn niet hetzelfde: cell recall is het deel van de ground-truth waarden dat ergens in de gedetecteerde tabel terugkomt; in-row rate is het deel dat ook daadwerkelijk in de juiste rij belandt. Die twee op één hoop gooien maakt de tool mooier dan hij is, dus hier staan ze allebei:
| Tabel (stress) | Gedetecteerd | Cell recall | In-row rate | Opmerking |
|---|---|---|---|---|
| T1 eenvoudige tabel met randen (8 rijen × 5 kolommen), alleen op pagina | Nee | 0.0 | — | geclassificeerd als <!-- image -->, alle cellen verdwenen |
| T2 zonder randen (alleen een headerregel) | Ja | 1.00 | 1.00 | perfect, exact raster |
| T3 samengevoegde 2-laags colspan-header | Ja | 1.00 | 0.97 | alle waarden aanwezig; één headerwaarde verschuift een rij |
| T4 samengevoegde rowspan-rijlabel, alleen op pagina | Nee | 0.0 | — | geclassificeerd als <!-- image --> |
| T5 colspan-header + zonder randen | Ja | 1.00 | 0.97 | alle waarden aanwezig; dezelfde header-rijverschuiving als T3 |
| T6 financiële tabel, lege kolom, rechts uitgelijnd | Ja | 1.00 | 1.00 | lege kolom behouden, niet verschoven |
| T7 brede grid met 12 kolommen | Ja | 1.00 | 1.00 | geen kolomverschuiving bij een brede tabel |
Van de vijf tabellen die Docling wel detecteerde, kwam elke ground-truth waarde gewoon mee — cell recall 1.00 overal. Bij drie van die vijf kwam ook elke waarde in de juiste rij terecht. Bij de twee cases met een meerlagige header (T3 en T5) schuift één headerwaarde uit zijn oorspronkelijke rij, waardoor de in-row rate naar 0.97 zakt — alle data is aanwezig, maar de rijtoewijzing wiebelt een beetje bij een gelaagde header.
De lastige structurele gevallen hielden beter stand dan ik had verwacht. De tweelaagse colspan-header werd correct afgevlakt naar GitHub-flavored Markdown (het label “Q1 2026” werd herhaald over de twee kolommen die het overspant, wat precies de juiste manier is om een colspan naar GFM om te zetten). Het randloze raster met alleen een headerregel (T2) kwam exact door. De brede tabel met 12 kolommen (T7) verschoof niet. En een volledig lege financiële kolom (T6) bleef behouden als lege cellen in plaats van verwijderd of samengevoegd. Dat sluit aan bij de officiële TableFormer TEDS-scores — 95,4 simpel, 90,1 complex, 93,6 alle tabellen — waarmee het model in de model card beter scoort dan Camelot (73,0) en EDD (88,3).
Een waarschuwing over samengevoegde cellen is hier wel op zijn plaats, want er is een open issue dat het tegenovergestelde beweert. Issue #3698 meldt dat V1 en V2 samengevoegde rijen en kolommen verkeerd behandelen. In mijn fixtures werden simpele colspan (T3/T5) en rowspan-waarden correct afgevlakt, met alleen de eerder genoemde rijverschuiving bij meerlagige headers. Maar de foutgevallen in #3698 gaan over onregelmatige multi-row/multi-column merges en tabellen over meerdere pagina’s — het pathologische eind van het spectrum. Mijn tests zitten aan de eenvoudige kant. De juiste formulering is dus smal: simpele colspan- en rowspan-waarden werden hier goed teruggevonden (meerlagige headers kunnen een rij verschuiven); complexe en onregelmatige merges blijven een gedocumenteerd open probleem. Niet “samengevoegde cellen werken”, maar ook niet “samengevoegde cellen zijn kapot”.
De valkuil: een tabel die alleen op een pagina staat kan verdwijnen
Kijk nog eens naar de tabel — T1 en T4 werden helemaal niet gedetecteerd. Docling gaf <!-- image --> terug en liet elk celletje vallen, zonder foutmelding. T1 is een volstrekt gewone tabel met randen, 8 rijen en 5 kolommen. Dat vond ik al zorgwekkend genoeg om het nog geen tabelparser-probleem te noemen voordat ik had uitgezocht wat het nu precies uitlokte, dus ik bouwde een gescripte A/B-test.
Eerst sloot ik de voor de hand liggende verklaringen uit. De tekstlaag is intact — pypdfium2 leest 327 tekens uit T1 en 221 uit T4, dus dit zijn echte digitale PDF’s, geen gescande afbeeldingen. OCR uitzetten (do_ocr=False) helpt niet; de tabellen verdwijnen nog steeds. En als je rechtstreeks in DoclingDocument kijkt, zie je len(doc.tables) == 0 terwijl len(doc.pictures) == 1 — het layoutmodel had de hele tabelregio dus als een Picture geclassificeerd.
Daarna de doorslaggevende test. Ik renderde exact dezelfde T1- en T4-tabellen opnieuw, maar dit keer omringd door een paar gewone alinea’s tekst, en converteerde opnieuw. Beide kwamen perfect door: len(doc.tables) == 1, correcte GFM-tabellen werden uitgegeven, en de rowspan-label “North” van T4b werd netjes over de drie rijen herhaald. Dezelfde tabel. Alleen de variabele veranderde: stond die alleen op een lege pagina, of was hij ingebed in tekst?
Dus de echte waarschuwing is niet dat TableFormer fragiel is — het is dat Docling’s RT-DETR-layoutmodel afhankelijk is van paginacontext, en een kleine tabel op een verder bijna lege pagina daardoor stilletjes als Picture kan worden gelezen en wegvalt. Dat komt in de praktijk makkelijk voor, omdat facturen, specificatiebladen en geknipte exports er precies zo uitzien: één tabel per pagina, geen omliggende tekst. De oplossing is saai maar effectief — geef het layoutmodel meer paginacontext, of controleer na conversie doc.tables en markeer pagina’s waar de count nul is. Dit ligt in de buurt van issue #3495 (een tabel die zowel als Table als Picture wordt gedetecteerd), maar de trigger van paginaarmoede — dezelfde tabel verdwijnt wanneer hij geïsoleerd staat, maar converteert zodra er tekst omheen staat — kon ik nergens gepubliceerd terugvinden. Gemeten, niet eerder gedocumenteerd; dus niet zomaar een bug die niemand kende.
OCR op echte scans: RapidOCR, niet EasyOCR
Gescande PDF’s zijn precies waar veel converters stilletjes op stuklopen, dus ik voerde Docling twee echte scans met een gemeten tekstlaag van 0 tekens aan — pypdfium2 rapporteert nul herstelbare tekens, wat bevestigt dat elke output OCR is en niet een verborgen tekstlaag.
Het eenpagina’s ocr_test.pdf kwam op CPU netjes terug in 14,3 seconden: “Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” letterlijk hersteld. Het vier pagina’s tellende nemotron_multipage.pdf liet OCR op alle vier pagina’s lopen in 70,1 seconden totaal (17,5 s/pagina), en zette op elke pagina de testzin opnieuw neer. De standaard OCR draaide automatisch — geen flag, geen configuratie.
Hier zit een detail dat veel artikelen fout hebben: de standaard OCR-engine is RapidOCR, niet EasyOCR. Dat bevestigde ik doordat de PP-OCRv4 .pth-weights bij de eerste run werden gedownload. Veel bestaande blogs en oudere Docling-FAQ-teksten zeggen nog steeds dat EasyOCR de standaard is; dat is verouderd. EasyOCR is inmiddels een extra die je bewust inschakelt. Wat nog steeds klopt: OCR is op schaal het trage pad, en alles hier is een CPU-only bovengrens — met GPU zouden deze tijden aanzienlijk lager liggen.
Echte PDF’s, leesvolgorde en tijd per pagina
Synthetische fixtures bewijzen specifieke gedragingen; echte PDF’s bewijzen dat het ook echt werkt. Ik draaide twee born-digital academische papers — het 9-pagina’s tellende Docling technical report en “Attention Is All You Need” van 15 pagina’s, allebei tweekoloms en met tabellen en formules.
In het 15-pagina’s tellende Attention-paper verschijnen alle vijf sectiemarkers — Abstract, Introduction, Background, Conclusion, References — in documentvolgorde in de lineaire Markdown, ondanks de tweekoloms lay-out. Elke contentprobe (Transformer, encoder, BLEU, multi-head) is aanwezig, en de bekende resultaten-tabellen met meerdere kolommen worden als vier gedetecteerde tabellen geregistreerd. Dat is echte reconstructie van leesvolgorde en kolomsamenvoeging, en dat is precies de kernwaarde voor RAG-chunking — je kunt een document niet netjes chunk-en als de linearizer een tweekolomspagina tot door elkaar gehusselde tekst maakt.
De timing laat een contra-intuïtieve les zien. Tijd per pagina wordt bepaald door hoeveel structuur er op elke pagina staat, niet door het aantal pagina’s. Het dichtere 9-pagina’s tellende rapport liep op 14,95 seconden per pagina — langzamer per pagina dan het 15-pagina’s tellende paper met 5,99 seconden per pagina — omdat er per pagina meer tabellen en figuren in zitten — 3 tabellen over 9 pagina’s tegenover 4 over 15 — en elke extra structuur meer layout- en TableFormer-inferentie triggert. Dat is een dun verschil, en in absolute zin heeft het dichtere document juist minder tabellen, niet meer. Dus “seconden per pagina” op CPU hangt af van structurele dichtheid, niet van lengte. Dit is één CPU-only run; het is een bovengrens, geen productiegetal.
Multi-format en de claim van lossless JSON
Docling adverteert uniforme parsing voor meerdere formaten, dus ik maakte een DOCX, een XLSX en een PPTX met bekende inhoud en ground-truth probes, en controleerde vervolgens twee dingen: verschijnen die probes in de Markdown, en overleven ze de JSON-roundtrip via export_to_dict()?
| Bestand | Conversie s | MD probes gevonden | Tabellen in MD | Probes overleven JSON |
|---|---|---|---|---|
report.docx (koppen + samengevoegde "Total"-tabel + bullets) | 0.137 | 7/7 | 1 | Ja |
workbook.xlsx (2 sheets, lege kolom) | 0.016 | 6/6 | 2 | Ja |
deck.pptx (3 slides, bullets + tabel) | 0.038 | 6/6 | 1 | Ja |
Alle inhoudsprobes kwamen in de Markdown terecht, tabellen werden hersteld (inclusief de samengevoegde “Total”-rij uit de DOCX en beide XLSX-sheets), en elke probe overleefde ook de export_to_dict()-JSON — dat is het bewijs dat telt voor de claim van lossless DoclingDocument, tenminste op schone inputs. Deze formaten lopen via formaat-native backends in plaats van via de ML-modellen, en daarom draaien ze in tienden van seconden en werken ze volledig offline. De scope is eerlijk: één schoon bestand per formaat bewijst breedte, geen stress test van kapotte Office-bestanden.
HTML: trouw, maar niet schoon
Dit is de waarschuwing die bepaalt of Docling in je RAG-pijplijn past, dus lees dit goed. Docling converteert het hele HTML-document. Het doet geen readability-achtige hoofdcontent-extractie. Ik heb gemeten hoeveel site-chrome bewaard blijft door nav-, TOC-, cookie- en footer-markers in de output van Docling zelf te tellen.
| Pagina | Niet-lege MD-regels | Boilerplate-regels | % boilerplate | Artikel begint op regel |
|---|---|---|---|---|
| Wikipedia "Web scraping" | 255 | 34 | 13.3% | 28 |
| scrapethissite/forms | 63 | 1 | 1.6% | — |
| books.toscrape | 65 | 0 | 0.0% | — |
| quotes.toscrape | 35 | 0 | 0.0% | — |
Op een pagina met veel chrome, zoals Wikipedia, bestaat ongeveer 13% van de Markdown-regels uit nav/TOC/footer-boilerplate, en begint het echte artikel pas op regel 28 — de output opent met “move to sidebar / Contents / Toggle the table of contents” en eindigt met “CS1 maint… / Search Wikipedia.” Op schone contentpagina’s (books, quotes) is dat ongeveer 0%, dus dit is een probleem van templates en chrome, niet van een vaste kostenpost per pagina. Docling geeft je getrouwe Markdown van het volledige document, niet een schone extractie van alleen de hoofdtekst. Upstream houdt het HTML-furniturprobleem bij in issue #1865 (gesloten) en #1930 (open).
Twee dingen houden dit oordeel eerlijk. Ten eerste draait Docling voor HTML helemaal geen ML-modellen — het is een BeautifulSoup-backend op een eenvoudige pipeline. Het verhaal dat visionmodellen je pagina lezen geldt alleen voor PDF en afbeeldingen; geef Docling HTML en geen enkel layout- of TableFormer-mechanisme wordt geactiveerd. Ten tweede probeert het PDF-pad wél header- en footer-furniture te classificeren, dus “helemaal geen boilerplateverwijdering” zou te sterk zijn — het is specifiek de HTML-backend die de chrome teruggeeft.
Hoe het zich verhoudt tot anderen (en waar Thunderbit past)
Probeer Thunderbit voor webdata-extractie
De tool waarmee mensen Docling het vaakst vergelijken is Firecrawl, dus hier is een positioneringstabel. Eén kanttekening vooraf, omdat die ertoe doet: dit is een vergelijking op documentatieniveau, geen benchmark op dezelfde machine. Ik heb Firecrawl niet op deze fixtures gedraaid. Alleen de Docling-kolom is hier gemeten; de Firecrawl-kolom komt uit de publieke documentatie.
| As | Firecrawl (volgens de docs) | Docling (hier gemeten) |
|---|---|---|
| Kernfunctie | Crawl + scrape het live web → Markdown | Zet een document dat je al hebt om → Markdown/JSON |
| Ophalen / JS-render / anti-bot | Ja (gehoste browser) | Nee — jij levert het bestand aan |
| Extractie van hoofdcontent | Ja | Nee — getrouwe volledige documentweergave (~13% chrome op Wikipedia) |
| PDF-tabelstructuur (ML) | beperkt | Ja — TableFormer (officiële TEDS 93.6; cell recall 1.00, in-row 0.97–1.00 op gedetecteerde fixtures) |
| Gescande PDF / OCR | beperkt | Ja — RapidOCR standaard (herstelde een scan met 0-tekstenlaag) |
| Formaatbreedte | webpagina’s | PDF/DOCX/PPTX/XLSX/HTML/EPUB/afbeeldingen |
| Deployment | gehoste API (+ self-host) | lokale pip-library, offline, geen API-key |
| Setupgewicht | API-key / lichte client | 1,3 GB standaardinstallatie + ~506 MiB modellen (of docling-slim) |
| Licentie | commercieel / source-available | MIT |
De versie in één zin: Firecrawl is de tool wanneer je data op het live web staat en moet worden gecrawld, gerenderd via JS en opgeschoond tot hoofdcontent. Docling is de tool wanneer je het document al hebt — vooral PDF’s, scans en Office-bestanden met veel tabellen — en je een offline, structuurbehoudende conversie wilt met echte tabel- en OCR-intelligentie. Ze vullen elkaar aan. Een realistische pipeline crawlt met de een en zet documenten om met de ander.
En dan ben ik ook gewoon eerlijk over Thunderbit, want ik werk hier en het zou terecht verdacht zijn als ik deed alsof dat niet zo was. Thunderbit en Docling doen niet hetzelfde, en ik ga ze niet kunstmatig gelijk trekken. Voor developers is Thunderbit een AI scraping API plus MCP server plus CLI, en de eenheid van werk is de live webpagina: POST /distill zet een URL om in schone, LLM-klare Markdown (inclusief JS-rendering, anti-bot en CAPTCHA waar Docling expliciet niets mee doet), en POST /extract geeft schema-overeenkomende gestructureerde JSON terug via een JSON Schema dat je zelf definieert. Dat is het ophalen-en-schoonmaken-gedeelte van een RAG-pijplijn. Docling is het lokale-documentgedeelte — de PDF, de scan, het spreadsheet dat al op je schijf staat. Als je corpus uit webpagina’s bestaat, kies dan voor Thunderbit’s API, de MCP-tools (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) of de CLI (npx @thunderbit/thunderbit-cli). Zijn het PDF’s en scans, dan kies je Docling. En als het allebei is — wat in de praktijk meestal zo is — combineer je ze, en probeert geen van beide de ander te zijn.
Het oordeel: voorlopig, met huiswerk dat nog openstaat
Ik ga je geen enkele score van 0–100 geven, omdat een gewogen totaalscore hier ook straffen zou meenemen voor dingen die Docling nooit heeft geclaimd te doen (zoals crawlen) en zou doen alsof die vergelijkbaar zijn. Per dimensie, op de fixtures die ik testte:
- Setup / eerste run: zwaar — venv van 1,3 GB, ~506 MiB modellen, ~224s eerste PDF, ~0,55s warm — maar
docling-slimlaat je die zwaarte vermijden. - Tabelnauwkeurigheid: sterk zodra een tabel wordt gedetecteerd (cell recall 1.00 op 5/5, in-row 0.97–1.00), in lijn met het officiële TEDS-verhaal op deze fixtures.
- Robuustheid van tabeldetectie: de sparse-page-valkuil — een geïsoleerde tabel kan als Picture verdwijnen. Controleer
doc.tablesna afloop. - Gescand / OCR: werkt, RapidOCR standaard; traag op schaal.
- Multi-format: degelijk, met een intacte JSON-roundtrip.
- HTML: trouw, niet schoon — geen extractie van alleen de hoofdcontent.
- Developer experience: nette API van 3 regels en een overzichtelijke
DoclingDocument, minus de ontbrekende__version__.
Voor wie is het bedoeld: teams die RAG- of datapijplijnen bouwen rond PDF’s, scans en Office-bestanden en offline, structuurbehoudende conversie willen met echte tabel- en OCR-ondersteuning. Voor wie niet: iedereen die live-web-crawling of schone HTML-extractie van alleen hoofdartikelen nodig heeft — daarvoor heb je een ander type tool nodig.
En omdat dit een review is en geen persbericht, blijven de beperkingen gewoon zichtbaar. Dit is een gerichte probe — 7 synthetische tabellen plus 2 echte PDF’s op één CPU-only machine — en geen TEDS-schaal accuracy benchmark. Een aantal dingen heb ik niet getest, maar zou je wel moeten testen voordat je een pijplijn op Docling bouwt: het optionele VLM-pad (GraniteDocling), de echte footprint van docling-slim, een GPU-run, complexe en onregelmatige samengevoegde cellen plus tabellen over meerdere pagina’s, de trouw van formule-naar-LaTeX, en — waarschijnlijk het meest verrassende in productie — de duurzaamheid van batch-geheugengroei, thread/GIL-schaalbaarheid en objectlevenscyclus over duizenden conversies. Docling is sterk in wat het claimt, gemeten in plaats van geadverteerd, en heeft echte randen die je in kaart wilt brengen voordat je het op een corpus loslaat. Ken de sparse-page-waarschuwing, reserveer ruimte voor de eerste download en verifieer zelf hoe het op schaal gedraagt.
Probeer Thunderbit voor webdata-extractie Get Started Free
FAQ’s
Is Docling een webscraper of crawler? Nee. Docling zet documenten die je al hebt — PDF, DOCX, PPTX, XLSX, HTML, afbeeldingen — om naar Markdown of JSON. Het haalt geen URL’s op, rendert geen JavaScript en handelt geen anti-bot af. Crawling van het live web is een aparte taak voor tools zoals Firecrawl of Thunderbit’s web-API; Docling begint bij het bestand dat jij aanlevert.
Hoe groot zijn de Docling-installatie en de eerste download?
Het standaard docling-metapackage levert een venv van ongeveer 1,3 GB op, omdat het de volledige ML-stack als harde afhankelijkheden meeneemt (alleen torch is al 536 MiB). De eerste PDF-conversie downloadt ongeveer 506 MiB aan layout- en TableFormer-modellen naar schijf plus ongeveer 40 MB RapidOCR-weights, en duurt ongeveer 224 seconden — bijna volledig downloadtijd. De tweede conversie duurt ongeveer 0,55 seconden. Als je alleen lichte formaten nodig hebt, slaat docling-slim (~50 MB core) het zware pad over.
Doet Docling OCR, en met welke engine? Ja. Op een gescande PDF zonder tekstlaag start de OCR van Docling automatisch en herstelde in mijn test de tekst netjes. De standaardengine is RapidOCR, niet EasyOCR — een veelgemaakte fout in oudere artikelen. EasyOCR is nu een optionele extra. OCR is op schaal het trage pad, vooral op CPU.
Waarom veranderde Docling mijn tabel in een afbeelding of liet hij die verdwijnen?
Waarschijnlijk door het sparse-page-effect. Docling’s RT-DETR-layoutmodel gebruikt paginacontext, en een kleine tabel die alleen op een bijna lege pagina staat kan als Picture worden geclassificeerd en zonder foutmelding verdwijnen. Dezelfde tabel, omringd door lopende tekst, wordt prima geconverteerd. De oplossing is om het layoutmodel meer paginacontext te geven, of na conversie doc.tables te controleren en elke pagina met een nul-waarde te markeren.
Docling vs Firecrawl — welke moet ik gebruiken? Dat zijn verschillende taken, dus meestal is het niet óf-óf. Firecrawl crawlt het live web, rendert JavaScript en extraheert hoofdcontent. Docling zet documenten om die je al hebt, met echte PDF-tabelstructuur en OCR, volledig offline. Als je bron uit webpagina’s bestaat, gebruik dan een webtool (Firecrawl, of Thunderbit’s API/MCP/CLI). Gaat het om PDF’s, scans of Office-bestanden, gebruik dan Docling. In de meeste echte pipelines gebruik je allebei.
