Nästan varje sammanställning av “bästa open source-scraper” har samma tysta svaghet: ingen kör verktygen på exakt samma sidor. Scrapy testas på en nyhetsartikel, Playwright på någon e-handelsdemo, Colly på det författaren råkade ha till hands — och sedan ställs de mot varandra som om siffrorna faktiskt betydde samma sak. Den sortens ranking säger mer om sidorna än om verktygen.
Så jag gjorde det tråkiga, självklara som listorna ofta hoppar över. Jag byggde ett gemensamt testupplägg och körde alla nio verktyg mot det: en statisk produktkatalog, en JavaScript-renderad katalog, en artikel gömd bakom navigering och footer-brus, ett medvetet trasigt HTTP 500-svar, en liten crawl-graf med interna länkar, plus två publika övningssajter. Samma facit, samma mätning, varje gång. Skripten och råresultaten ligger i ett offentligt benchmark-repo så att du kan köra om allt själv. Det som kom tillbaka är inte den prydliga topplista som sammanställningarna lovar — det finns ingen ensam vinnare. Det finns tre olika jobb, och de nio verktygen sorterar nästan av sig själva in i dem.
Testa Thunderbit för webbdatautvinning
Hur testbänken fungerade, och den ena begränsningen jag säger högt
Varje verktyg kördes mot samma fixture-typer: 12 statiska produkter fördelade på två sidor, 8 produkter som lades in av JavaScript efter en fördröjning, en artikel inramad av nav/footer-boilerplate runt tre riktiga stycken, ett avsiktligt serverfel 500, och en graf av interna länkar. Det upplägget är det som gör att resultaten går att jämföra — “8/8 dynamiska produkter” betyder exakt samma sak oavsett om det var Puppeteer eller Crawlee som tog fram dem.
Här är gränsen som många sammanställningar hoppar över. Varje tools paket speglar dess egen kopia av dessa fixtures, så absoluta teckenmängder är inte strikt jämförbara mellan verktyg — läs dem som signaler inom samma verktyg, aldrig som ett korsjämförande betyg. De siffror som är jämförbara är recall (se det som en träffprocent), godkänd/underkänd JavaScript-körning och strukturellt beteende. En liknande notering: Crawl4AI:s körning på den statiska katalogen omfattade bara sida ett, så dess 6/6 är full recall på ett smalare urval, medan de andra verktygen crawlande båda sidor för 12/12 — ett mindre scope, inte en halvträff. Den fulla motiveringen, fixture för fixture, finns i metodbeskrivningen.
En sak till innan siffrorna. Varje paket innehåller också ett preliminärt forskningsbetyg, men jag visar dem medvetet inte som en rankad tabell. De var interna hjälpmedel för att kontrollera varje verktyg mot dess egen evidens, inte en liga-tabell — och att publicera dem som en sådan skulle återskapa exakt den falska precision som hela övningen försöker undvika. Det här är en sammanvägning av vad testbänken visade, inte en poängtabell.
Hela fältet på en och samma testbänk
Läs nedför de två kolumnerna i tabellen — “Renderar JS?” och “Inbyggd crawlkö” — så blir de tre jobben i princip självklara.
| Verktyg | Språk | Renderar JS? | Statisk recall | Strukturerad output | Inbyggd crawlkö | Installationsvikt | Licens |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Ja (webbläsare) | 6/6 (sida 1) | CSS-schema | BFS/DFS inbyggt | Tung (2 webbläsarstackar) | Apache-2.0 |
| Firecrawl | Självhostad | Ja (playwright-service) | Full Markdown | Ja | /v1/crawl | Tyngst (6 containrar) | AGPL-3.0 |
| trafilatura | Python | Nej | 3/3 artikel | Nej (endast text) | Nej | Lätt | Apache-2.0 |
| Crawlee | Node/TS | Motor valfri | 12/12 | Via extrahering | Ja (RequestQueue) | Medel (+~80 MiB) | Apache-2.0 |
| Playwright | Node/multi | Ja | 12/12 | Manuellt | Nej (egen BFS) | Medel (webbläsare) | Apache-2.0 |
| Puppeteer | Node | Ja (Chrome) | 12/12 | Manuellt | Nej (egen BFS) | Medel (Chrome) | Apache-2.0 |
| Scrapy | Python | Nej | 12/12 | Feed-export (JSON/CSV/XML) | Ja (inbyggd) | Medel (Twisted-beroenden) | BSD-3 |
| Colly | Go | Nej | 12/12 | Via callbacks | Djupkontroll | Lätt (1 binär + Go) | Apache-2.0 |
| Scrapling | Python | Nej (HTTP-hämtare) | 12/12 | Ja | Nej | Medel ([fetchers]) | BSD-3 |
En notis om metadata i tabellen och överallt nedan: stjärnantal och versionsnummer togs i början av juli 2026, och båda ändras snabbt. Kolla om dem mot varje projekts GitHub-sida och paketsida innan du behandlar dem som aktuella.
Index över enskilda genomgångar
Varje projekt i den här sammanställningen har en egen fördjupad recension:
- Crawl4AI-recension
- Firecrawl-recension
- trafilatura-recension
- Jämförelse mellan Playwright och Puppeteer
- Crawlee-recension
- Scrapy-recension
- Colly-recension
- Scrapling-recension
Här är deras omslag — plus två riktiga skärmdumpar från testet för JavaScript-rendering, så att påståendet om “8/8 dynamiska” inte bara är en siffra på sidan.
Jobb ett: gör en sida till LLM-redo text
Om du vill ha ren Markdown för en RAG-pipeline är det tre verktyg som slåss — och de kunde inte vara mer olika.
Crawl4AI är, bakom marknadsföringen, en browser-baserad Markdown-generator. Det är värt att slå hål på historien om “adaptiv intelligens med självlärande selector” som följer med i sökresultaten: något sådant finns inte — det är en annan libraries grej (mer om det när vi kommer till Scrapling). Det den faktiskt gör, gör den bra. På övningssajten Books to Scrape gav den ut 13 476 tecken Markdown, den hanterar CSS-schemaextrahering för strukturerade uttag, och dess inbyggda BFS-djupcrawl gick igenom 5 sidor i crawl-graf-fixturen medan den renderade en JavaScript-sida och tog en skärmdump. Två tydliga nackdelar ändå. Den råa Markdownen innehåller sidans boilerplate om du inte slår på ett content filter, och det avsiktliga 500-svaret kom tillbaka som success=false — inte för att Crawl4AI snyggt fångade HTTP-felet, utan för att dess egen innehållsheuristik tittade på den lilla felkroppen och markerade den som minimal_text ... blocked. Och installationen lägger två webbläsarstackar på disken. Version 0.9.0, Apache-2.0, ungefär 71k stjärnor i början av juli.
Firecrawl är tungviktaren, och självhosting fungerar faktiskt — jag säger “faktiskt” eftersom sex-container-stacken (api, playwright-service, redis, rabbitmq, nuq-postgres och foundationdb) verkligen kom upp och producerade 9 222 tecken LLM-redo Markdown från samma Books to Scrape-sida. Den renderade en JavaScript-sida via sin inbyggda playwright-service, och Einstein-citatet som lades in efter scriptet dök upp i outputen, vilket bevisade att renderingen var verklig. Två problem jag stötte på berodde på miljön, inte på Firecrawl, och jag vill vara noggrann så att ingen kopierar fel lösning: en build från källkod fastnade i ett containerd snapshotter-hak under colima (jag bytte till de förbyggda bilderna), och colimas 198.18.x.x-DNS-intervall triggar Firecrawls SSRF-skydd, vilket jag löste med ALLOW_LOCAL_WEBHOOKS=true — en lokal utvecklingslösning, inte något man ska stänga av i en riktig driftsättning. Den självhostade kärnan saknar också Fire-engine, molnlagret mot blockering, och jag testade inte moln-API:t. Den större varningsflaggan är licensen: Firecrawls självhostade kärna är AGPL-3.0, vilket kräver seriös juridisk genomgång innan kommersiell användning, inte bara en fotnot. Runt 148k stjärnor i början av juli.
trafilatura är gruppens motröst, och den som AI-hype-listorna ständigt glömmer. Ingen webbläsare. Inga strukturerade rader. Bara snabb, ren artikeltext i ren Python. På artikel-fixturen hämtade den titeln plus alla 3 av de 3 riktiga styckena, tog bort boilerplate helt — inget “Login”, “Subscribe” eller “Copyright” läckte igenom — och fångade dessutom författare och datum. På en offentlig produktsida gav den tillbaka 1 324 tecken ren text. Dess begränsning är precis det designen antyder: peka den mot en katalog så lämnar den tillbaka 12 produktnamn som text men 0 strukturerade rader — texten finns där, strukturen gör det inte, och den renderar ingen JavaScript. Version 2.1.0 (nuvarande release), Apache-2.0, ungefär 6,2k stjärnor. För ren artikelutvinning är det första jag skulle välja.
De två Markdown-siffrorna — 13 476 från Crawl4AI och 9 222 från Firecrawl — kom från samma offentliga sida, men läs dem inte som ett kvalitetsgap. De speglar olika Markdown-strategier (hur mycket sidans krom som behålls), inte ett omdöme om vilken output som är bäst. Det är regeln om signaler inom samma verktyg, i full skala.
Jobb två: rendera JavaScript pålitligt
Vissa data finns helt enkelt inte i HTML innan skripten körs, och då är en riktig webbläsare inte längre valfri. Tre verktyg täcker det här jobbet — och två av dem visade sig nästan vara samma verktyg.
Playwright och Puppeteer blev lika på varje test jag kastade mot dem. Båda renderade 8/8 dynamiska produkter i den lokala fixturen och 10 på den publika Quotes JS-sajten, båda nådde 12/12 statisk recall, och båda hanterade 500-svaret snyggt (Puppeteer returnerar ett response-objekt i stället för att kasta). Ingen av dem levereras med crawlkö, så båda behövde en egen BFS för att gå igenom länkgrafen med 12 sidor. Den enda verkliga skillnaden är räckvidd: Playwright styr Chromium, Firefox och WebKit och talar Python och .NET, medan Puppeteer är Chrome-först och bara Node. Två upplysningar, eftersom versionerna rör sig snabbt: jag testade Playwright 1.56.0 mot en aktuell 1.61.1 och använde bara Chromium, och Puppeteer 24.16.0 mot en aktuell 25.3.0 — kör om eller vikta ner siffrorna därefter. Båda Apache-2.0; ungefär 92k respektive 95k stjärnor.
Crawlee är det verktyg som löser kö-problemet som de två andra lämnar öppet. Det paketerar en Cheerio-motor (HTTP) och en Playwright-motor (webbläsare) bakom ett gemensamt API, och kontrasten på en och samma sida är hela poängen: Cheerio-motorn såg 0 JavaScript-injicerade objekt, Playwright-motorn såg alla 8/8 lokalt (och 10 på den publika sajten), och det räcker att byta motor med en enda rad kod. Det ger dig också en riktig RequestQueue, vilket gör att det hör hemma i det här jobbet snarare än i jobb tre. Nackdelen som aldrig hamnar i rubriken: browser-motorn kräver ett separat npx playwright install, ungefär 80 MiB som npm install crawlee inte hämtar åt dig. Version 3.17.0, TypeScript, Apache-2.0, runt 24,6k stjärnor.
Jobb tre: crawla snabbt utan webbläsare
Ingen JavaScript på sidan betyder att en webbläsare är dyr överkurs. Tre HTTP-först-verktyg tävlar här, ett per språkfilosofi, och de skiljer sig åt på intressanta sätt.
Scrapy är den mest ingenjörsmässiga ramen i gänget — spiders, feed-export till JSON/CSV/XML, AutoThrottle, alltihop. Den träffade 12/12 statisk recall, hämtade artikelns 3/3 stycken, gick igenom 11 sidor över djup 0–2 i crawl-grafen och fångade 500-felet via handle_httpstatus_list. Dess synsätt är det intressanta: den renderar inte, den återskapar förfrågan. När den kastades mot JavaScript-sidan fick den 0 noder — och sedan gav JSON-API:t bakom samma sida den 8/8. Det är Scrapy-filosofin i en enda datapunkt: hitta anropet sidan gör och spela upp det igen, inte kör en webbläsare. Kostnaden är en ganska tung beroendestapel (Twisted, lxml, parsel), och jag testade den bara mot små fixtures. Version 2.17.0, BSD-3-Clause, ungefär 63k stjärnor.
Colly är Go-svaret, och den är uppfriskande bokstavlig om vad den är: en enda statisk binär, callback-styrd via OnHTML, OnResponse och OnError, med djupkontroll. Den klarade 12/12 statisk recall, hämtade 8/8 från JSON-API:t via OnResponse, fångade 500 via OnError, och nådde 17 sidor under en crawl med djup 2 — och jag uttrycker det exakt så, eftersom sidantalet är harnessens egen räknare, inte någon fullständighetsgaranti som Colly själv lovar. Det den inte gör är JavaScript: den dynamiska fixturen och Quotes JS-sajten kom båda tillbaka som 0, enligt design. Du behöver en Go-toolchain för att bygga den, och modulversionen (v2.3.0) ligger för närvarande före den taggade releasen (v2.2.0). Apache-2.0, runt 25k stjärnor.
Scrapling är specialisten, och den förtjänar den etiketten. Dess adaptiva selectors är byggda för att hitta ett element igen efter att markupen ändras — så när jag bytte en målsidas HTML-klass från product-name till product-title, träffade en vanlig selector 0, och den adaptiva omlokaliseringen hittade ändå det spårade elementet. Vid vanlig HTTP-extraktion träffade den 12/12 statiskt och 8/8 på JSON-API:t. Det som den egna dokumentationen inte döljer: i ett syntetiskt test med flera element återfann den 1 av 3 — det här är robust elementspårning, inte total återställning, så översälj den inte i huvudet. Grundinstallationen pip install scrapling behöver också tillägget [fetchers] för att komma igång, och dess StealthyFetcher är en compliance-varningsflagga, inte en funktion jag skulle sätta på en slide. Version 0.4.10 (nuvarande release), BSD-3-Clause, runt 68,7k stjärnor.
Mönstret bakom de tre jobben
Ställer man upp alla nio bredvid varandra framträder något tydligt. Full statisk recall — platt 12/12 — är minimikrav för alla HTTP-först-verktyg; ingen missade den lätta uppgiften, så det är ingen särskiljare. Browser-verktygen motiverar bara sin extra tyngd när JavaScript faktiskt är med i bilden, och då betalar de alla med installation: en webbläsarstack, en extra installation eller en hel containerflotta. Och kolumnen “inbyggd crawlkö” är egentligen gränsen mellan ett ramverk och en motor — Scrapy och Crawlee ger dig orkestrering, medan Playwright och Puppeteer får dig att skriva BFS själv. Det är så fältet ser ut. Ingen vinner totalt eftersom ingen spelar samma spel.
Så vilken ska du faktiskt välja
Testbänken vägrar utse en vinnare eftersom rätt svar inte är ett verktyg utan en fråga — vilket av de tre jobben gör du?
- Behöver du LLM-redo Markdown? Välj trafilatura när du vill ha ren artikeltext, Crawl4AI när du också vill ha CSS-extrahering och JavaScript-rendering i samma bibliotek, och Firecrawl när du specifikt vill ha en självhostad tjänst och kan acceptera både AGPL-3.0-licensen och vikten av sex containrar.
- Behöver du JavaScript-rendering? Välj Playwright eller Puppeteer för själva renderingen — välj utifrån motor och språk, eftersom de i övrigt är oavgjorda — och Crawlee när du dessutom vill få crawl-orkestrering levererad i stället för att skriva den själv.
- Crawlar du statiska sidor eller reproducerbara API:er i stor skala? Scrapy för ett komplett Python-ramverk, Colly för rå Go-hastighet i en enda binär, och Scrapling när just markup-drift är ditt återkommande problem.
Matcha verktyget med uppgiften så är vart och ett av dem ett rimligt val. Ta från fel kategori — ett browser-verktyg för statiska sidor eller en HTTP-parser för en JavaScript-app — och det högst rankade biblioteket på internet kommer ändå att falla på mållinjen.
Var en hanterad AI-API passar i stället
Alla verktyg ovan är gratis, open source och dina att köra. Det är också den gemensamma avvägningen som testbänken gång på gång visar: du äger webbläsarmiljön, crawl-koden, anti-bot-racet och allt underhåll. För många team är just den kontrollen poängen, och licenskartan spelar roll när du tar på dig den — större delen av fältet är permissiv (Apache-2.0 för Crawl4AI, Crawlee, Playwright, Puppeteer och Colly; BSD-3 för Scrapy och Scrapling), med Firecrawls självhostade kärna på AGPL-3.0 som den enda som verkligen behöver granskas innan kommersiell användning.
Men se också vad testbänken visade att de här verktygen inte gör. Renderar, crawlar, strukturerar och hanterar blockeringar — sällan allt samtidigt, och aldrig utan ditt underhåll. En hanterad AI-scraping-API klumpar ihop hela den stacken till ett anrop. Vår egen utvecklarvy på Thunderbit är ett alternativ där, och för en teknisk målgrupp är det API:t, MCP-servern och CLI:t som spelar roll, inte webbläsartillägget. POST /distill returnerar ren Markdown och POST /extract returnerar schema-definierad JSON, med JavaScript-rendering och anti-bot hanterat server-side i stället för på din maskin. Det finns en officiell MCP-server för agenter och kodassistenter — thunderbit_suggest_fields körs gratis för att planera en extrahering, sedan gör thunderbit_distill (1 kredit) och thunderbit_extract (20 krediter) jobbet — och ett CLI som du kan hämta med npx @thunderbit/thunderbit-cli för terminal- och cron-jobb. För icke-utvecklarna i teamet finns också ett no-code-Chrome-tillägg, och prissättningen täcker båda dimensionerna.
Avvägningen är densamma som hela den här testbänken kretsar kring: kör och underhåll upp till nio bibliotek själv utan kostnad per anrop, eller lämna över infrastrukturen och betala per förfrågan. Inget av valen är fel. Det handlar om hur mycket av stacken du faktiskt vill äga. Om du hellre vill se hur extraheringen ser ut i praktiken går Thunderbit YouTube-kanal igenom det.
{{INTERNAL_BLOG_LINKS}}
Slutsats
Det finns ingen enskilt bästa open source-scraper, och varje lista som självsäkert ger dig en döljer tyst den fråga som faktiskt avgör saken: vilket av de tre jobben gör du? Gör om en sida till text, rendera JavaScript eller crawla snabbt utan webbläsare — fältet delas tydligt in i de lådorna, och inom var och en handlar valet om språk och installationsvikt, inte om någon universell mästare.
Om du tar med dig en vana från allt detta, så ta den här: testa på dina egna sidor innan du bestämmer dig. Varje siffra här går att återskapa i benchmark-repot just av den anledningen — för verktyget som toppar en generell sammanställning och verktyget som överlever dina riktiga mål är inte alltid samma sak.
Testa Thunderbit för webbdatautvinning Get Started Free
Vanliga frågor
Vilken är den bästa open source-webbscrapern? Det finns ingen enda — det beror på jobbet. För LLM-redo text: trafilatura eller Crawl4AI; för JavaScript-rendering: Playwright, Puppeteer eller Crawlee; för snabb HTTP-crawling: Scrapy eller Colly. I en gemensam testbänk var varje verktyg starkast inom sin egen kategori och märkbart svagare utanför den, vilket är varför generella topplistor lätt vilseleder.
Vilka open source-scrapers renderar JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer och Crawlees Playwright-motor renderar JavaScript. Scrapy, Colly, trafilatura och Scraplings standard-HTTP-hämtare gör det inte — de behöver antingen ett reproducerbart API bakom sidan (Scrapys angreppssätt, som nådde 8/8 via JSON-endpointen) eller ett separat browser-läge.
Behöver jag en headless browser för att scrapa en sajt? Bara om datan dyker upp efter att JavaScript körts. Om en vanlig HTTP-förfrågan plus en parser når innehållet är en webbläsare dyr överkurs — då är Scrapy, Colly eller Scrapling betydligt lättare och snabbare.
Vilken av dessa har den mest företagsvänliga licensen? De flesta är permissiva: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) eller BSD-3-Clause (Scrapy, Scrapling). Undantaget är Firecrawls självhostade kärna, som är AGPL-3.0 och bör granskas ordentligt innan du bygger en kommersiell produkt på den.
Går de här benchmark-siffrorna att återskapa? Ja. Varje runner, fixture och råresultat finns i ett offentligt MIT-licensierat repo. En viktig sak att ha i åtanke: recall och strukturella resultat går att jämföra mellan verktyg, men absoluta teckenmängder är bara signaler inom respektive verktyg, eftersom varje paket speglar fixtures i stället för att dela en enda kanonisk kopia — så jämför procentsatser och pass/fail, inte råa teckenmängder.
