मैंने 9 ओपन-सोर्स स्क्रेपर्स को एक ही टेस्ट बेंच पर परखा, और सही विकल्प आखिरकार सवाल पर निर्भर निकला

लगभग हर "सर्वश्रेष्ठ ओपन-सोर्स स्क्रेपर" वाली लिस्ट में एक छोटी-सी लेकिन बहुत अहम कमी होती है: किसी भी टूल को एक ही तरह के पेजों पर नहीं आज़माया जाता। Scrapy को किसी न्यूज़ आर्टिकल पर टेस्ट कर दिया जाता है, Playwright को किसी ई-कॉमर्स डेमो पर, Colly को लेखक के पास जो भी पड़ा हो उस पर — और फिर इन्हें आपस में रैंक कर दिया जाता है, जैसे उन नंबरों का हमेशा एक ही मतलब हो। ऐसी रैंकिंग आपको टूल नहीं, पेजों के बारे में बताती है।

इसलिए मैंने वह सीधा काम किया जिसे बाकी लिस्टें छोड़ देती हैं। मैंने एक ही सेट के टेस्ट केस बनाए और नौों टूल्स को उन्हीं पर चलाया: एक स्टैटिक कैटलॉग, JavaScript से रेंडर हुआ कैटलॉग, नेविगेशन और फुटर के शोर में छिपा आर्टिकल, जानबूझकर दिया गया HTTP 500, एक छोटा internal-link क्रॉल ग्राफ, और दो पब्लिक प्रैक्टिस साइट्स। हर रन में ग्राउंड ट्रुथ, मेट्रिक्स और हालात एक जैसे थे। स्क्रिप्ट्स और रॉ आउटपुट एक पब्लिक benchmark repo में उपलब्ध हैं, ताकि आप चाहें तो खुद दोबारा चला सकें। नतीजा वह चमकदार लीडरबोर्ड नहीं था जैसा ये roundups वादा करते हैं — यहाँ कोई एक विजेता नहीं है। यहाँ तीन अलग-अलग काम हैं, और नौ टूल लगभग अपने-आप उनमें बँट जाते हैं।

वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ

टेस्ट बेंच कैसे बनाई गई, और एक सीमा जो मैं साफ़-साफ़ बताना चाहता हूँ

हर टूल को एक ही तरह के टेस्ट केस दिए गए: 12 स्टैटिक प्रोडक्ट्स जो दो पेजों पर फैले थे, 8 प्रोडक्ट्स जो देरी के बाद JavaScript से जोड़े गए, एक आर्टिकल जिसके चारों ओर nav/footer का extra HTML था लेकिन अंदर तीन असली पैराग्राफ थे, एक जानबूझकर दिया गया server 500, और internal links का एक ग्राफ। यही डिज़ाइन नतीजों को तुलना योग्य बनाता है — "8/8 dynamic products" का मतलब चाहे Puppeteer ने बनाया हो या Crawlee ने, एक ही है।

लेकिन यहाँ वह सीमा है जिसे ज़्यादातर roundups छोड़ देते हैं। हर टूल के पैक में उन्हीं fixtures की अपनी कॉपी है, इसलिए absolute character counts को टूल-टू-टूल सीधे तुलना योग्य नहीं मानना चाहिए — उन्हें सिर्फ़ उसी टूल के अंदर संकेत की तरह पढ़ें, cross-tool score की तरह नहीं। जो आँकड़े सच में तुलना योग्य हैं वे हैं recall (इसे एक rate की तरह देखें), JavaScript pass/fail, और structural behavior। इसी भावना के साथ एक और scope note: Crawl4AI के static-catalog run में सिर्फ़ page one शामिल था, इसलिए उसका 6/6 सीमित दायरे में पूरा recall है, जबकि बाकी टूल्स ने दोनों पेज crawl करके 12/12 हासिल किया — यानी scope छोटा था, partial miss नहीं। हर fixture के हिसाब से पूरी reasoning methodology write-up में है।

नंबर्स पर जाने से पहले एक और बात। हर pack में एक provisional research score भी है, लेकिन मैंने जानबूझकर उसे ranked table की तरह नहीं छापा। वे सिर्फ़ internal checks थे, ताकि हर टूल को उसकी अपनी evidence chain से मिलाया जा सके — न कि कोई league table बनाने के लिए। उन्हें एक साथ publish करना वही false precision वापस ला देता, जिससे यह पूरा exercise बचना चाहता था। यह बेंच ने क्या दिखाया, उसका synthesis है — scoreboard नहीं।

पूरा मैदान, एक ही बेंच पर

इस table की दो columns — "Renders JS?" और "Built-in crawl queue" — पढ़िए, और तीनों काम अपने-आप साफ़ दिखने लगते हैं।

Tool	Language	Renders JS?	Static recall	Structured output	Built-in crawl queue	Setup weight	License
Crawl4AI	Python	Yes (browser)	6/6 (page 1)	CSS schema	BFS/DFS built-in	Heavy (2 browser stacks)	Apache-2.0
Firecrawl	Self-hosted	Yes (playwright-service)	Full Markdown	Yes	/v1/crawl	Heaviest (6 containers)	AGPL-3.0
trafilatura	Python	No	3/3 article	No (text only)	No	Light	Apache-2.0
Crawlee	Node/TS	Engine-optional	12/12	Via extraction	Yes (RequestQueue)	Medium (+~80 MiB)	Apache-2.0
Playwright	Node/multi	Yes	12/12	Manual	No (hand-written BFS)	Medium (browser)	Apache-2.0
Puppeteer	Node	Yes (Chrome)	12/12	Manual	No (hand-written BFS)	Medium (Chrome)	Apache-2.0
Scrapy	Python	No	12/12	Feed export (JSON/CSV/XML)	Yes (built-in)	Medium (Twisted deps)	BSD-3
Colly	Go	No	12/12	Via callbacks	Depth control	Light (1 binary + Go)	Apache-2.0
Scrapling	Python	No (HTTP fetcher)	12/12	Yes	No	Medium ([fetchers])	BSD-3

ऊपर की table और नीचे हर जगह दिए गए metadata पर एक note: star counts और version numbers जुलाई 2026 की शुरुआत में snapshot किए गए थे, और दोनों जल्दी बदलते हैं। इन्हें current मानने से पहले हर project के GitHub और package page पर दोबारा verify कर लें।

हर टूल की अलग समीक्षा

इस roundup के हर project की एक अलग deep-dive review भी है:

• Crawl4AI review
• Firecrawl review
• trafilatura review
• Playwright vs Puppeteer comparison
• Crawlee review
• Scrapy review
• Colly review
• Scrapling review

ये हैं उनके covers — और साथ में JavaScript-rendering test के दो असली screenshots, ताकि "8/8 dynamic" वाला दावा सिर्फ़ एक संख्या न रहे।

काम 1: किसी पेज को LLM-ready text में बदलना

अगर आपका लक्ष्य RAG pipeline के लिए साफ़ Markdown बनाना है, तो तीन टूल मुकाबले में आते हैं — और उनका design एक-दूसरे से काफ़ी अलग है।

Crawl4AI मार्केटिंग के नीचे असल में एक browser-backed Markdown generator है। इसके साथ घूमने वाली "adaptive intelligence self-learning selector" वाली कहानी को साइड में रख देना चाहिए: इसमें ऐसा कुछ नहीं है — वह किसी दूसरी library की trick है (उस पर हम Scrapling तक पहुँचकर बात करेंगे)। जो यह सच में करता है, वह अच्छा करता है। Books to Scrape practice site पर इसने 13,476 characters का Markdown निकाला, structured pulls के लिए CSS-schema extraction संभाली, और अपने built-in BFS deep crawl से crawl-graph fixture पर 5 pages देखे, साथ ही JavaScript page render करके screenshot भी लिया। लेकिन दो असली दिक्कतें थीं। इसका raw Markdown content filter चालू किए बिना page boilerplate साथ ले आता है, और जानबूझकर दिया गया 500 success=false के साथ लौटा — क्योंकि Crawl4AI ने HTTP error को साफ़ तौर पर catch नहीं किया, बल्कि अपनी content heuristic ने छोटे error body को देखकर उसे minimal_text ... blocked टैग कर दिया। और setup आपके disk पर दो browser stacks डाल देता है। Version 0.9.0, Apache-2.0, जुलाई की शुरुआत तक लगभग 71k stars।

Firecrawl इस समूह का भारी-भरकम विकल्प है, और इसे self-host करना सचमुच काम करता है — मैं "सचमुच" इसलिए कह रहा हूँ क्योंकि छह-container वाला stack (api, playwright-service, redis, rabbitmq, nuq-postgres, और foundationdb) वास्तव में ऊपर आया और उसी Books to Scrape page से 9,222 characters का LLM-ready Markdown निकाल पाया। इसने bundled playwright-service के ज़रिए एक JavaScript page render किया, और script के बाद वाला Einstein quote output में आ गया — इससे साबित हुआ कि render असली था। मुझे जो दो अड़चनें मिलीं वे Firecrawl की नहीं, environment की थीं, और मैं साफ़ होना चाहता हूँ ताकि कोई गलत fix न अपनाए: from-source build colima पर containerd snapshotter flake से टकराया (मैं prebuilt images पर चला गया), और colima की 198.18.x.x DNS range ने Firecrawl के SSRF guard को trigger कर दिया, जिसे मैंने ALLOW_LOCAL_WEBHOOKS=true से ठीक किया — यह local-dev workaround है, production में कुछ बंद करने वाली चीज़ नहीं। इसका self-hosted core Fire-engine, यानी cloud anti-block layer, शामिल नहीं करता, और मैंने cloud API टेस्ट नहीं किया। सबसे बड़ा मुद्दा इसका license है: Firecrawl का self-hosted core AGPL-3.0 है, इसलिए commercial use से पहले यह कानूनी तौर पर गंभीर जांच माँगता है, सिर्फ़ एक फुटनोट नहीं। जुलाई की शुरुआत तक लगभग 148k stars।

trafilatura इस समूह का सबसे अलग सोच वाला टूल है, और वही है जिसे AI-hype वाली लिस्टें अक्सर भूल जाती हैं। न browser. न structured rows. बस तेज़, साफ़ article text, pure Python में। Article fixture पर इसने title के साथ 3 में से सभी 3 असली paragraph निकाले, boilerplate पूरी तरह हटा दी — "Login," "Subscribe," या "Copyright" कुछ भी बाहर नहीं निकला — और साथ में author और date भी निकाल लिए। एक public product page पर इसने 1,324 characters का साफ़ text दिया। इसकी सीमा वही है जो इसके design से साफ़ हो जाती है: इसे किसी catalog पर डालिए और यह 12 product names as text तो दे देगा, लेकिन 0 structured rows — text मौजूद है, structure नहीं, और यह JavaScript render भी नहीं करता। Version 2.1.0 (current release), Apache-2.0, लगभग 6.2k stars। शुद्ध article extraction के लिए, मैं सबसे पहले इसी की तरफ़ देखूँगा।

ये दो Markdown character counts — Crawl4AI से 13,476 और Firecrawl से 9,222 — एक ही public page से आए थे, लेकिन इन्हें quality gap की तरह न पढ़ें। ये अलग Markdown strategies को दिखाते हैं (page chrome कितना रखा गया), न कि यह कि कौन-सा output बेहतर है। पहले बताए गए within-tool-signal rule का यही खुले तौर पर दिखता हुआ रूप है।

काम 2: JavaScript को भरोसेमंद ढंग से render करना

कुछ डेटा HTML में तब तक नहीं होता जब तक scripts चल न जाएँ, और उसी पल एक असली browser विकल्प नहीं, ज़रूरत बन जाता है। तीन टूल यह काम करते हैं — और उनमें से दो तो लगभग एक ही टूल निकले।

Playwright और Puppeteer मेरे हर टेस्ट में बराबरी पर रहे। दोनों ने local fixture पर 8/8 dynamic products render किए और public Quotes JS site पर 10 items निकाले, दोनों ने 12/12 static recall हासिल किया, और दोनों ने 500 को साफ़ तरीके से संभाला (Puppeteer response object लौटाता है, exception नहीं फेंकता)। दोनों में crawl queue नहीं आती, इसलिए 12-page link graph को चलाने के लिए hand-written BFS लिखनी पड़ी। असली फर्क बस reach का है: Playwright Chromium, Firefox, और WebKit चला सकता है, और Python तथा .NET बोलता है; जबकि Puppeteer Chrome-first है और सिर्फ़ Node पर चलता है। दो disclosures, क्योंकि यहाँ versions तेज़ी से बदलते हैं: मैंने Playwright 1.56.0 को current 1.61.1 के खिलाफ़ टेस्ट किया और सिर्फ़ Chromium इस्तेमाल किया; Puppeteer 24.16.0 को current 25.3.0 के खिलाफ़ चलाया — इसलिए नतीजे उसी संदर्भ में पढ़ें। दोनों Apache-2.0 हैं; stars लगभग 92k और 95k।

Crawlee वही टूल है जो queue वाली समस्या हल करता है, जिसे बाकी दोनों छोड़ देते हैं। यह Cheerio (HTTP) engine और Playwright (browser) engine को एक API के पीछे जोड़ता है, और एक ही पेज पर इसका फर्क पूरा pitch समझा देता है: Cheerio engine ने JavaScript से injected 0 items देखे, जबकि Playwright engine ने local पर सभी 8/8 और public site पर 10 items देखे; और इन दोनों के बीच बदलना सिर्फ़ एक line बदलने जैसा है। साथ में यह असली RequestQueue भी देता है, इसी वजह से इसे काम 3 नहीं बल्कि यही काम 2 मिलता है। headline में कोई नहीं बताता यह बात: browser engine के लिए अलग npx playwright install चाहिए, यानी लगभग 80 MiB जो npm install crawlee अपने-आप नहीं लाता। Version 3.17.0, TypeScript, Apache-2.0, लगभग 24.6k stars।

काम 3: browser के बिना तेज़ crawl करना

अगर पेज पर JavaScript नहीं है, तो browser बेवजह का भारी हथौड़ा है। यहाँ तीन HTTP-first टूल compete करते हैं, एक-एक language philosophy के अनुसार, और वे दिलचस्प तरीक़े से अलग निकलते हैं।

Scrapy इस समूह का engineering-grade framework है — spiders, JSON/CSV/XML feed exports, AutoThrottle, और सब कुछ। इसने 12/12 static recall हासिल किया, article के 3/3 paragraphs निकाले, crawl graph पर depth 0–2 में 11 pages तक गया, और handle_httpstatus_list के जरिए 500 को भी पकड़ लिया। इसकी असली सोच दिलचस्प है: यह render नहीं करता, request को दोहराता है। JavaScript page पर डालने पर इसे 0 nodes मिले — और फिर उसी page के पीछे मौजूद JSON API ने इसे 8/8 दे दिए। यही Scrapy की philosophy एक data point में: browser चलाने के बजाय उस request को ढूँढो जो page करता है और उसे replay करो। इसकी कीमत dependency stack का आकार है (Twisted, lxml, parsel), और मैंने इसे सिर्फ़ छोटे fixtures पर टेस्ट किया। Version 2.17.0, BSD-3-Clause, लगभग 63k stars।

Colly Go का जवाब है, और यह इस बारे में काफ़ी साफ़ बोलता है कि यह क्या है: एक static binary, OnHTML, OnResponse, और OnError callbacks के ज़रिए, साथ में depth control। इसने 12/12 static recall हासिल किया, OnResponse के ज़रिए JSON API से 8/8 निकाले, OnError के जरिए 500 पकड़ा, और depth-2 crawl में 17 pages तक पहुँचा — और मैं इसे ठीक इसी तरह कहूँगा, क्योंकि यह page count harness का अपना counter है, Colly की completeness की गारंटी नहीं। यह JavaScript नहीं चलाता: dynamic fixture और Quotes JS site दोनों 0 लौटे, और यह design के हिसाब से है। इसे build करने के लिए Go toolchain चाहिए, और module version (v2.3.0) अभी tagged release (v2.2.0) से आगे चल रहा है। Apache-2.0, लगभग 25k stars।

Scrapling specialist है, और यह label इसके लायक है। इसके adaptive selectors markup बदलने के बाद भी element को दोबारा ढूँढने के लिए बने हैं — इसलिए जब मैंने target की HTML class को product-name से product-title किया, तो plain selector ने 0 match किया, और adaptive re-match ने tracked element फिर भी वापस ले लिया। साधारण HTTP extraction में इसने 12/12 static और JSON API पर 8/8 हासिल किया। लेकिन इसकी docs भी यह नहीं छिपातीं: एक synthetic multi-element test में इसने 3 में से 1 recover किया — यह resilient element tracking है, total recovery नहीं, इसलिए इसे अपने दिमाग में बढ़ा-चढ़ाकर मत आँकिए। pip install scrapling के साथ बेस इंस्टॉल को चलाने के लिए [fetchers] extra भी चाहिए, और इसका StealthyFetcher compliance के लिहाज़ से एक चेतावनी है, ऐसा feature नहीं जिसे मैं slide पर बेचूँ। Version 0.4.10 (current release), BSD-3-Clause, लगभग 68.7k stars।

इन तीनों कामों के पीछे का पैटर्न

नौों टूल्स को साथ रखिए, और एक साफ़ pattern उभरता है। Full static recall — सीधा 12/12 — हर HTTP-first tool के लिए बुनियादी मानक है; आसान केस में किसी ने भी चूक नहीं की, इसलिए यही differentiator नहीं है। Browser tools तभी अपनी extra weight को सही ठहराते हैं जब JavaScript सच में मौजूद हो, और उसकी कीमत वे setup में चुकाते हैं: एक browser stack, एक extra install, या पूरा container fleet। और "built-in crawl queue" वाला कॉलम असल में framework और engine के बीच की रेखा है — Scrapy और Crawlee orchestration देते हैं, जबकि Playwright और Puppeteer में BFS आपको खुद लिखनी पड़ती है। यही field की असली बनावट है। कोई overall इसलिए नहीं जीतता क्योंकि कोई एक ही game नहीं खेल रहा।

तो आपको आखिर कौन-सा चुनना चाहिए

यह बेंच किसी एक विजेता को ताज नहीं पहनाती, क्योंकि सही जवाब tool नहीं, सवाल है — आप इन तीनों में से कौन-सा काम कर रहे हैं?

• LLM-ready Markdown चाहिए? साफ़ article text के लिए trafilatura लें, जब CSS extraction और JavaScript rendering एक ही library में चाहिए तो Crawl4AI लें, और जब self-hosted service चाहिए और AGPL-3.0 license व छह-container weight दोनों संभाल सकते हों तो Firecrawl लें।
• JavaScript render करना है? raw rendering के लिए Playwright या Puppeteer लें — engine और language के हिसाब से चुनें, क्योंकि बाकी दोनों बराबरी पर हैं — और अगर crawl orchestration भी साथ में चाहिए, तो Crawlee लें, ताकि उसे आपको खुद न लिखना पड़े।
• Static pages या reproducible APIs को scale पर crawl करना है? पूरी Python framework के लिए Scrapy, एक single binary में Go speed के लिए Colly, और जब markup drift से बचना आपकी खास, बार-बार आने वाली समस्या हो तो Scrapling।

काम के हिसाब से tool मिलाइए, और इनमें से हर एक विकल्प तार्किक है। गलत category से tool उठाइए — static page के लिए browser tool, या JavaScript app के लिए HTTP parser — और इंटरनेट की सबसे अच्छी रेटिंग वाली library भी आपको बचा नहीं पाएगी।

इसके बजाय managed AI API कहाँ fit होती है

ऊपर दिए गए सभी टूल free हैं, open-source हैं, और आप उन्हें खुद चला सकते हैं। लेकिन यही इस बेंच का साझा trade-off भी है: browser environment, crawl code, anti-bot arms race, और maintenance की हर चीज़ आपकी ज़िम्मेदारी है। कई टीमों के लिए यही control असली मकसद होता है, और license map भी वहीं मायने रखता है — field का बड़ा हिस्सा permissive है (Crawl4AI, Crawlee, Playwright, Puppeteer, और Colly में Apache-2.0; Scrapy और Scrapling में BSD-3), जबकि Firecrawl का AGPL-3.0 self-hosted core commercial use से पहले गंभीर समीक्षा माँगता है।

लेकिन ध्यान दीजिए कि इस बेंच ने और क्या दिखाया: ये टूल क्या नहीं करते। Render, crawl, structure, और blocks के बीच घूमना — बहुत कम बार सब एक साथ, और maintenance के बिना तो बिल्कुल नहीं। एक managed AI scraping API इन सबको एक call में समेट देती है। Thunderbit पर हमारा अपना developer surface वहाँ एक option है, और technical audience के लिए असली चीज़ें API, MCP server, और CLI हैं — browser extension नहीं। POST /distill साफ़ Markdown लौटाता है और POST /extract schema-defined JSON देता है, जबकि JavaScript rendering और anti-bot handling server-side होती है, आपकी machine पर नहीं। agents और coding assistants के लिए एक official MCP server भी है — extraction plan करने के लिए thunderbit_suggest_fields मुफ़्त चलता है, फिर thunderbit_distill (1 credit) और thunderbit_extract (20 credits) काम करते हैं — और terminal तथा cron jobs के लिए npx @thunderbit/thunderbit-cli से एक CLI भी मिलता है। आपकी टीम के non-developers के लिए एक no-code Chrome extension भी है, और pricing दोनों ज़रूरतों को कवर करती है।

अंतिम trade-off वही है जिसके इर्द-गिर्द यह पूरा benchmark घूमता है: आप नौ लाइब्रेरीज़ तक खुद चलाकर और संभालकर per-call लागत शून्य रख सकते हैं, या plumbing किसी और को सौंपकर request के हिसाब से भुगतान कर सकते हैं। कोई भी विकल्प गलत नहीं है। बात इस पर आती है कि stack का कितना हिस्सा आप सचमुच अपने हाथ में रखना चाहते हैं। अगर आप देखना चाहते हैं कि extraction व्यवहार में कैसे दिखती है, तो Thunderbit YouTube channel इसे कदम-दर-कदम समझाता है।

{{INTERNAL_BLOG_LINKS}}

निष्कर्ष

कोई एक सबसे अच्छा ओपन-सोर्स स्क्रेपर नहीं है, और जो लिस्ट आपको आत्मविश्वास से एक नाम दे देती है, वह चुपचाप उस सवाल को छिपा रही होती है जो असल में फैसला करता है: आप कौन-सा काम कर रहे हैं? किसी पेज को text में बदलना हो, JavaScript render करनी हो, या browser के बिना तेज़ crawl करना हो — field साफ़ तौर पर इन्हीं buckets में बँटती है, और हर bucket के अंदर चुनाव language और setup weight पर निर्भर करता है, किसी सार्वभौमिक champion पर नहीं।

अगर इस पूरी बात से आप एक आदत लें, तो यह: किसी भी tool को final करने से पहले अपने खुद के pages पर टेस्ट ज़रूर करें। यहाँ दिए गए हर number को benchmark repo में reproduce किया जा सकता है — और यही वजह है: जो tool generic roundup में टॉप करता है, वह आपके असली targets पर हमेशा वही नहीं रहता।

वेब डेटा एक्सट्रैक्शन के लिए Thunderbit आज़माएँ Get Started Free

FAQs

सबसे अच्छा ओपन-सोर्स वेब स्क्रेपर कौन-सा है? एक ही नहीं है — यह काम पर निर्भर करता है। LLM-ready text के लिए trafilatura या Crawl4AI; JavaScript rendering के लिए Playwright, Puppeteer, या Crawlee; और तेज़ HTTP crawling के लिए Scrapy या Colly। साझा टेस्ट बेंच पर हर टूल अपनी category के अंदर सबसे मजबूत था और उसके बाहर साफ़ तौर पर कमज़ोर, इसलिए one-size rankings भ्रामक होती हैं।

कौन-से ओपन-सोर्स scrapers JavaScript render करते हैं? Crawl4AI, Firecrawl, Playwright, Puppeteer, और Crawlee का Playwright engine — ये सभी JavaScript render करते हैं। Scrapy, Colly, trafilatura, और Scrapling का default HTTP fetcher ऐसा नहीं करते — उन्हें या तो page के पीछे कोई reproducible API चाहिए (Scrapy का तरीका, जिसने JSON endpoint से 8/8 निकाले) या फिर अलग browser mode।

क्या किसी site को scrape करने के लिए headless browser ज़रूरी है? सिर्फ़ तब, जब डेटा JavaScript चलने के बाद ही दिखे। अगर साधारण HTTP request और parser से content मिल जाता है, तो browser महँगा और ज़रूरत से ज़्यादा भारी solution है — ऐसे मामले में Scrapy, Colly, या Scrapling कहीं हल्के और तेज़ होंगे।

Commercial use के लिए इनमें से किसका license सबसे आसान है? ज़्यादातर permissive हैं: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) या BSD-3-Clause (Scrapy, Scrapling)। अपवाद Firecrawl का self-hosted core है, जो AGPL-3.0 है और उस पर commercial product बनाने से पहले गंभीर license review चाहिए।

क्या ये benchmark numbers reproducible हैं? हाँ। हर runner, fixture, और raw result एक public MIT-licensed repo में है। एक सीमा ध्यान में रखें: recall और structural results tools के बीच तुलना योग्य हैं, लेकिन absolute character counts सिर्फ़ उसी tool के भीतर signal हैं, क्योंकि हर pack fixtures की अपनी copy रखता है, कोई एक canonical copy साझा नहीं करता — इसलिए rates और pass/fail की तुलना करें, raw character totals की नहीं।