MarkItDown को अक्सर वेब स्क्रैपर समझ लिया जाता है, लेकिन यह धारणा गलत है। इसमें न तो कोई क्रॉलर है, न JavaScript इंजन, और न ही ऐसा तरीका कि यह किसी URL को लेकर उसका boilerplate हटाकर साफ़ लेख निकाल दे। यह आपके पास मौजूद bytes — जैसे PDF, Word डॉक्यूमेंट, spreadsheet, slide deck — को लेकर पूरे कंटेंट को Markdown में बदल देता है, जिसे language model पढ़ सके।
मैंने Microsoft के MarkItDown को लगभग दो हफ्तों तक एक ही Mac पर असली दस्तावेज़ों की एक पूरी बैटरी पर चलाया। हर table को मैंने रन से पहले तैयार किए गए manifest के खिलाफ स्कोर किया, और हर conversion का समय मापा। संक्षेप में: साफ़ input पर यह तेज़ और भरोसेमंद है, लेकिन इसके packaging में एक 73 MB का machine-learning runtime छिपा है जिसकी आपको उम्मीद नहीं होती; और इसके tables ऐसे तरीके से टूटते हैं कि वे “क्या text बच गया?” वाली जाँच पास कर लेते हैं, लेकिन “क्या data सही column में है?” वाली जाँच में फेल हो जाते हैं। नीचे पूरा चित्र है, numbers के साथ।
MarkItDown असल में है क्या
MarkItDown Microsoft का एक Python utility है जो files और Office documents को LLMs के लिए optimized Markdown में बदलता है। इसे PDF, .docx, .xlsx, .pptx, image, HTML file, या कुछ अन्य formats दें, और यह Markdown वापस देता है। इसे चलाने के तीन तरीके हैं: CLI (markitdown file.pdf -o out.md, या stdin से pipe करके), Python API (MarkItDown().convert(...)), और agent workflows के लिए एक optional MCP server।
सबसे महत्वपूर्ण बात यह है कि यह क्या नहीं करता। README में इसका दावा नहीं है, और testing में मैंने इसकी पुष्टि की: इसमें crawling नहीं है, JS rendering नहीं है, link-following नहीं है, pagination नहीं है, और न ही readability-style main-content extraction। यह एक पूरे-document converter है। आप bytes देते हैं; यह उन्हें standardize करता है। यही एक फर्क तय करता है कि यह tool आपके stack में फिट बैठता है या नहीं — इसलिए मैं इस पर बार-बार वापस आऊँगा।
Repo GitHub के vanity metrics के हिसाब से काफ़ी भारी है — mid-July 2026 तक 165,282 stars और 11,790 forks, MIT license के साथ, और latest release (v0.1.6) 2026-05-26 को आया। लेकिन यह star count ज़्यादा Microsoft-org repo होने और LLM tooling के प्रति सामान्य उत्साह की वजह से है, conversion internals की maturity का संकेत नहीं। अभी भी 833 open issues हैं, और उनमें से कुछ install करने से पहले जानना ज़रूरी है (नीचे और)।
HTML से Markdown: तेज़ और पूरा, boilerplate सहित
मेरी scraper-review series बाकी fixtures के लिए वही चार web pages इस्तेमाल करती है, इसलिए मैंने MarkItDown को वही local HTML files दिए — इसे scraper की तरह grade करने के लिए नहीं, बल्कि यह देखने के लिए कि इसका HTML-to-Markdown conversion कितना अच्छा है। अच्छी तरह tagged pages पर यह सचमुच अच्छा है।
चारों pages core install पर बिना किसी extra के convert हो गए, और हर body-content probe बच गया। Wikipedia का "Web scraping" article (226 KB) अपने heading tree के साथ सही तौर पर mirror हुआ — एक h1, सात h2, बारह h3, जो article की असली section structure से मेल खाते हैं — और 418 links proper [text](url) के रूप में preserved रहे। Scrape This Site forms page पर मौजूद 26×9 hockey-stats table एक साफ़ 27-row GFM pipe table बन गई (header + separator + 26 data rows), खाली cells समेत। इन pages पर speed कोई issue नहीं था: छोटे quotes page के लिए median 48 ms से लेकर 226 KB वाले Wikipedia page के लिए 352 ms तक।
लेकिन यहाँ एक catch है, और यह bug से ज़्यादा design choice है। MarkItDown boilerplate हटाता नहीं है। यह पूरे <body> को convert करता है, इसलिए site chrome भी साथ आ जाता है — और यह residue page पर मौजूद chrome की मात्रा के साथ बढ़ता है।
| Page | Output chars | Headings (h1/h2/h3) | Links | Site-chrome lines |
|---|---|---|---|---|
| Books to Scrape | 10,478 | 1 / 0 / 0 | 94 | 0.6% (1/159) |
| Quotes to Scrape | 2,973 | 1 / 1 / 0 | 55 | 1.2% (1/86) |
| ScrapeThisSite forms | 3,385 | 1 / 0 / 0 | 31 | 6.7% (5/75) |
| Wikipedia Web scraping | 60,159 | 1 / 7 / 12 | 418 | 12.4% (42/338) |
लगभग chrome-free Books homepage पर output lines का केवल 0.6% chrome है। Wikipedia पर यह 12.4% है — 338 non-empty lines में से 42 हैं “jump to content,” “toggle the table of contents,” “22 languages,” “retrieved from,” cookie और license footers। Wikipedia के maintenance banners (“This article needs additional citations”) भी faithfully two-column pipe tables में render हो जाते हैं, और यही वजह है कि जिस page पर कोई असली data table नहीं है, वहाँ भी नौ table rows बन जाते हैं।
यह MarkItDown का कुछ गलत करना नहीं है। यह whole-document converter है, readability extractor नहीं: faithful HTML-to-Markdown और clean article extraction दो अलग काम हैं। Trafilatura और Firecrawl जैसी tools सिर्फ main content लौटाने की कोशिश करती हैं; MarkItDown पूरा page लौटाता है। अंदर से _html_converter.py <script> और <style> हटाता है, फिर पूरे body को markdownify library को दे देता है — path में कहीं भी main-content heuristic नहीं है। अगर आपको सिर्फ article चाहिए, तो यह सही layer नहीं है।
इसकी असली ताक़त: PDF, DOCX, XLSX, PPTX
Documents MarkItDown का मुख्य क्षेत्र हैं। मैंने इसे असली public files पर चलाया — एक arXiv paper जिसके पास text layer थी, Bitcoin whitepaper, एक image-only scanned PDF जिसे मैंने render करके textless बनाया, और MarkItDown के अपने test suite की DOCX/XLSX/PPTX files (UUIDs के साथ seed की गईं ताकि silent content loss पकड़ सकूँ)।
| Document | Input | Output chars | Probes | Median time | Notes |
|---|---|---|---|---|---|
| arXiv 1706.03762 (text-layer PDF) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" all present |
| Bitcoin whitepaper (9 pp PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" present |
| Scanned PDF (no text layer) | 89 KB | 0 | 0/4 | 15 ms | empty output, no error, no OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | headings + GFM table; embedded UUIDs survive |
| DOCX with equations | 15 KB | 240 | — | 101 ms | Office Math preserved as LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | each sheet → ## SheetName + GFM table |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | slide-number markers, tables, chart → table |
Text-layer PDFs पर text recall बेहतरीन रहा — arXiv “Attention Is All You Need” paper पर मेरे pre-registered probes में से 7/7, और Bitcoin whitepaper पर 6/6 — और Office files में से किसी ने भी एक भी UUID sentinel नहीं खोया। यानी maintainers के अपने regression fixtures पर silent content loss नहीं हुई। एक छोटा लेकिन खास जीत: DOCX path (mammoth के ज़रिए) Office Math equations को LaTeX के रूप में preserve करता है, जिससे equations.docx असली $$...$$ math में बदल जाती है। अगर आप math-heavy Word docs को LLM में दे रहे हैं, तो यह एक वास्तविक, अगर सीमित, ताकत है, जिसे मैंने और कहीं इतनी साफ़ तौर पर नहीं देखा।
इस क्षेत्र में दो निष्कर्ष ऐसे हैं जिन पर अलग से ध्यान देना चाहिए, क्योंकि यही सबसे ज़्यादा आपको नुकसान पहुँचा सकते हैं।
ऐसा scanned PDF जो गायब हो जाता है
अगर MarkItDown को ऐसा image-only PDF दें जिसमें text layer न हो, तो वह खाली string लौटाता है। Zero characters, कोई exception नहीं, कोई warning नहीं — और conversion लगभग 15 ms में हो जाती है, क्योंकि निकालने के लिए कुछ है ही नहीं। MarkItDown का PDF path सिर्फ text extraction करता है (अंदर pdfminer और pdfplumber), और core install या किसी pip extra के साथ OCR नहीं आता।
Batch processing में यह बहुत मायने रखता है। अगर कोई developer PDFs का एक folder देता है जिसमें कुछ files scans हैं, तो उन files के लिए silently empty results मिलते हैं और कोई संकेत नहीं मिलता कि कुछ छोड़ा गया। मैंने fixture को यह सुनिश्चित करने के लिए भी जाँचा कि खराब नहीं है, pdfminer के extract_text को सीधे उस पर चला कर — zero stripped characters, कोई text layer नहीं, पुष्टि हो गई — इसलिए empty output MarkItDown का असली behavior है, किसी real scan पर। यह लंबे समय से खुले OCR-fallback gap (#1268) से मेल खाता है, जिसे upstream पर काफी समय से ट्रैक किया जा रहा है। दस्तावेज़ित रास्ता optional Azure Document Intelligence backend या plugin है; इनमें से कोई भी default install में नहीं है।
PDFs में structure नहीं, बस flat text मिलता है
दोनों text-layer PDFs में MarkItDown ने zero Markdown heading markers बनाए। PDF में semantic heading tags नहीं होते, और MarkItDown font size देखकर headings नहीं अनुमानित करता, इसलिए हर line body level पर आ जाती है। Text recall ऊँचा है; structure सपाट है।
यह सिर्फ मेरा निष्कर्ष नहीं है। सार्वजनिक third-party benchmarks MarkItDown की PDF heading-hierarchy को लगभग 0.0 और table fidelity को लगभग 0.27 देते हैं, जो Docling के TableFormer-backed 0.88 से काफी नीचे है (देखें MarkItDown vs Docling vs Marker comparison और READoc benchmark)। मेरे fixtures ने भी वही दिखाया, जो evidence की मजबूती है — मेरे numbers बाहरी source से मेल खाते हैं। वही benchmarks यह भी बताते हैं कि MarkItDown Docling की तुलना में लगभग 100× तेज़ चलता है, और मेरे seconds-not-minutes timings भी उसी से मेल खाते हैं, जबकि layout-model tool documents पर कई मिनट लगाता है। निष्कर्ष: MarkItDown आपको साफ़, तेज़ PDF text देता है; PDF की structure नहीं। अगर headings और tables को बचाना ज़रूरी है, तो Docling या Marker जैसा layout-model tool सही layer है।
Tables: content हमेशा बचता है, structure हमेशा नहीं
Tables वही जगह हैं जहाँ “text बच गया?” और “data usable है?” दो अलग सवाल बन जाते हैं। इसलिए मैंने 13-case matrix बनाई — हर case के लिए एक <table>, और हर एक को रन से पहले लिखे गए manifest के खिलाफ score किया — ताकि साफ़ हो सके कि कौन-सी shapes टिकती हैं और कौन-सी टूटती हैं।
मुख्य निष्कर्ष: MarkItDown ने table content कभी नहीं खोया। सभी 13 cases में pre-registered tokens का 100% बचा रहा। लेकिन structural fidelity तीन तरह से बँटी। सात में से तेरह cases में एक सही GFM grid बनी (plain, header-colspan, 24-column-wide, headerless, empty-cells, block-in-cell, और right-to-left Arabic)। चार cases ragged हो गए, क्योंकि Markdown में spanned cell की कोई अवधारणा नहीं है, इसलिए rowspan, colspan, और malformed sources छोटी rows बनाते हैं। और दो cases बिल्कुल टूट गए।
ये दो breaks नाम लेने लायक हैं। Nested table (<td> के अंदर <table>) inline flatten हो जाती है, अपनी pipes और separator row parent cell में डाल देती है, और 14-“column” की बेकार row बना देती है। और cell के भीतर मौजूद literal | escape नहीं होता — cell text a | b दो columns बन जाता है, x || y तीन columns बन जाता है — इसलिए दो-column table से two, three, और four columns वाली rows निकलती हैं, और कोई भी downstream Markdown parser गलत boundaries पढ़ता है। दिलचस्प बात यह है कि cell के भीतर asterisks और backticks escape होते हैं; सिर्फ pipes नहीं। इसकी जड़ यह है कि MarkItDown का HTML path markdownify के default table handling का उपयोग करता है, और उसका custom subclass links, images, और headings को override करता है, लेकिन table cells को नहीं। यही pipe-escaping bug class CSV converter के लिए एक open issue (#2019) के रूप में मौजूद है, हालांकि वह fix उस HTML path को नहीं छूता जिसे मैंने test किया।
सबसे subtle मुद्दा — और data engineer को जो सबसे ज़्यादा देखना चाहिए — वह rowspan है। Case t03 सिर्फ ragged नहीं होता; यह data को quietly misalign करता है। rowspan=2 वाला label (“Fruit”) एक बार emit होता है, और उसके नीचे वाली row छोटी two-column row (| Banana | 8 |) बन जाती है, इसलिए “Banana” Group column के नीचे चला जाता है, Item के नीचे नहीं। हर token मौजूद है। कोई naive “second column पढ़ो” वाला consumer गलत value उठा लेता है। यह वही bug है जो text-survival check पास कर जाता है और dataset को चुपचाप corrupt कर देता है।
Span limitation खुद एक ज्ञात, tracked design constraint है (#1211, #1248) — flat GFM pipe grid spans या nesting को सचमुच represent नहीं कर सकती, इसलिए converter structure के बदले content-completeness चुनता है। बीच में कुछ अच्छे behaviors भी हैं: headerless tables के लिए एक synthesized blank header row बनती है (ताकि कोई data चुपचाप header में promote न हो जाए), empty cells preserved रहती हैं, और <caption> table के ऊपर एक text line के रूप में बची रहती है।
Install और startup: वह tax जिसके बारे में एक “lightweight utility” चेतावनी नहीं देता
इससे ज़्यादा मुझे कुछ और surprise नहीं हुआ, और यहीं “lightweight Python utility” वाली framing quietly overpromise कर देती है।
पहली बात: pip install 'markitdown[all]' मत चलाइए। Python 3.14 पर यह चुपचाप markitdown 0.0.2 तक backtrack कर देता है — यानी दो साल पुराना release — और मैंने इसे साफ़ virtual environment में live reproduce किया। Pinning करने पर वजह दिखती है: pip install 'markitdown[all]==0.1.6' error देता है क्योंकि [all] extra youtube-transcript-api~=1.0.0 pin करता है, और current PyPI पर उस range के हर build पर Python <3.14 की gating है, जबकि 3.14-compatible builds इस pin से बाहर हैं। इसलिए resolver उस आख़िरी release तक वापस चला जाता है जिसकी dependencies वह satisfy कर सकता है। यह एक open upstream issue (#2179) से मेल खाता है। सरल fix है — version pin करें और extras अलग-अलग install करें: pip install 'markitdown==0.1.6', फिर pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. ये सब cleanly resolve हो जाते हैं; poisoned pin सिर्फ combined [all] bundle में है। (यह trap Python-version dependent है — Python 3.13 या उससे पहले [all] अलग तरीके से resolve हो सकता है।)
दूसरी बात, footprint। Core install 161 MB का है (13 MB की empty venv plus 148 MB)। इसमें से onnxruntime (73 MB) और numpy (34 MB) मिलकर 107 MB बनाते हैं — यानी पूरे core footprint का 66% — और दोनों एक ही hard dependency से आते हैं: magika, Google का ML file-type detector। यानी एक text converter अपने base install में, किसी document extra को जोड़े बिना, 73 MB का ONNX inference runtime साथ लाता है। document extras जोड़ने पर venv 310 MB तक पहुँच जाता है। यह headless-browser stack से फिर भी हल्का है, लेकिन अगर आप pip install-और-done micro-utility की उम्मीद कर रहे थे, तो जान लें कि साथ में ONNX runtime भी आता है।
तीसरी बात — और मेरे पूरे set में यही वह finding है जो हर novelty check पास करती है — clean install के बाद भी import markitdown इस मशीन पर लगभग 3.35 seconds लेता है। लागत लगभग पूरी तरह import time पर है: markitdown._markitdown पूरे converter registry को eagerly import करता है (2.56 s cumulative, कुल का 76%), जो pandas (594 ms, XLSX converter के ज़रिए), python-pptx (427 ms), magika (354 ms), और requests (270 ms) को खींच लाता है — चाहे आप इनमें से कोई format convert करें या नहीं। लंबे समय तक चलने वाली service के लिए यह import amortized हो जाता है और irrelevant है। लेकिन CLI invocation या serverless cold start के लिए यह एक वास्तविक per-process tax है, जिसकी उम्मीद “lightweight utility” label से नहीं होती। (न्यायपूर्ण चेतावनी: यह single profiled run है, multi-run distribution नहीं।)
Scale: यह क्रैश नहीं करता, लेकिन PDFs के लिए CPU और spreadsheets के लिए RAM बजट करें
मैंने चार बड़े subjects को अलग-अलग process में चलाया, ताकि peak memory पहले के किसी run से contaminate न हो। कुछ भी क्रैश नहीं हुआ। लेकिन cost profile काफ़ी असंतुलित है।
| Subject | Input | Output chars | Median time | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (492-page PDF) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50,000 rows × 8 cols | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15-page PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 rows × 64 cols | 46 KB | 120,129 | 2.9 s | +22 MB |
492-page NIST PDF का median time 192.5 seconds आया — लगभग 3.2 minutes, या 0.39 s/page — क्योंकि pdfplumber हर page पर word-position form-detection चलाता है। Peak RSS +40 MB पर ही रहा, यानी यह CPU-bound है, memory-bound नहीं। यहाँ तक कि 15-page arXiv PDF भी अपने isolated process में 12.6 seconds ले गया — वही file मेरी document suite के अंदर warm स्थिति में दिखे 3.7 seconds से लगभग 3.4× ज़्यादा। यह gap cold-process cost है, और यह साबित करता है कि per-page work असली driver है, raw byte size नहीं। उस PDF के लिए एक transferable number चाहिए तो isolated 12.6 s लें।
Spreadsheet path bottleneck उल्टा कर देता है। 2.1 MB, 50,000-row XLSX +374 MB peak RSS तक फूल गई (और 3.7 million output characters बनाए) क्योंकि converter पूरी sheet को load करता है और memory में एक बड़ा Markdown string बनाता है। इसलिए practical guidance सीधी है: बड़े PDFs के लिए मिनटों का CPU बजट रखें; बड़े spreadsheets के लिए सैकड़ों MB RAM। ये macOS arm64 और Python 3.14 पर एक single-machine measurement हैं, और per-page/per-row constants platform-specific हैं — लेकिन पैटर्न (PDF धीमा और CPU-bound है, XLSX memory-heavy है, कुछ भी क्रैश नहीं करता) वही हिस्सा है जो आगे भी काम आएगा।
Thunderbit कहाँ फिट बैठता है — और कहाँ नहीं
वेब डेटा extraction के लिए Thunderbit आज़माएँ
यह एक ऐसा comparison है जिसमें बढ़ा-चढ़ाकर बोलना आसान होगा, इसलिए मैं सीमा साफ़ रखूँगा। MarkItDown और Thunderbit पास-पास की समस्याएँ हल करते हैं, एक जैसी नहीं।
MarkItDown आपके पास मौजूद files को convert करता है। Thunderbit पहले page fetch करता है। Thunderbit का /distill endpoint live web page को साफ़, LLM-ready Markdown में बदल देता है — JS rendering, anti-bot, और dynamic content को संभालते हुए, जिनके लिए MarkItDown में कोई machinery नहीं है — और इसका /extract endpoint raw Markdown नहीं, बल्कि schema-matched structured JSON लौटाता है। Developers के लिए यह एक ही AI engine के ऊपर API (POST /distill / POST /extract), MCP server, और CLI (npx @thunderbit/thunderbit-cli) के रूप में उपलब्ध है — वही engine जो 100,000+ user extension के पीछे है।
इसलिए इनमें सिर्फ एक जगह overlap है — दोनों “LLM-ready Markdown” दे सकते हैं — लेकिन input domain अलग है: Thunderbit का distill open web पर मौजूद URL लेता है, MarkItDown local file लेता है। ये drop-in equivalents नहीं हैं, और मैं ऐसा pretend नहीं करूँगा। असली stack दोनों का उपयोग करता है: Thunderbit (या Firecrawl-style service) से web fetch और crawl करें, फिर जो mixed local documents आपके पास हैं — PDFs, decks, spreadsheets — उन्हें MarkItDown से normalize करें। एक network संभालता है; दूसरा file drawer।
फायदे और नुकसान
ताकतें
- साफ़ HTML पर पूरे body का recall बहुत अच्छा (4/4 pages), heading trees और links ठीक से preserved
- PDF/DOCX text recall बहुत ऊँचा (arXiv 7/7 probes, Bitcoin 6/6) और maintainers की own Office fixtures पर कोई silent content loss नहीं
- Office Math equations LaTeX के रूप में preserved — एक असली niche जीत
- किसी भी scale subject पर crash नहीं किया, 492-page PDF और 50k-row XLSX तक
- चलाना आसान: CLI,
convert(), stdin piping, और optional MCP server - MIT-licensed, Microsoft द्वारा actively maintained, और responsive issue tracker
कमज़ोरियाँ
- Boilerplate छोड़ता नहीं — Wikipedia पर 12.4% तक chrome lines; यह article extractor नहीं है
- Tables spans, nesting, और in-cell pipes पर टूटते हैं (2/13 broken, 4/13 ragged), और rowspan data को silently गलत column में डाल सकता है
- Scanned/image-only PDFs खाली output देते हैं, OCR नहीं, error नहीं
- PDF output में zero heading structure होती है (public benchmarks से मेल खाती है)
- 161 MB core install, जिसमें 73 MB ONNX runtime शामिल; लगभग 3.35 s cold import
[all]extra Python 3.14 पर चुपचाप दो साल पुराने 0.0.2 पर backtrack कर जाता है
किसे इस्तेमाल करना चाहिए, किसे नहीं
MarkItDown तब चुनें जब आपके पास local documents का mixed pile हो — Word, Excel, PowerPoint, text-layer PDFs — और आप उन्हें LLM pipeline के लिए Markdown में standardize करना चाहते हों, जहाँ preserved structure से ज़्यादा complete text महत्त्वपूर्ण है। Batch job में last-mile converter के रूप में, model को साफ़ text देने के लिए, यह तेज़, भरोसेमंद, और मुक्त है।
इसे छोड़ दें, या किसी और tool के साथ जोड़ें, अगर आपका काम इनमें से कोई है: web page से सिर्फ main article चाहिए (readability या Firecrawl-style tool लें); PDF की headings और tables को intact रखना है (तो Docling या Marker देखें); या input में scanned documents हैं जिन्हें OCR चाहिए (तो Azure backend या कोई और tool चाहिए होगा)। और अगर आप scraper ढूँढ़ रहे थे — यानी ऐसा tool जो fetch और crawl करे — तो यह वह नहीं है।
मैंने scraper-shaped rubric पर जो provisional scoring की, उसमें MarkItDown को 60/100 मिला, और यह कम score एक converter को crawler के test पर grade करने का परिणाम है। अपने असली क्षेत्र में इसके text-fidelity scores ऊँचे हैं; कमजोरियाँ structure (tables, PDF headings) और packaging (footprint, import, [all] trap) में हैं, text quality में नहीं। इसे वही समझकर आँकिए जो यह है — एक file-to-Markdown converter — और यह एक ठोस, अच्छी तरह maintained tool निकलता है, जिसमें कुछ sharp edges हैं, जिन्हें production में wire करने से पहले जानना चाहिए।
अक्सर पूछे जाने वाले सवाल
क्या MarkItDown एक web scraper है?
नहीं। इसमें crawler नहीं है, JavaScript rendering नहीं है, link-following नहीं है, और pagination नहीं है। यह आपके पास मौजूद files और documents — PDF, DOCX, XLSX, PPTX, images, HTML — को Markdown में convert करता है। अगर आपको live web pages fetch और crawl करने हैं, तो Thunderbit या Firecrawl जैसा scraping tool चाहिए; MarkItDown उस के बाद वाला step है, जो fetched या local files को साफ़ Markdown में बदलता है।
pip install markitdown[all] पुराना version क्यों install करता है?
Python 3.14 पर [all] extra youtube-transcript-api~=1.0.0 pin करता है, और उस range के सभी builds Python 3.14 से नीचे वाले versions तक gated हैं। Resolver उस pin को satisfy नहीं कर पाता, इसलिए वह चुपचाप markitdown 0.0.2, यानी दो साल पुराने release, पर वापस चला जाता है। Fix यह है कि version pin करें और extras अलग-अलग install करें: pip install 'markitdown==0.1.6', फिर pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. यह issue #2179 के रूप में tracked है।
क्या MarkItDown scanned PDFs पर OCR करता है?
Default install में नहीं। इसका PDF path सिर्फ text extraction करता है, इसलिए image-only PDF जिसमें text layer नहीं है, खाली string लौटाता है — कोई error नहीं, कोई warning नहीं। OCR के लिए optional Azure Document Intelligence backend या plugin चाहिए, जो default में ship नहीं होता। यह लंबे समय से tracked gap है (issue #1268)।
Tables को MarkItDown कितनी अच्छी तरह संभालता है?
Content के स्तर पर बहुत अच्छा — मेरे 13-case test में हर case में table content 100% preserved रहा। Structure के स्तर पर shape पर निर्भर करता है: simple, wide, headerless, और empty-cell tables साफ़ GFM grids बनकर निकलते हैं, लेकिन rowspan और colspan ragged हो जाते हैं (और rowspan data को quietly गलत column में डाल सकता है), nested tables garbage rows में flatten हो जाते हैं, और cells के अंदर literal pipe characters escape नहीं होते। Markdown का flat table format spans या nesting को represent ही नहीं कर सकता।
क्या MarkItDown बड़े documents के लिए तेज़ है?
यह बड़े files पर crash नहीं करता, लेकिन resource budget file type के हिसाब से रखें। 492-page PDF को लगभग 3.2 minutes (करीब 0.39 s/page) लगे क्योंकि यह हर page पर form-detection करता है, और यह CPU-bound है। 50,000-row spreadsheet लगभग एक minute में पूरी हुई, लेकिन +374 MB RAM लगी क्योंकि यह memory में एक बड़ा Markdown string बनाता है। बड़े PDFs के लिए मिनटों का CPU, और बड़े spreadsheets के लिए सैकड़ों MB RAM का अनुमान रखें।
वेब डेटा extraction के लिए Thunderbit आज़माएँ Get Started Free
