Bijna elke round-up van de “beste open-source scraper” heeft één stille fout: niemand test de tools op dezelfde pagina’s. Scrapy wordt getest op een nieuwsartikel, Playwright op een e-commerce demo, Colly op wat de auteur toevallig nog had liggen — en daarna worden ze recht tegenover elkaar gezet, alsof die cijfers ooit precies hetzelfde konden betekenen. Zo’n ranglijst zegt vooral iets over de pagina’s, niet over de tools.
Dus heb ik het voor de hand liggende, saaie werk gedaan dat zulke lijsten overslaan. Ik bouwde één set fixtures en zette 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 expres kapotte HTTP 500, een kleine crawl-graph met interne links, plus twee openbare oefensites. Zelfde ground truth, zelfde metingen, elke run opnieuw. De scripts en ruwe output staan in één openbare benchmark-repo, zodat je alles zelf opnieuw kunt draaien. Wat daaruit kwam is niet de nette leaderboard die de round-ups beloven — er is geen enkele winnaar. Er zijn drie verschillende taken, en de negen tools verdelen zich daar bijna vanzelf over.
Probeer Thunderbit voor web data-extractie
Hoe de benchmark werkte, en één beperking die ik hardop wil benoemen
Elke tool kreeg precies dezelfde fixture-vormen: 12 statische producten verspreid over twee pagina’s, 8 producten die na een vertraging via JavaScript worden toegevoegd, een artikel met nav- en footer-boilerplate rond drie echte alinea’s, een opzettelijke server-500, en een grafiek van interne links. Díe opzet zorgt ervoor dat de resultaten vergelijkbaar zijn — “8/8 dynamische producten” betekent exact hetzelfde, of Puppeteer of Crawlee het nu produceerde.
Hier is de grens die de meeste round-ups overslaan. De dataset van elke tool weerspiegelt een eigen kopie van die fixtures, dus absolute tekenaantallen zijn niet strikt vergelijkbaar tussen tools — lees ze alleen als signaal binnen één tool, nooit als score tussen tools. De cijfers die wél vergelijkbaar zijn, zijn recall (zie het als een percentage), JavaScript slagen/mislukken, en structureel gedrag. Nog een afbakening in dezelfde geest: Crawl4AI’s statische catalogus-run behandelde alleen pagina één, dus die 6/6 is volledige recall op een smaller segment, terwijl de andere tools beide pagina’s crawlden 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 dataset bevat ook een voorlopige researchscore, maar ik druk die bewust niet af als ranglijst. Het waren interne hulpmiddelen om elke tool tegen zijn eigen bewijs te controleren, niet een competitie-overzicht — en ze publiceren als lijst zou precies het probleem van schijnprecisie opnieuw creëren dat dit hele onderzoek probeert te vermijden. Dit is een synthese van wat de benchmark liet zien, geen scoreboard.
Het hele veld, op één benchmark
Lees in deze tabel vooral twee kolommen: “Renders JS?” en “Built-in crawl queue” — dan springen de drie taken er bijna vanzelf uit.
| Tool | Taal | Renders JS? | Statische recall | Gestructureerde output | Ingebouwde crawl queue | Setup-gewicht | Licentie |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Ja (browser) | 6/6 (pagina 1) | CSS-schema | BFS/DFS ingebouwd | Zwaar (2 browserstacks) | 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 | Engine optioneel | 12/12 | Via extractie | Ja (RequestQueue) | Medium (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Ja | 12/12 | Handmatig | Nee (handgeschreven BFS) | Medium (browser) | Apache-2.0 |
| Puppeteer | Node | Ja (Chrome) | 12/12 | Handmatig | Nee (handgeschreven BFS) | Medium (Chrome) | Apache-2.0 |
| Scrapy | Python | Nee | 12/12 | Feed-export (JSON/CSV/XML) | Ja (ingebouwd) | Medium (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 | Medium ([fetchers]) | BSD-3 |
Nog even over de metadata in die tabel en verderop: steraantallen en versies zijn vastgelegd begin juli 2026, en die veranderen snel. Check ze opnieuw via de GitHub- en packagepagina’s van elk project voordat je ze als actueel beschouwt.
Index van de review per tool
Van elk project in deze round-up is er een losse diepgaande 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-render-test, zodat de claim “8/8 dynamisch” niet alleen een getal op een pagina is.
Taak één: een pagina omzetten naar LLM-klare tekst
Als je schone Markdown wilt voor een RAG-pipeline, concurreren drie tools — en ze verschillen fundamenteel van elkaar.
Crawl4AI is, ondanks de marketing, in de kern een browser-gestuurde Markdown-generator. Het loont om het verhaal over “adaptive intelligence self-learning selector” te ontkrachten dat overal opduikt in zoekresultaten: dat bestaat hier niet — dat is een truc van een andere library (daar kom ik op terug bij Scrapling). Wat het echt doet, doet het goed. Op de Books to Scrape-oefensite produceerde het 13.476 tekens aan Markdown, het ondersteunt CSS-schema-extractie voor gestructureerde pulls, en de ingebouwde BFS-deep crawl liep 5 pagina’s over de crawl-graph-fixture terwijl een JavaScript-pagina werd gerenderd en een screenshot werd gemaakt. Twee duidelijke minpunten: de ruwe Markdown bevat 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 afhandelde, maar omdat de eigen contentheuristiek naar de kleine error-body keek en die als minimal_text ... blocked markeerde. En de setup zet twee browserstacks op je schijf. Versie 0.9.0, Apache-2.0, ongeveer 71k sterren begin juli.
Firecrawl is de zwaargewicht, en self-hosten werkt echt — ik zeg “echt” omdat de stack met zes containers (api, playwright-service, redis, rabbitmq, nuq-postgres en foundationdb) daadwerkelijk opkwam en 9.222 tekens aan LLM-klare Markdown uit dezelfde Books to Scrape-pagina produceerde. Het rendeerde een JavaScript-pagina via de meegeleverde playwright-service, en het Einstein-citaat dat na het script verschijnt, stond ook daadwerkelijk in de output — bewijs dat de render echt was. Twee problemen kwamen door de omgeving en niet door Firecrawl, en ik wil dat precies zeggen zodat niemand de verkeerde oplossing kopieert: een build vanaf broncode liep vast op een containerd-snapshotter-flater onder colima (ik schakelde over op de vooraf gebouwde images), en colima’s 198.18.x.x-DNS-range activeerde Firecrawl’s SSRF-beveiliging, wat ik oploste met ALLOW_LOCAL_WEBHOOKS=true — een workaround voor lokale ontwikkeling, niet iets om uit te zetten in een echte productieomgeving. De self-hosted core mist ook Fire-engine, de cloud anti-block-laag, en ik heb de cloud-API niet getest. De grotere waarschuwing is de licentie: Firecrawl’s self-hosted core is AGPL-3.0, en dat is serieuze juridische huiswerkstof vóór elk commercieel gebruik, geen voetnoot. Rond 148k sterren begin juli.
trafilatura is de contrarian in deze groep, en precies degene die de AI-hype-lijsten steeds vergeten. Geen browser. Geen gestructureerde rijen. Gewoon snelle, schone artikeltekst in pure Python. Op de article-fixture haalde het de titel plus alle 3 van de 3 echte alinea’s binnen, haalde alle boilerplate volledig weg — geen “Login”, “Subscribe” of “Copyright” lekte door — en vond daarnaast auteur en datum terug. Op een publieke productpagina gaf het 1.324 tekens aan schone tekst terug. De beperking volgt precies uit het ontwerp: geef het een catalogus en je krijgt 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 artikel-extractie is dit het eerste waar ik naar zou grijpen.
Die twee Markdown-tekencijfers — 13.476 van Crawl4AI, 9.222 van Firecrawl — komen van dezelfde openbare pagina, maar lees ze niet als kwaliteitsverschil. Ze weerspiegelen verschillende Markdown-strategieën (hoeveel page chrome elk behoudt), niet welk resultaat “beter” is. Dat is die regel van de binnen-tool-signalen van eerder, hier volledig zichtbaar.
Taak twee: JavaScript betrouwbaar renderen
Sommige data staat simpelweg nog niet in de HTML voordat scripts draaien, en dan is een echte browser ineens geen luxe maar noodzaak. Drie tools dekken deze taak af — en twee daarvan bleken vrijwel dezelfde tool te zijn.
Playwright en Puppeteer eindigden gelijk op elk testonderdeel dat ik ze gaf. Beide renderden 8/8 dynamische producten op de lokale fixture en 10 op de openbare 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 exception te gooien). Geen van beide heeft een crawl queue, dus voor allebei was een handgeschreven BFS nodig, en die kwam uit op 12 pagina’s over diepte 0–2 op de crawl-graph. Het enige echte verschil is de reikwijdte: Playwright stuurt Chromium, Firefox en WebKit aan en spreekt Python en .NET, terwijl Puppeteer vooral op Chrome gericht is en alleen Node ondersteunt. Twee belangrijke aantekeningen, omdat versies hier snel bewegen: 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 — opnieuw draaien of met die context wegfilteren dus. Beide Apache-2.0; ongeveer 92k en 95k sterren respectievelijk.
Crawlee is degene die het queue-probleem oplost dat de andere twee laten liggen. Het verpakt een Cheerio-(HTTP)-engine en een Playwright-(browser)-engine achter één API, en het contrast op één pagina is meteen de hele propositie: de Cheerio-engine zag 0 via JavaScript toegevoegde items, de Playwright-engine zag lokaal alles 8/8 (en 10 op de publieke site), en wisselen tussen die twee is een wijziging van één regel. Je krijgt er ook een echte RequestQueue bij, en juist daarom hoort het in deze taak thuis en niet in taak drie. De adder onder het gras die niemand in de headline zet: de browser-engine heeft een aparte npx playwright install nodig, zo’n 80 MiB die npm install crawlee niet automatisch meeneemt. Versie 3.17.0, TypeScript, Apache-2.0, ongeveer 24,6k sterren.
Taak drie: snel crawlen zonder browser
Als er geen JavaScript op de pagina staat, is een browser dure overkill. Drie HTTP-first tools concurreren hier, elk vanuit hun eigen taalfilosofie, en ze verschillen op interessante manieren.
Scrapy is hier de framework-oplossing op engineering-niveau — spiders, feed-exports naar JSON/CSV/XML, AutoThrottle, alles erop en eraan. Het haalde 12/12 statische recall, trok de 3/3 alinea’s uit het artikel, doorliep 11 pagina’s over diepte 0–2 in de crawl-graph, en ving de 500 af via handle_httpstatus_list. Het interessante is zijn wereldbeeld: het rendert niet, het reproduceert de request. Zet je het op de JavaScript-pagina, dan kreeg het 0 nodes — waarna de JSON-API achter diezelfde pagina hem ineens 8/8 gaf. Dat is de Scrapy-filosofie in één datapunt: vind de request die de pagina doet en speel die na, in plaats van een browser aan te sturen. De prijs is een flinke afhankelijkheden-stack (Twisted, lxml, parsel), en ik testte het alleen op kleine fixtures. Versie 2.17.0, BSD-3-Clause, ongeveer 63k sterren.
Colly is het Go-antwoord, en het is heerlijk letterlijk over wat het is: één statische binary, callback-gedreven via OnHTML, OnResponse en OnError, met dieptecontrole. Het haalde 12/12 statische recall, trok via OnResponse 8/8 van de JSON-API, ving de 500 via OnError, en kwam uit op 17 pagina’s bij een crawl met diepte 2 — en ik formuleer het precies zo, omdat dat paginatotaal de teller van de testopzet zelf is, niet een volledigheidsbelofte van Colly. Wat het niet doet, is JavaScript: zowel de dynamische fixture als de Quotes JS-site kwamen terug als 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. Zijn adaptive selectors zijn gebouwd om een element opnieuw te vinden nadat de markup verschuift — dus toen ik de HTML-class van een target van product-name naar product-title hernoemde, vond een gewone selector 0, maar de adaptive rematch haalde het gevolgde element alsnog terug. Bij pure HTTP-extractie scoorde het 12/12 op statisch en 8/8 op de JSON-API. Het deel dat de documentatie zelf ook niet verbergt: in een synthetische multi-element-test herstelde het 1 van de 3 — dit is robuuste elementtracking, geen totaal herstel, dus overschat het niet. De basisinstallatie pip install scrapling heeft bovendien de extra [fetchers] nodig om te starten, en StealthyFetcher is eerder een compliance-waarschuwing dan een feature die ik op een slide zou zetten. Versie 0.4.10 (de huidige release), BSD-3-Clause, ongeveer 68,7k sterren.
Het patroon achter de drie taken
Zet de negen tools naast elkaar en er komt iets heel helders naar voren. Volledige statische recall — een vlakke 12/12 — is voor elke HTTP-first tool simpelweg de instapdrempel; niemand verprutste de makkelijke case, dus dat onderscheidt ze niet. De browser-tools rechtvaardigen hun extra gewicht alleen wanneer JavaScript echt in het spel is, en ze betalen daarvoor allemaal in setup: een browserstack, een extra installatie, of een hele container-vloot. En de kolom “built-in crawl queue” is eigenlijk de lijn tussen een framework en een engine — Scrapy en Crawlee brengen orkestratie mee, terwijl Playwright en Puppeteer je zelf de BFS laten schrijven. Dat is de vorm van het veld. Niemand wint totaal, omdat niemand hetzelfde spel speelt.
Welke moet je dan eigenlijk kiezen?
De benchmark weigert één winnaar aan te wijzen, omdat het juiste antwoord geen tool is maar een vraag: welke van de drie taken 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 accepteert.
- JavaScript renderen nodig? Pak Playwright of Puppeteer voor pure rendering — kies op engine en taal, want verder is het een gelijke strijd — en Crawlee als je daarnaast ook crawl-orkestratie wilt zonder die zelf te schrijven.
- Statische pagina’s of reproduceerbare API’s op schaal crawlen? Scrapy voor een volwaardig Python-framework, Colly voor pure Go-snelheid in één binary, en Scrapling wanneer bestand zijn tegen markup-drift jouw specifieke, terugkerende pijn is.
Stem de tool af op de taak en elk van deze opties is verdedigbaar. Pak je een tool uit de verkeerde categorie — een browsertool voor statische pagina’s, of een HTTP-parser voor een JavaScript-app — dan faalt zelfs de best beoordeelde library op internet nog steeds voor jouw use case.
Waar een beheerde AI-API dan wél past
Elke tool hierboven is gratis, open-source en door jou zelf te draaien. Dat is ook de gedeelde trade-off die de benchmark steeds weer blootlegt: jij beheert de browseromgeving, de crawlcode, de anti-bot-wapenwedloop en alles wat onderhoud vraagt. Voor veel teams is die controle precies de reden om hiervoor te kiezen, en de licentiemix doet ertoe wanneer je die stap zet — het grootste deel van het veld is permissief (Apache-2.0 bij Crawl4AI, Crawlee, Playwright, Puppeteer en Colly; BSD-3 bij Scrapy en Scrapling), met Firecrawl’s AGPL-3.0 self-hosted core als enige die serieuze beoordeling vraagt vóór commercieel gebruik.
Maar let ook op wat de benchmark óók in kaart bracht: wat deze tools níet doen. Renderen, crawlen, structureren en rond blokkades heen bewegen — zelden allemaal tegelijk, en nooit zonder dat jij het onderhoud draagt. Een beheerde AI-scraping-API haalt die hele stapel weg in één call. Ons eigen developer-surface 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 geeft schone Markdown terug en POST /extract levert schema-gedefinieerde JSON, met JavaScript-rendering en anti-bot afhandeling server-side in plaats van op jouw machine. Er is een officiële MCP-server voor agents en coding assistants — thunderbit_suggest_fields is gratis om een extractie voor te bereiden, 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-developers in je team is er ook een no-code Chrome-extensie, en de pricing dekt beide kanten.
De afweging is dezelfde waar deze hele benchmark omheen draait: draai en onderhoud zelf tot negen libraries met nul kosten per call, of besteed de plumbing uit en betaal per request. Geen van beide keuzes is fout. Het gaat erom hoeveel van de stack je echt zelf wilt bezitten. Als je liever ziet hoe de extractie er in de praktijk uitziet, laat het Thunderbit YouTube-kanaal het stap voor stap zien.
Oordeel
Er is geen enkele beste open-source scraper, en elke lijst die je er zelfverzekerd één geeft, verbergt stilletjes de vraag die er echt toe doet: welke van de drie taken voer je uit? Een pagina naar tekst omzetten, JavaScript renderen, of snel crawlen zonder browser — het veld valt netjes uiteen in die categorieën, en binnen elk daarvan draait de keuze om taal en setup-gewicht, niet om één universele kampioen.
Neem je één gewoonte uit dit alles mee, laat het dan deze zijn: test op je eigen pagina’s vóór je ergens op vastlegt. Elk cijfer hier is reproduceerbaar in de benchmark-repo, precies om die reden — omdat de tool die bovenaan een generieke round-up eindigt en de tool die jouw echte targets overleeft niet altijd dezelfde is.
Probeer Thunderbit voor web data-extractie Get Started Free
Veelgestelde vragen
Wat is de beste open-source webscraper? Die ene bestaat niet — 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 testbench was elke tool het sterkst binnen zijn eigen categorie en duidelijk zwakker daarbuiten, en juist daarom zijn one-size-fits-all ranglijsten misleidend.
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 (de Scrapy-aanpak, die via het JSON-eindpunt 8/8 haalde) óf een aparte browsermodus.
Heb ik een headless browser nodig om een site te scrapen? Alleen als de data pas verschijnt nadat JavaScript draait. Als een gewone HTTP-request plus parser genoeg is om bij de content te komen, dan is een browser dure overkill — Scrapy, Colly of Scrapling zijn in dat geval 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 AGPL-3.0 is en een echte licentiecheck verdient vóór je er een commercieel product op bouwt.
Zijn deze benchmarkcijfers reproduceerbaar? Ja. Elke runner, fixture en ruwe uitkomst staat in een openbare repo met MIT-licentie. Eén nuance om in gedachten te houden: recall- en structurele resultaten zijn tussen tools vergelijkbaar, maar absolute tekentaantallen zijn alleen binnen dezelfde tool zinvol, omdat elke dataset de fixtures spiegelt in plaats van één canonieke kopie te delen — vergelijk dus percentages en slaag/faal, niet de ruwe tekenaantallen.
