Bijna elke roundup met de titel “beste open-source scraper” maakt één stille denkfout: niemand test de tools op exact dezelfde pagina’s. Scrapy wordt beoordeeld op een nieuwsartikel, Playwright op een e-commerce-demo, Colly op wat de auteur toevallig nog had liggen — en daarna zet men ze naast elkaar alsof die cijfers ooit hetzelfde konden betekenen. Zo’n ranking zegt vooral iets over de pagina’s, niet over de tools.
Dus deed ik het saaie, voor de hand liggende werk dat die lijstjes overslaan. Ik bouwde één set testfixtures en draaide alle negen tools erdoorheen: een statische catalogus, een catalogus die via JavaScript wordt gerenderd, een artikel dat verstopt zit tussen navigatie- en footer-rommel, een bewust kapotte HTTP 500, een kleine crawl-grafiek met interne links, plus twee publieke oefensites. Zelfde basis, dezelfde metingen, bij elke run opnieuw. De scripts en ruwe output staan in één publieke benchmark-repo, zodat je alles zelf opnieuw kunt draaien. Wat daaruit kwam is niet die nette ranglijst die de roundups beloven — er is geen enkele winnaar. Er zijn drie verschillende soorten werk, en de negen tools vallen daar bijna vanzelf in uiteen.
Probeer Thunderbit voor webdata-extractie
Hoe de testbank werkte, en de ene beperking die ik hardop wil noemen
Elke tool kreeg dezelfde soorten fixtures: 12 statische producten verdeeld over twee pagina’s, 8 producten die na een vertraging via JavaScript worden toegevoegd, een artikel dat omringd is door standaard navigatie- en footertekst met drie echte alinea’s, een opzettelijke server-500, en een grafiek van interne links. Juist die opzet maakt de resultaten netjes naast elkaar vergelijkbaar — “8/8 dynamische producten” betekent exact hetzelfde, of Puppeteer dat nu opleverde of Crawlee.
Hier zit wel de grens die de meeste roundups overslaan. Elke toolset spiegelt zijn eigen kopie van die fixtures, dus absolute karaktertellingen kun je niet strak met elkaar vergelijken — lees die alleen als signalen binnen één tool, nooit als score tussen tools. De cijfers die wél vergelijkbaar zijn: recall (zie dat als een percentage), het al dan niet slagen van JavaScript, en structureel gedrag. Nog één scope-opmerking in dezelfde geest: Craw4AI’s run op de statische catalogus besloeg alleen pagina één, dus 6/6 betekent daar volledige recall op een smaller deel, terwijl de andere tools beide pagina’s doorliepen voor 12/12 — kleinere scope, geen gedeeltelijke miss. De volledige redenering, fixture voor fixture, staat in de methodologie-uitleg.
Nog één kanttekening vóór de cijfers. Elke toolset bevat ook een voorlopige onderzoeks-score, maar die druk ik bewust niet af als ranglijst. Het waren interne hulpmiddelen om elke tool te toetsen aan zijn eigen bewijsmateriaal, niet een competitieklassement — en die scores publiceren zou precies het probleem van schijnprecisie terugbrengen waar dit hele experiment juist tegen is bedoeld. Zie dit dus als een synthese van wat de testbank liet zien, niet als een scoreboard.
Het volledige veld, op één testbank
Lees in deze tabel vooral de kolommen “Renders JS?” en “Built-in crawl queue”; dan springen de drie soorten werk er bijna vanzelf uit.
| Tool | Taal | Renders JS? | Statische recall | Gestructureerde output | Ingebouwde crawl-queue | Installatiezwaarte | Licentie |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Ja (browser) | 6/6 (pagina 1) | CSS-schema | BFS/DFS ingebouwd | Zwaar (2 browser-stacks) | Apache-2.0 |
| Firecrawl | Zelf gehost | Ja (playwright-service) | Volledige Markdown | Ja | /v1/crawl | Zwaarst (6 containers) | AGPL-3.0 |
| trafilatura | Python | Nee | 3/3 artikel | Nee (alleen tekst) | Nee | Licht | Apache-2.0 |
| Crawlee | Node/TS | Optioneel per engine | 12/12 | Via extractie | Ja (RequestQueue) | Middelzwaar (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Ja | 12/12 | Handmatig | Nee (handgeschreven BFS) | Middelzwaar (browser) | Apache-2.0 |
| Puppeteer | Node | Ja (Chrome) | 12/12 | Handmatig | Nee (handgeschreven BFS) | Middelzwaar (Chrome) | Apache-2.0 |
| Scrapy | Python | Nee | 12/12 | Feed-export (JSON/CSV/XML) | Ja (ingebouwd) | Middelzwaar (Twisted-afhankelijkheden) | BSD-3 |
| Colly | Go | Nee | 12/12 | Via callbacks | Dieptecontrole | Licht (1 binary + Go) | Apache-2.0 |
| Scrapling | Python | Nee (HTTP-fetcher) | 12/12 | Ja | Nee | Middelzwaar ([fetchers]) | BSD-3 |
Een opmerking over de metadata in die tabel en alles hieronder: ster-aantallen en versienummers zijn vastgelegd begin juli 2026, en beide veranderen snel. Check altijd de GitHub- en packagepagina van elk project opnieuw voordat je ze als actueel beschouwt.
De review-index per tool
Van elk project in deze roundup is er ook een losse deep-dive review:
- Crawl4AI review
- Firecrawl review
- trafilatura review
- Playwright vs Puppeteer vergelijking
- Crawlee review
- Scrapy review
- Colly review
- Scrapling review
Hier zijn hun covers — plus twee echte screenshots uit de JavaScript-renderingtest, zodat de claim “8/8 dynamisch” niet alleen een getal op een pagina is.
Job één: zet een pagina om in LLM-klare tekst
Als je schone Markdown wilt voor een RAG-pipeline, strijden drie tools om die plek — en ze kunnen nauwelijks verder uit elkaar liggen.
Crawl4AI is, onder de marketinglaag, een browser-gedreven Markdown-generator. Het is de moeite waard om het verhaal over “adaptive intelligence self-learning selector” meteen te ontkrachten, want dat hoort hier niet thuis: zo’n functie heeft het niet — dat is het trucje van een andere library (daar komen we bij Scrapling op terug). Wat het werkelijk doet, doet het goed. Op de Books to Scrape-oefensite leverde het 13.476 tekens Markdown op, het ondersteunt CSS-schema-extractie voor gestructureerde pulls, en de ingebouwde BFS-deep crawl liep 5 pagina’s van de crawl-grafiek af terwijl ook een JavaScript-pagina werd gerenderd en een screenshot werd gemaakt. Twee echte minpunten echter. De ruwe Markdown bevat de boilerplate van de pagina, tenzij je een contentfilter inschakelt, en de opzettelijke 500 kwam terug als success=false — niet omdat Crawl4AI de HTTP-fout netjes afving, maar omdat de eigen contentheuristiek naar het kleine foutbericht keek en het als minimal_text ... blocked markeerde. En de setup zet twee browser-stacks op je schijf. Versie 0.9.0, Apache-2.0, begin juli ongeveer 71k sterren.
Firecrawl is de zwaargewicht, en self-hosting werkt hier echt — ik zeg bewust “echt”, omdat de stack met zes containers (api, playwright-service, redis, rabbitmq, nuq-postgres en foundationdb) daadwerkelijk opkwam en 9.222 tekens LLM-klare Markdown opleverde van dezelfde Books to Scrape-pagina. Het renderde een JavaScript-pagina via de meegeleverde playwright-service, en het Einstein-citaat dat na het script verschijnt, stond ook in de output; dat bewees dat de render echt was. Twee problemen die ik tegenkwam lagen niet aan Firecrawl maar aan de omgeving, en ik wil dat precies houden zodat niemand de verkeerde oplossing kopieert: een build uit broncode liep vast op een containerd-snapshotter-fluke onder colima (ik ben toen overgestapt op de vooraf gebouwde images), en colima’s 198.18.x.x-DNS-range activeerde Firecrawl’s SSRF-beveiliging, die ik heb opgelost met ALLOW_LOCAL_WEBHOOKS=true — een workaround voor lokale ontwikkeling, niet iets wat je in productie moet uitschakelen. De self-hosted core mist bovendien Fire-engine, de cloud anti-bloklaag, en ik heb de cloud-API niet getest. De grotere rode vlag is de licentie: Firecrawl’s self-hosted core is AGPL-3.0, en dat vraagt echt juridisch onderzoek vóór commercieel gebruik, niet een voetnoot. Rond 148k sterren begin juli.
trafilatura is de tegendraadse in deze groep, en precies de tool die AI-hype-lijstjes steeds vergeten. Geen browser. Geen gestructureerde rijen. Alleen snelle, schone artikeltekst in pure Python. Op de artikel-fixture pakte het de titel plus alle 3 van de 3 echte alinea’s, schrapte de boilerplate volledig — geen “Login”, “Subscribe” of “Copyright” lekte door — en haalde daarbovenop de auteur en datum op. Op een publieke productpagina leverde het 1.324 tekens schone tekst. De beperking is exact wat het ontwerp al doet vermoeden: zet je het op een catalogus, dan krijg je 12 productnamen als tekst maar 0 gestructureerde rijen — de tekst is er, de structuur niet, en JavaScript wordt niet gerenderd. Versie 2.1.0 (de huidige release), Apache-2.0, ongeveer 6,2k sterren. Voor pure article-extractie is dit de eerste tool waar ik naar zou grijpen.
Die twee Markdown-tekentellingen — 13.476 van Crawl4AI, 9.222 van Firecrawl — kwamen van dezelfde publieke pagina, maar lees ze niet als kwaliteitsverschil. Ze laten verschillende Markdown-strategieën zien (hoeveel paginachrome ze behouden), niet welk resultaat “beter” is. Dat is precies die binnen-tool-regel van eerder, hier zichtbaar in de praktijk.
Job twee: JavaScript betrouwbaar renderen
Sommige data staat simpelweg niet in de HTML totdat scripts draaien, en dan is een echte browser geen luxe meer maar noodzaak. Drie tools dekken dit werk af — en twee daarvan bleken bijna dezelfde tool te zijn.
Playwright en Puppeteer eindigden in al mijn tests gelijk. Beide renderden 8/8 dynamische producten op de lokale fixture en 10 op de publieke Quotes JS-site, beide haalden 12/12 statische recall, en beide verwerkten de 500 netjes (Puppeteer geeft een response-object terug in plaats van een fout te gooien). Geen van beide heeft een crawl-queue ingebouwd, dus voor de 12-pagina-linkgrafiek moest handmatig BFS-code worden geschreven. Het echte verschil zit in bereik: Playwright stuurt Chromium, Firefox en WebKit aan en spreekt Python en .NET, terwijl Puppeteer Chrome-first en alleen Node is. Twee disclaimers, want versies veranderen hier snel: ik testte Playwright 1.56.0 tegenover een huidige 1.61.1 en gebruikte alleen Chromium, en Puppeteer 24.16.0 tegenover een huidige 25.3.0 — dus opnieuw draaien of met die context lezen. Beide Apache-2.0; ongeveer 92k en 95k sterren respectievelijk.
Crawlee is degene die het queue-probleem oplost dat de andere twee openlaten. Het verpakt een Cheerio-(HTTP)-engine en een Playwright-(browser)-engine achter één API, en het contrast op één pagina is precies de pitch: de Cheerio-engine zag 0 JavaScript-ingespoten items, de Playwright-engine zag lokaal alles 8/8 (en 10 op de publieke site), en wisselen tussen beide is een wijziging van één regel. Daarnaast krijg je een echte RequestQueue, en daardoor hoort het hier thuis en niet bij job drie. De adder onder het gras die meestal niet in de headline staat: de browser-engine vereist een aparte npx playwright install, ongeveer 80 MiB die npm install crawlee niet voor je meeneemt. Versie 3.17.0, TypeScript, Apache-2.0, rond 24,6k sterren.
Job drie: snel crawlen zonder browser
Geen JavaScript op de pagina betekent dat een browser dure overkill is. Drie HTTP-first tools concurreren hier, elk vanuit een andere taalfilosofie, en ze verschillen op interessante punten.
Scrapy is de framework-oplossing van het stel — spiders, feed-exports naar JSON/CSV/XML, AutoThrottle, noem maar op. Het haalde 12/12 statische recall, trok het artikel op 3/3 alinea’s, liep 11 pagina’s af over diepte 0–2 in de crawl-grafiek, en ving de 500 op via handle_httpstatus_list. De echte les zit in de denkwijze: het rendert niet, het bootst de request na. Op de JavaScript-pagina kreeg het 0 nodes — en vervolgens gaf de JSON-API achter diezelfde pagina het 8/8. Dat is Scrapy in één datapunt: vind de request die de pagina zelf doet en speel die opnieuw af, in plaats van een browser te sturen. De prijs is een flinke afhankelijkhedenstapel (Twisted, lxml, parsel), en ik heb het alleen tegen kleine fixtures getest. Versie 2.17.0, BSD-3-Clause, rond 63k sterren.
Colly is het Go-antwoord, en het is verfrissend letterlijk over wat het is: één statische binary, callback-gedreven via OnHTML, OnResponse en OnError, met dieptecontrole. Het haalde 12/12 statische recall, trok 8/8 uit de JSON-API via OnResponse, ving de 500 via OnError, en kwam tot 17 pagina’s onder een depth-2 crawl — en ik formuleer dat bewust zo, want dat paginatal is de teller van de testopstelling zelf, geen volledigheidsbelofte van Colly. Wat het niet doet is JavaScript: de dynamische fixture en de Quotes JS-site kwamen allebei terug met 0, zoals bedoeld. Je hebt een Go-toolchain nodig om het te bouwen, en de moduleversie (v2.3.0) loopt momenteel voor op de getagde release (v2.2.0). Apache-2.0, ongeveer 25k sterren.
Scrapling is de specialist, en die titel verdient het ook. De adaptive selectors zijn gebouwd om een element opnieuw te vinden nadat de markup wijzigt — dus toen ik de HTML-class van een target veranderde van product-name naar product-title, leverde een gewone selector 0, maar de adaptive re-match vond het gevolgde element alsnog terug. Bij pure HTTP-extractie haalde het 12/12 statisch en 8/8 op de JSON-API. Het deel dat de eigen docs niet verzwijgen: in een synthetische test met meerdere elementen herstelde het 1 van de 3 — dit is robuuste elementtracking, geen totale hersteloplossing, dus overschat het niet. Voor pip install scrapling heb je bovendien de extra [fetchers] nodig om op gang te komen, en StealthyFetcher is een compliance-kanttekening, niet iets wat ik op een slide zou zetten. Versie 0.4.10 (de huidige release), BSD-3-Clause, rond 68,7k sterren.
Het patroon onder de drie soorten werk
Zet de negen tools naast elkaar en er komt een helder patroon naar voren. Volledige statische recall — een vlakke 12/12 — is voor elke HTTP-first tool standaard; niemand struikelde over het makkelijke geval, dus dat onderscheidt ze niet. De browser-tools rechtvaardigen hun extra gewicht alleen wanneer JavaScript echt in het spel is, en daarvoor betalen ze allemaal in setup: een browserstack, een extra installatie, of een hele container-vloot. En de kolom “built-in crawl queue” is eigenlijk de scheidslijn tussen een framework en een engine — Scrapy en Crawlee brengen orchestration mee, terwijl Playwright en Puppeteer je de BFS zelf laten schrijven. Dat is de vorm van het veld. Niemand wint overall, omdat niemand hetzelfde spel speelt.
Welke moet je dan echt kiezen
De testbank weigert een winnaar te kronen, omdat het juiste antwoord geen tool is maar een vraag: welk van de drie soorten werk doe je?
- LLM-klare Markdown nodig? Kies trafilatura als je vooral schone artikeltekst wilt, Crawl4AI als je ook CSS-extractie en JavaScript-rendering in één library wilt, en Firecrawl als je specifiek een self-hosted service zoekt en zowel de AGPL-3.0-licentie als het gewicht van zes containers kunt accepteren.
- JavaScript laten renderen? Neem Playwright of Puppeteer voor de ruwe rendering — kies op engine en taal, want verder is het gelijkspel — en Crawlee wanneer je ook de crawl-orchestratie kant-en-klaar wilt hebben in plaats van handmatig te bouwen.
- Statische pagina’s of reproduceerbare API’s op schaal crawlen? Scrapy voor een volwaardig Python-framework, Colly voor Go-snelheid in één binary, en Scrapling wanneer omgaan met verschuivende markup jouw specifieke, terugkerende pijn is.
Koppel de tool aan de taak en elk van deze keuzes is verdedigbaar. Pak je uit de verkeerde categorie — een browsertool voor statische pagina’s, of een HTTP-parser voor een JavaScript-app — dan laat zelfs de hoogst gewaardeerde library op internet je alsnog in de steek.
Waar een beheerde AI-API in plaats daarvan past
Elke tool hierboven is gratis, open-source en door jou zelf te draaien. Dat is ook de gedeelde afweging die de testbank steeds weer blootlegt: jij beheert de browseromgeving, de crawlcode, de anti-botwapenwedloop en alle onderhoud. Voor veel teams is juist die controle het punt, en het licentielandschap telt mee zodra je die verantwoordelijkheid neemt — het grootste deel van het veld is permissief (Apache-2.0 voor Crawl4AI, Crawlee, Playwright, Puppeteer en Colly; BSD-3 voor Scrapy en Scrapling), met Firecrawl’s AGPL-3.0 self-hosted core als de uitzondering die serieuze beoordeling vraagt vóór commercieel gebruik.
Maar let ook op wat de testbank óók in kaart brengt: wat deze tools níet doen. Renderen, crawlen, structureren en omgaan met blokkades — zelden allemaal tegelijk, en nooit zonder onderhoud van jouw kant. Een beheerde AI-scraping-API trekt die hele stapel samen tot één call. Onze eigen developer-omgeving bij Thunderbit is daar één optie voor, en voor een technisch publiek draait het om de API, de MCP-server en de CLI, niet om de browserextensie. POST /distill levert schone Markdown en POST /extract levert schema-gedefinieerde JSON, met JavaScript-rendering en anti-botafhandeling server-side in plaats van op je eigen machine. Er is een officiële MCP-server voor agents en coding assistants — thunderbit_suggest_fields is gratis om een extractie te plannen, daarna doen thunderbit_distill (1 credit) en thunderbit_extract (20 credits) het werk — en een CLI die je kunt binnenhalen met npx @thunderbit/thunderbit-cli voor terminal- en cronjobs. Voor niet-ontwikkelaars in je team is er ook een no-code Chrome-extensie, en de prijzen dekken beide kanten.
De afweging blijft dezelfde als waar deze hele testbank om draait: zelf tot negen libraries draaien en onderhouden tegen nul kosten per call, of de infrastructuur uit handen geven en per request betalen. Geen van beide keuzes is fout. Het hangt ervan af hoeveel van de stack je echt zelf wilt beheren. Als je liever wilt zien hoe die extractie er in de praktijk uitziet, laat het Thunderbit YouTube-kanaal het stap voor stap zien.
{{INTERNAL_BLOG_LINKS}}
Conclusie
Er bestaat niet zoiets als de ene beste open-source scraper, en elke lijst die je er zelfverzekerd één aanreikt, verbergt stilletjes de vraag die er echt toe doet: welk van de drie soorten werk doe je? Zet een pagina om in tekst, render JavaScript, of crawl snel zonder browser — het veld valt netjes uiteen in die vakken, en binnen elk vak draait de keuze vooral om taal en installatiezwaarte, niet om een universele kampioen.
Als je één gewoonte uit dit alles meeneemt, neem dan deze: test op je eigen pagina’s voordat je ergens definitief op inzet. Elk cijfer hier is reproduceerbaar in de benchmark-repo juist om die reden — omdat de tool die een generieke roundup aanvoert en de tool die jouw echte targets overleeft lang niet altijd dezelfde zijn.
Probeer Thunderbit voor webdata-extractie Get Started Free
FAQ
Wat is de beste open-source webscraper? Die bestaat niet als één enkel antwoord — het hangt af van de taak. Voor LLM-klare tekst: trafilatura of Crawl4AI; voor JavaScript-rendering: Playwright, Puppeteer of Crawlee; voor snelle HTTP-crawls: Scrapy of Colly. Op een gedeelde testbank bleek elke tool het sterkst binnen de eigen categorie en duidelijk zwakker erbuiten, en daarom misleiden one-size-fits-all-ranglijsten.
Welke open-source scrapers renderen JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer en Crawlee’s Playwright-engine renderen JavaScript. Scrapy, Colly, trafilatura en Scrapling’s standaard HTTP-fetcher doen dat niet — die hebben óf een reproduceerbare API achter de pagina nodig (Scrapy’s aanpak, die 8/8 uit het JSON-eindpunt haalde) óf een aparte browsermodus.
Heb ik een headless browser nodig om een site te scrapen? Alleen als de data pas verschijnt nadat JavaScript is uitgevoerd. Als een gewone HTTP-request plus een parser bij de inhoud kan komen, is een browser dure overkill — dan zijn Scrapy, Colly of Scrapling veel lichter en sneller.
Welke van deze heeft de vriendelijkste licentie voor commercieel gebruik? De meeste zijn permissief: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) of BSD-3-Clause (Scrapy, Scrapling). De uitzondering is Firecrawl’s self-hosted core, dat onder AGPL-3.0 valt en serieuze licentiebeoordeling verdient voordat je er een commercieel product op bouwt.
Zijn deze benchmarkcijfers reproduceerbaar? Ja. Elke runner, fixture en ruwe uitkomst staat in een publieke MIT-gelicentieerde repo. Eén kanttekening: recall- en structurele resultaten zijn tussen tools vergelijkbaar, maar absolute karaktertellingen alleen binnen één tool, omdat elke toolset de fixtures spiegelt in plaats van één canonieke kopie te delen — vergelijk dus percentages en pass/fail, niet de ruwe tekentotalen.
