Docling wordt steeds weer in hetzelfde hokje gestopt als webscrapers, maar dat klopt 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 praktische review van een converter, geen crawler. Alles hieronder is gemeten op één CPU-only machine (macOS arm64, Python 3.14.2, Docling 2.111.0), met scores uit scripts en fouten gewoon als fouten geregistreerd. De repository is gigantisch en verandert dagelijks — 63.069 sterren, 4.449 forks, en een push op dezelfde dag dat ik de metadata ophaalde — dus zie elk getal of versienummer hier als een momentopname, niet als iets vasts.
Wat Docling Wel Is — en Niet Is
Alles in Docling draait om één kernobject: het DoclingDocument. Parse een bestand naar die structuur en exporteer daarna naar Markdown, HTML, DocTags of lossless JSON. De code is MIT-gelicentieerd (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 functie zit in de PDF- en afbeeldingsroute. Dat is niet simpelweg string parsing, maar een stapel machine-learningmodellen: 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 de moeite waard is om te beoordelen, en precies het deel dat een test met alleen HTML nooit zou raken.
Eén onderscheid voorkomt een week verwarring: Docling haalt zelf niets op. Het rendert geen JavaScript, breekt niet door anti-botmaatregelen en crawlt niet. Jij levert het bestand aan; Docling doet het begrip. Crawling is werk voor een ander soort tool — en dat wordt later belangrijk als mensen vragen of Docling Firecrawl vervangt (dat doet het niet; ze vullen elkaar aan, en ik leg straks uit waarom).
De Eerste Run Waar Niemand Je Voor Waarschuwt
pip install docling verloopt probleemloos op Python 3.14.2. Daarna kijk je in je venv en zie je 1,3 GB. Docling trekt de volledige ML-stack binnen als harde dependency, zelfs als je alleen ooit 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) | 75,6 |
| docling_parse | 30 |
En dat nog vóór je één PDF omzet. De echte frictie komt bij de eerste PDF-conversie, want dan worden de modellen gedownload. Op een verse, geïsoleerde HuggingFace-cache duurde de eerste PDF-conversie ongeveer 224 seconden — en vrijwel alles daarvan is downloadtijd, niet rekentijd. De layout- en TableFormer-modellen nemen samen ongeveer 506 MiB op schijf in beslag (342 MiB TableFormer + 164 MiB layout, geverifieerd met du), en RapidOCR haalt ongeveer 40 MB aan PP-OCRv4-gewichten binnen in site-packages. De tweede conversie van hetzelfde bestand? 0,55 seconden. De modellen zijn dan gecachet; die tol betaal je maar één keer.
Eén getal kun je beter negeren: het coldstart-script meldt een model_download_mb van 1060.2. Citeer dat niet als echte footprint. Die waarde komt uit een os.walk die symlinks volgt, en de HuggingFace-cache bewaart elk modelbestand één keer onder blobs/ en zet het daarna opnieuw zichtbaar via snapshots/-symlinks — waardoor de walk de 14 modelbestanden dubbel telt. De du-overeenkomende, symlink-gede-dupliceerde waarde is ongeveer 506 MiB (alleen blobs: 505,4 MiB). De les voor iedereen die Docling benchmarkt: rapporteer downloadbytes en bytes op schijf als twee aparte cijfers, want dat zijn ze ook.
Er is nog een tweede addertje onder het gras voor iedereen die een Docling-container bouwt. De gewichten worden over twee locaties en volgens twee schema’s gesplitst. De layout- en TableFormer-modellen respecteren HF_HOME en downloaden bij de eerste PDF-conversie. De modellen van RapidOCR doen dat niet — die landen in …/site-packages/rapidocr/models/ en omzeilen je cache-instellingen volledig. Als je een image vooraf wilt inbakken of volledig offline wilt draaien, moet je dus beide caches meenemen; HF_HOME alleen vangt de tweede niet af.
Nu het eerlijke deel. Sinds eerdere releases heeft het project docling-slim uitgebracht — een kern van ongeveer 50 MB waarmee je pip install docling-slim[format-html] kunt gebruiken voor HTML zonder torch mee te trekken. Die 1,3 GB is dus echt voor het standaard docling-metapackage, maar het is inmiddels optioneel. Ik heb het standaardpakket getest omdat pip install docling dat nog steeds oplevert, maar de zwaarte is geen onbehandeld probleem meer — de modulaire oplossing bestaat en wordt gevolgd in issue #2393.
Tijdens het opzetten kwam ik nog één klein irritatiepunt tegen dat het vermelden waard is: import docling; docling.__version__ geeft AttributeError: module 'docling' has no attribute '__version__'. De module exposeert die waarde simpelweg niet. De werkende manier is importlib.metadata.version("docling"), en dat geeft '2.111.0'. Kleine DX-frustratie, sinds juli 2026 open als issue #3733.
Tabelnauwkeurigheid: Waar TableFormer Zijn Waarde Bewijst
Tabellen zijn precies de reden waarom mensen voor Docling kiezen in plaats van een simpele PDF-naar-tekstdump. Daarom heb ik zeven tabel-PDF’s gemaakt met machineleesbare ground truth en de output cel voor cel gescoord. Twee metrics doen ertoe, en die zijn niet hetzelfde: cell recall is het aandeel ground-truthwaarden dat ergens in de gedetecteerde tabel terugkomt; in-row rate is het aandeel dat ook in de juiste rij terechtkomt. Die twee door elkaar halen maakt de tool mooier dan hij is, dus hier staan ze allebei:
| Tabel (stress) | Gedetecteerd | Cell recall | In-row rate | Opmerking |
|---|---|---|---|---|
| T1 simpel tabelraster met randen (5×8), 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 gevonden; éé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 gevonden; dezelfde verschuiving in de header-rij als T3 |
| T6 financiële tabel, lege kolom, rechts uitgelijnd | Ja | 1.00 | 1.00 | lege kolom blijft behouden, niet verschoven |
| T7 breed raster met 12 kolommen | Ja | 1.00 | 1.00 | geen kolomverschuiving in een brede tabel |
Van de vijf tabellen die Docling wél detecteerde, kwam elk ground-truthgegeven netjes door — cell recall 1.00 overal. Bij drie van die vijf kwam ook elke waarde in de juiste rij terecht. Bij de twee cases met meerdere headerlagen (T3 en T5) schuift één headerwaarde van de oorspronkelijke rij af, waardoor de in-row rate zakt naar 0,97 — alle data is aanwezig, alleen de rijtoewijzing wiebelt één positie bij een gestapelde header.
De lastige structurele gevallen hielden beter stand dan ik had verwacht. De twee-laags colspan-header werd correct afgevlakt naar GitHub-flavored Markdown (het label “Q1 2026” werd herhaald over de twee spankolommen, wat de juiste manier is om een colspan in GFM samen te vatten). Het tabelraster zonder randen 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 als lege cellen behouden in plaats van te verdwijnen of samengevoegd te worden. Dat sluit aan bij de officiële TableFormer TEDS-scores — 95,4 voor simpel, 90,1 voor complex, 93,6 overall — waarmee het model duidelijk boven Camelot (73,0) en EDD (88,3) scoort.
Een waarschuwing over samengevoegde cellen: er is een open issue dat het tegenovergestelde meldt. Issue #3698 zegt dat V1 en V2 samengevoegde rijen en kolommen verkeerd afhandelen. Op mijn fixtures werden simpele colspan (T3/T5) en rowspan-waarden correct afgevlakt, met alleen de eerder genoemde rijverschuiving bij de meerlagige headers. Maar de falende gevallen uit #3698 gaan over onregelmatige multi-row/multi-column merges en tabellen over meerdere pagina’s — de pathologische uiterste gevallen. Die van mij zitten aan de simpele kant. De juiste conclusie is dus smal: simpele colspan- en rowspan-waarden werden hier goed herkend (meerlagige headers kunnen een rij verschuiven); complexe en onregelmatige merges blijven een bekend open probleem. Niet “samengevoegde cellen werken”, en ook niet “samengevoegde cellen zijn kapot.”
De Valkuil: Een Tabel Alleen Op Een Pagina Kan Verdwijnen
Kijk nog eens naar de tabel: T1 en T4 werden helemaal niet gedetecteerd. Docling gaf <!-- image --> terug en gooide alle cellen weg, zonder foutmelding. T1 is een volstrekt normale tabel met randen van 5×8. Dat vond ik alarmerend genoeg om het niet meteen als een algemene tabelparser-zwakte te bestempelen; eerst wilde ik exact weten wat het triggerde, dus ik bouwde een scripted 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 direct in DoclingDocument kijkt, zie je len(doc.tables) == 0 terwijl len(doc.pictures) == 1 — het layoutmodel had het hele tabelgebied als Picture geclassificeerd.
Toen kwam de beslissende test. Ik renderde exact dezelfde T1- en T4-tabellen opnieuw, maar dit keer met een paar gewone alinea’s tekst eromheen, en converteerde opnieuw. Beide kwamen nu perfect door: len(doc.tables) == 1, correcte GFM-tabellen, en T4b’s rowspan-label “North” werd netjes over de drie rijen herhaald. Zelfde tabel. Alleen de context veranderde: stond hij alleen op een lege pagina, of zat hij ingebed in tekst.
De echte waarschuwing is dus niet dat TableFormer fragiel is, maar dat Docling’s RT-DETR-layoutmodel paginacontext gebruikt, en dat een kleine tabel op een verder bijna lege pagina waarschijnlijk als Picture wordt gelezen en stilletjes verdwijnt. Dat is in de praktijk makkelijk te raken, omdat facturen, specificatiesheets en uitgeknipte exports er precies zo uitzien: één tabel per pagina, zonder omringende tekst. De oplossing is saai maar effectief: geef het layoutmodel paginacontext, of check na conversie doc.tables en markeer pagina’s waar de teller nul is. Dit ligt dicht bij issue #3495 (een tabel die zowel als Table als Picture werd gedetecteerd), maar die specifieke pagina-sparsity-trigger — dezelfde tabel verdwijnt geïsoleerd, maar converteert mét context — kon ik nergens eerder gedocumenteerd vinden. Gemeten, niet eerder beschreven; niet zomaar een bug die niemand kende.
OCR op Echte Scans: RapidOCR, Niet EasyOCR
Gescande PDF’s zijn precies waar veel converters stilletjes falen, dus ik voerde Docling twee echte scans met een gemeten tekstlaag van 0 tekens. pypdfium2 meldt nul herstelde tekens, wat bevestigt dat elke output echt OCR is en niet een verborgen tekstlaag die toevallig meegaat.
De enkele pagina ocr_test.pdf kwam op CPU schoon terug in 14,3 seconden: “Docling bundles PDF document conversion to JSON and Markdown in an easy self contained package,” letterlijk hersteld. De vier pagina’s van nemotron_multipage.pdf zetten OCR op alle vier de pagina’s aan in totaal 70,1 seconden (17,5 s/pagina), en de testzin werd per pagina herhaald. De standaard OCR draaide automatisch — geen vlag, geen configuratie.
Hier zit een detail dat veel artikelen fout hebben: de standaard OCR-engine is RapidOCR, niet EasyOCR. Dat heb ik bevestigd doordat de PP-OCRv4 .pth-gewichten bij de eerste run werden gedownload. Veel bestaande blogs en oudere Docling-FAQ’s zeggen nog steeds dat EasyOCR de standaard is; dat is verouderd. EasyOCR is nu een extra die je expliciet inschakelt. Wat wel overeind blijft: OCR is de trage route op schaal, en alles hier is een CPU-only bovengrens — op GPU zouden deze tijden flink lager uitvallen.
Echte PDF’s, Leesvolgorde en Tijd per Pagina
Synthetische fixtures bewijzen specifieke gedragingen; echte PDF’s bewijzen dat het systeem ook echt werkt. Ik testte twee born-digital academische papers — het technische Docling-rapport van 9 pagina’s en “Attention Is All You Need” van 15 pagina’s, beide tweetalig in kolommen 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 lay-out met twee kolommen. Elke inhoudsprobe (Transformer, encoder, BLEU, multi-head) is aanwezig, en de beroemde resultaten-tabellen over meerdere kolommen worden als vier gedetecteerde tabellen geregistreerd. Dat is echte reconstructie van leesvolgorde en kolommen, en precies de kernwaarde voor RAG-chunking — je kunt een document niet zinvol knippen als de linearizer een tweekolomspagina door elkaar husselt.
De timing laat een onverwachte les zien. De tijd per pagina wordt bepaald door hoeveel structuur er op elke pagina staat, niet door het aantal pagina’s. Het dichtere rapport van 9 pagina’s draaide op 14,95 seconden per pagina — dus trager per pagina dan het 15-pagina’s tellende paper met 5,99 seconden per pagina — omdat het meer tabellen en figuren bevat, en elk daarvan extra layout- en TableFormer-inferentie triggert. Dus “seconden per pagina” op CPU is een functie van structuurdichtheid, niet van lengte. Dit is één CPU-only run; het is een bovengrens, geen productiegetal.
Multi-Format en de Lossless-JSON-bewering
Docling claimt een uniforme parser voor meerdere formaten, dus ik genereerde een DOCX, een XLSX en een PPTX met bekende content en ground-truth probes, en controleerde twee dingen: komen die probes in de Markdown terug, 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 landden in de Markdown, tabellen werden hersteld (inclusief de samengevoegde “Total”-rij uit de DOCX en beide XLSX-sheets), en elke probe overleefde ook de JSON van export_to_dict(). Dat is het bewijs dat telt voor de claim van een lossless DoclingDocument, althans op schone inputs. Deze formaten lopen via format-native backends in plaats van de ML-modellen, en daarom zijn ze in tientallen milliseconden klaar en volledig offline te gebruiken. De scope is eerlijk: één schoon bestand per formaat bewijst breedte, geen stress test met pathologische Office-bestanden.
HTML: Nauwkeurig, Maar Niet Schoon
Dit is de waarschuwing die bepaalt of Docling in je RAG-pijplijn thuishoort, dus lees dit goed. Docling converteert het hele HTML-document. Het doet geen readability-achtige main-content-extractie. Ik heb gemeten hoeveel site-chrome behouden blijft door nav-, TOC-, cookie- en footer-markers in Docling’s eigen output 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 chrome-zware pagina zoals Wikipedia bestaat ongeveer 13% van de Markdown-regels uit nav/TOC/footer-boilerplate, en het echte artikel begint 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 het ongeveer 0%, dus dit is een template-chromeprobleem, geen belasting per pagina. Docling geeft je trouwe Markdown van het volledige document, geen opgeschoonde hoofdtekstextractie. Upstream houdt het HTML-furnitureprobleem bij in issue #1865 (gesloten) en #1930 (open).
Twee dingen maken dit eerlijk. Ten eerste draait Docling op HTML helemaal geen ML-modellen — het is een BeautifulSoup-backend op een simpele pipeline. Het verhaal over visionmodellen die je pagina “lezen” geldt alleen voor PDF en afbeeldingen; geef Docling HTML en geen enkele layout- of TableFormer-machine komt op gang. Ten tweede probeert de PDF-route wel header- en footer-furniture te classificeren, dus zeggen dat er “helemaal geen boilerplate wordt verwijderd” zou te ver gaan — het is specifiek de HTML-backend die de chrome teruggeeft.
Hoe Het Zich Verhoudt — 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, want die doet ertoe: 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.
| Aspect | Firecrawl (volgens de docs) | Docling (hier gemeten) |
|---|---|---|
| Kerntaak | De live web crawlen en scrapen → Markdown | Een document dat je al hebt converteren → Markdown/JSON |
| Ophalen / JS-rendering / anti-bot | Ja (gehoste browser) | Nee — jij levert het bestand aan |
| Extractie van hoofdcontent | Ja | Nee — getrouwe volledige documentoutput (~13% chrome op Wikipedia) |
| PDF-tabelstructuur (ML) | beperkt | Ja — TableFormer (TEDS 93,6 officieel; cell recall 1.00, in-row 0.97–1.00 op gedetecteerde fixtures) |
| Gescande PDF / OCR | beperkt | Ja — RapidOCR standaard (herstelde een scan zonder tekstlaag) |
| Formaatbreedte | webpagina’s | PDF/DOCX/PPTX/XLSX/HTML/EPUB/afbeeldingen |
| Deployment | gehoste API (+ self-host) | lokale pip-bibliotheek, offline, geen API-key |
| Installatielast | API-key / lichte client | 1,3 GB standaardinstallatie + ~506 MiB modellen (of docling-slim) |
| Licentie | commercieel / source-available | MIT |
De korte versie: Firecrawl is de tool voor data die op het live web staat en crawling, JavaScript-rendering en opschoning van hoofdcontent nodig heeft. Docling is de tool voor documenten die je al hebt — vooral PDF’s, scans en Office-bestanden met veel tabellen — en waar je een getrouwe, offline conversie wilt die structuur behoudt en echte tabel- en OCR-inzicht meeneemt. Ze vullen elkaar aan. In een realistische pipeline crawl je met de ene en converteer je documenten met de andere.
Daarbij moet ik ook eerlijk zijn 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 werk, en ik ga die twee niet kunstmatig gelijkstellen. Voor ontwikkelaars is Thunderbit een AI scraping API plus MCP-server plus CLI, en de werkeenheid is de live webpagina: POST /distill zet een URL om naar schone, LLM-klare Markdown (inclusief JS-rendering, anti-bot en CAPTCHA die Docling expliciet niet aanraakt), en POST /extract geeft schema-gebonden gestructureerde JSON terug via een JSON Schema dat jij definieert. Dat is de fetch- en schoonmaak-kant van een RAG-pijplijn. Docling is de lokale documentkant — de PDF, de scan, de spreadsheet die al op je schijf staat. Als je corpus uit webpagina’s bestaat, kies dan Thunderbit’s API, de MCP-tools (thunderbit_suggest_fields, thunderbit_distill, thunderbit_extract) of de CLI (npx @thunderbit/thunderbit-cli). Als het PDF’s en scans zijn, kies dan Docling. Als het allebei is — wat in de meeste echte pijplijnen zo is — gebruik je ze samen, en geen van beide probeert de ander te zijn.
Het Oordeel: Voorlopig, Met Huiswerk Over
Ik ga je geen enkele score van 0–100 geven, omdat een gewogen totaalscore hier strafpunten zou meerekenen voor dingen die Docling nooit heeft beloofd te doen (zoals crawlen) en zou doen alsof die vergelijkbaar zijn. Per dimensie, op de fixtures die ik testte:
- Installatie / eerste run: zwaar — 1,3 GB venv, ~506 MiB modellen, ~224 s eerste PDF, ~0,55 s warm — maar
docling-slimmaakt de zware route optioneel. - Tabelnauwkeurigheid: sterk zodra een tabel gedetecteerd wordt (cell recall 1.00 op 5/5, in-row 0.97–1.00), en dat sluit aan bij het officiële TEDS-verhaal op deze fixtures.
- Robuustheid van tabeldetectie: de valkuil van sparseness — een geïsoleerde tabel kan als Picture verdwijnen. Check
doc.tablesachteraf. - Gescand / OCR: werkt, RapidOCR standaard; traag op schaal.
- Multi-format: degelijk, met intacte JSON-roundtrip.
- HTML: trouw, maar niet schoon — geen hoofdcontentextractie.
- Developer experience: nette API in drie regels en een overzichtelijke
DoclingDocument, minus de ontbrekende__version__.
Voor wie het is: 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 het niet is: iedereen die live web crawling of een nette extractie van hoofdartikelen uit HTML nodig heeft — dat is een andere tool.
En omdat dit een review is en geen persbericht, blijven de beperkingen gewoon staan. Dit is een gerichte probe — 7 synthetische tabellen plus 2 echte PDF’s op één CPU-only machine — geen TEDS-schaal accuracy benchmark. Er zijn meerdere dingen die ik niet testte en die je zelf moet testen voordat je een pipeline op Docling bouwt: het optionele VLM-pad (GraniteDocling), de echte footprint van docling-slim, een GPU-run, complexe en onregelmatige merged cells plus tabellen over meerdere pagina’s, formule-naar-LaTeX-nauwkeurigheid, en — waarschijnlijk de grootste verrassing in productie — de duurzaamheid onder batchgeheugengroei, thread/GIL-schaalbaarheid en object lifecycle over duizenden conversies. Docling is sterk in wat het claimt, gemeten in plaats van geadverteerd, en er zitten echte randen aan die je in kaart wilt brengen voordat je het op een corpus loslaat. Ken de sparse-page-waarschuwing, budgetteer voor de download bij de eerste run, en verifieer het gedrag op schaal zelf.
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 omzeilt geen anti-botmaatregelen. Het crawlen 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 download bij de eerste run?
Het standaard docling-metapackage levert een venv van ongeveer 1,3 GB op, omdat het de volledige ML-stack als harde dependency binnenhaalt (torch alleen al is 536 MiB). De eerste PDF-conversie downloadt ongeveer 506 MiB aan layout- en TableFormer-modellen naar schijf plus ongeveer 40 MB aan RapidOCR-gewichten, en duurt ongeveer 224 seconden — vrijwel volledig downloadtijd. De tweede conversie duurt ongeveer 0,55 seconden. Als je alleen lichte formaten nodig hebt, slaat docling-slim (kern van ongeveer 50 MB) het zware pad over.
Doet Docling OCR, en met welke engine? Ja. Op een gescande PDF zonder tekstlaag start OCR automatisch en werd de tekst in mijn test netjes hersteld. De standaard engine is RapidOCR, niet EasyOCR — een veelgemaakte fout in oudere beschrijvingen. EasyOCR is nu een optionele extra. OCR is op schaal de trage route, vooral op CPU.
Waarom veranderde Docling mijn tabel in een afbeelding of verdween hij gewoon?
Waarschijnlijk door het sparse-page-effect. Docling’s RT-DETR-layoutmodel gebruikt paginacontext, en een kleine tabel die alleen op een vrijwel lege pagina staat kan als Picture worden geclassificeerd en zonder foutmelding verdwijnen. Diezelfde tabel, omringd door gewone tekst, converteert prima. De oplossing is om het layoutmodel meer paginacontext te geven, of na conversie doc.tables te controleren en pagina’s met een teller van nul te markeren.
Docling vs Firecrawl — welke moet ik gebruiken? Andere taken, dus meestal is het niet of-of. Firecrawl crawlt het live web, rendert JavaScript en extraheert hoofdcontent. Docling converteert documenten die je al hebt, met echte PDF-tabelstructuur en OCR, volledig offline. Als je bron webpagina’s zijn, gebruik dan een webtool (Firecrawl, of Thunderbit’s API/MCP/CLI). Als het PDF’s, scans of Office-bestanden zijn, gebruik Docling. In de praktijk gebruiken de meeste pipelines beide.
