MarkItDown çoğu zaman web scraper’larla aynı sepete konuyor; ama bu yanlış bir sınıflandırma. İçinde crawler yok, JavaScript çalıştırma motoru yok, bir URL’yi çekip gereksiz sayfa kalıntılarını ayıklama yeteneği yok. Yaptığı şey, elinizde zaten bulunan baytları — bir PDF, Word belgesi, elektronik tablo, slayt dosyası — alıp bunların tamamını bir dil modelinin okuyabileceği Markdown formatına dönüştürmek.
Microsoft’un MarkItDown aracını birkaç hafta boyunca tek bir Mac üzerinde gerçek belgelerle test ettim; her tabloyu, çalıştırmadan önce hazırladığım bir manifest’e göre değerlendirdim ve her dönüşümün süresini ölçtüm. Kısa özet: temiz girdilerde hızlı ve sadık sonuç veriyor, ancak paketleme yapısı istemediğiniz 73 MB’lık bir makine öğrenimi çalışma zamanı bileşenini beraberinde getiriyor; ayrıca tabloları bazen öyle dönüştürüyor ki “metin kayboldu mu?” kontrolünden geçiyor ama “veri doğru sütunda mı?” sorusunda sınıfta kalıyor. Aşağıda tüm tabloyu, sayılarla birlikte bulacaksınız.
MarkItDown aslında nedir?
MarkItDown, Microsoft’un dosya ve Office belgelerini LLM’ler için optimize edilmiş Markdown’a dönüştüren bir Python aracıdır. Bir PDF, .docx, .xlsx, .pptx, bir görsel, bir HTML dosyası ya da benzeri birkaç format verin; size Markdown olarak geri döndürür. Üç farklı kullanım yolu sunar: CLI (markitdown file.pdf -o out.md ya da stdin üzerinden), Python API (MarkItDown().convert(...)) ve agent iş akışları için opsiyonel bir MCP sunucusu.
Burada en önemli ayrım, MarkItDown’ın ne yapmadığıdır; çünkü README’de de bunu iddia etmiyor ve testlerde ben de doğruladım: crawling yok, JS render yok, link takibi yok, sayfalama yok ve readability tarzı ana içerik çıkarımı yok. Bu araç tam belge dönüştürücüdür. Baytları siz getirirsiniz; o onları standartlaştırır. Bu tek fark, bu aracın sizin stack’inizde yer alıp almayacağını belirler; o yüzden bu konuya tekrar tekrar döneceğim.
Repo, GitHub’un gösteriş metriklerinde oldukça ağır bir isim: 2026 Temmuz ortası itibarıyla 165.282 yıldız ve 11.790 fork, MIT lisanslı ve en son sürümü (v0.1.6) 2026-05-26 tarihinde çıkmış. Ancak bu yıldız sayısı, dönüşüm altyapısının olgunluğundan çok Microsoft ekosistemine ve genel LLM araçlarına olan ilgiyi yansıtıyor. Ayrıca 833 açık issue var; bazıları da kurulumdan önce bilmeniz gereken türden (aşağıda değineceğim).
HTML’den Markdown’a: hızlı ve eksiksiz, ama sayfa kalıntılarıyla birlikte
İnceleme serimin geri kalanında aynı dört web örneğini kullanıyorum; MarkItDown’a da bu yerel HTML dosyalarını aynen verdim — bir scraper olarak puanlamak için değil, HTML’den Markdown’a dönüşüm kalitesini görmek için. İyi etiketlenmiş sayfalarda gerçekten güçlü.
Dört sayfanın hepsi çekirdek kurulumda, ek paket gerekmeden dönüştü ve gövde içeriğine ait tüm kontrol noktaları korundu. Wikipedia’daki “Web scraping” makalesi (226 KB), başlık ağacını olduğu gibi yansıttı — bir h1, yedi h2, on iki h3; makalenin gerçek bölüm yapısıyla birebir uyumlu — ve 418 bağlantıyı düzgün [metin](url) formatında sakladı. Scrape This Site forms sayfasındaki 26×9’luk hokey istatistikleri tablosu da temiz bir 27 satırlı GFM pipe tabloya dönüştü (başlık + ayırıcı + 26 veri satırı), boş hücreler dahil. Hız tarafında da sorun yoktu: küçük quotes sayfasında ortanca 48 ms’den 226 KB’lık Wikipedia sayfasında 352 ms’ye kadar çıktı.
Ama işin püf noktası şu; bu bir hata değil, bir tasarım tercihi. MarkItDown gereksiz sayfa öğelerini ayıklamaz. Tüm <body>’yi dönüştürür; yani siteye ait çerçeve, menü, footer ve benzeri parçalar da beraber gelir — ve sayfada ne kadar çok çerçeve öğesi varsa, geride kalan iz de o kadar büyür.
| Sayfa | Çıktı karakteri | Başlıklar (h1/h2/h3) | Bağlantılar | Site kalıntısı satırları |
|---|---|---|---|---|
| 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) |
Neredeyse hiç çerçeve öğesi olmayan Books ana sayfasında, çıktı satırlarının yalnızca %0,6’sı site kalıntısı. Wikipedia’da ise bu oran %12,4’e çıkıyor — boş olmayan 338 satırın 42’si “içeriğe atla”, “içindekiler tablosunu aç/kapat”, “22 dil”, “şuradan alındı”, çerez ve lisans altbilgileri gibi parçalar. Wikipedia’daki bakım şeritleri (“Bu makalenin ek kaynaklara ihtiyacı var”) bile iki sütunlu pipe tablolara sadakatle dönüştürülüyor; gerçek bir veri tablosu olmayan bir sayfada dokuz tablo satırı görünmesinin nedeni bu.
Bunların hiçbiri MarkItDown’ın yanlış bir şey yaptığı anlamına gelmiyor. Bu bir bütün belge dönüştürücüdür; readability çıkarıcısı değil. Sadık HTML’den Markdown’a dönüşüm ile temiz makale çıkarımı farklı işlerdir. Trafilatura ve Firecrawl tarzı araçlar yalnızca ana içeriği döndürmeyi hedefler; MarkItDown ise sayfanın tamamını verir. İçeride _html_converter.py, <script> ve <style> etiketlerini temizleyip tüm gövdeyi markdownify kütüphanesine bırakır — yani yolda ana içerik tahmini yapan bir mantık yok. Sadece makaleyi istiyorsanız, bu doğru katman değil.
Asıl oyun alanı: PDF, DOCX, XLSX, PPTX
MarkItDown esas olarak belgeler için tasarlanmış. Ben de bunu gerçek ve herkese açık dosyalarda denedim — metin katmanı olan bir arXiv makalesi, Bitcoin whitepaper’ı, sıfır metin içeren ve görüntü olarak render edilmiş bir taranmış PDF, ayrıca UUID’lerle işaretlenmiş DOCX/XLSX/PPTX test dosyaları (sessiz içerik kaybını tespit edebilmek için).
| Belge | Girdi | Çıktı karakteri | Kontroller | Ortanca süre | Notlar |
|---|---|---|---|---|---|
| arXiv 1706.03762 (metin katmanlı PDF) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | başlık, "Transformer", "BLEU", "References" mevcut |
| Bitcoin whitepaper (9 sayfa PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" mevcut |
| Taranmış PDF (metin katmanı yok) | 89 KB | 0 | 0/4 | 15 ms | boş çıktı, hata yok, OCR yok |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | başlıklar + GFM tablo; gömülü UUID’ler korunuyor |
| Denklemler içeren DOCX | 15 KB | 240 | — | 101 ms | Office Math LaTeX olarak korunuyor |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | her sayfa → ## SheetName + GFM tablo |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | slayt numarası işaretleri, tablolar, grafik → tablo |
Metin katmanı olan PDF’lerde metin yakalama oranı çok iyiydi — arXiv’de önceden tanımlanmış 7 kontrolün 7’si, Bitcoin whitepaper’da 6’sının 6’sı geçti — ve Office dosyalarının hiçbiri tek bir UUID işaretini kaybetmedi; yani geliştiricilerin kendi regresyon örneklerinde sessiz içerik kaybı yok. Küçük ama anlamlı bir kazanım: DOCX yolu (mammoth üzerinden) Office Math denklemlerini LaTeX olarak koruyor; equations.docx dosyasını gerçek $$...$$ matematiğine dönüştürüyor. Eğer matematik ağırlıklı Word belgelerini bir LLM’e verecekseniz, bu gerçekten değerli, ama çok spesifik bir avantaj.
Bu alanda özellikle dikkat edilmesi gereken iki bulgu var; bunlar sizi en çok vurma ihtimali olanlar.
Sessizce yok olan taranmış PDF
MarkItDown’a metin katmanı olmayan, yalnızca görüntü içeren bir PDF verirseniz boş bir string döndürür. Sıfır karakter, istisna yok, uyarı yok — çünkü çıkarılacak bir şey olmadığı için yaklaşık 15 ms’de dönüşüm tamamlanır. MarkItDown’ın PDF yolu yalnızca metin çıkarımı yapar (arka planda pdfminer ve pdfplumber), ve çekirdek kurulumda ya da herhangi bir pip ekstra paketinde OCR bulunmaz.
Bu, toplu işlemede önemli. Bir klasörde hem normal PDF’ler hem de taramalar varsa, taranan dosyalar için hiçbir sinyal vermeden boş sonuç alırsınız. Dosyanın bozuk olmadığını kontrol etmek için pdfminer’ın extract_text fonksiyonunu doğrudan çalıştırdım — sıfır karakter, metin katmanı yok, doğrulandı — yani boş çıktı, gerçek bir taramada MarkItDown’ın gerçek davranışı. Bu, uzun süredir açık olan OCR yedekleme boşluğu (#1268) sorununu da birebir yeniden üretiyor. Belgelenen çözüm, opsiyonel Azure Document Intelligence backend’i veya bir eklenti; ikisi de varsayılan kurulumda yok.
PDF’ler düz metin olarak çıkar, yapı olarak değil
Her iki metin katmanlı PDF’de de MarkItDown sıfır Markdown başlık işareti üretti. Bir PDF, semantik başlık etiketleri taşımaz; MarkItDown da font boyutundan yapı tahmini yapmaz. Sonuç: her satır gövde seviyesine düşer. Metin yakalama yüksek; yapı düz.
Bu yalnızca benim bulgum da değil. Üçüncü taraf herkese açık benchmark’lar, MarkItDown’ın PDF başlık hiyerarşisi skorunu yaklaşık 0.0, tablo doğruluğunu ise yaklaşık 0.27 olarak ölçüyor; bu, Docling’in TableFormer tabanlı 0.88 skorunun oldukça altında. Bkz. MarkItDown vs Docling vs Marker karşılaştırması ve READoc benchmark. Benim testlerim onlarınkini doğruluyor; bu da kanıt açısından bir artı, çünkü benim sayılarım dış bir kaynakla örtüşüyor. Aynı benchmark’ların aktardığı diğer tarafta ise MarkItDown’ın Docling’e göre yaklaşık 100 kat daha hızlı çalışması var; bu da benim bazı belgelerde dakikalar değil saniyelerle ölçtüğüm sürelerle uyumlu. Çıkarım şu: MarkItDown size temiz ve hızlı PDF metni verir; PDF’nin yapısını vermez. Başlıklar ve tablolar mutlaka korunmalıysa, Docling ya da Marker gibi bir düzen modeli aracı doğru katmandır.
Tablolar: içerik hep korunur, yapı ise bazen bozulur
Tablolar, “metin kayboldu mu?” ile “veri kullanılabilir mi?” sorularının ayrıldığı yer. Bu yüzden tam olarak hangi tablo biçimlerinin sağlam kaldığını, hangilerinin bozulduğunu görmek için 13 vakalık bir matris kurdum — her vaka için bir <table>, hepsi çalıştırmadan önce hazırlanmış manifest’e göre puanlandı.
Başlık şu: MarkItDown hiçbir tabloda içerik kaybetmedi. 13 vakanın tamamında önceden kayıtlı token’ların %100’ü korundu. Ancak yapısal doğruluk üçe ayrıldı. On üç vakanın yedisi düzgün bir GFM grid olarak çıktı (düz, header-colspan, 24 sütun genişlik, headersız, boş hücreli, block-in-cell ve sağdan sola Arapça). Dördü bozuldu; çünkü Markdown’un span’li hücre kavramı yok, bu yüzden rowspan, colspan ve bozuk kaynaklar kısa satırlar üretiyor. İkisi ise açıkça kırık.
Bu iki kırığın adı konmalı. İç içe tablo (bir <td> içinde <table>) satır içine düzleştiriliyor, kendi pipe ve ayırıcı satırını üst hücreye döküyor ve 14 “sütunluk” çöp bir satır oluşturuyor. Hücre içinde düz | karakteri de kaçırılmıyor — a | b hücre metni iki sütuna dönüşüyor, x || y ise üç sütun oluyor — yani iki sütunlu bir tablo, iki, üç ve dört sütunlu satırlar çıkarabiliyor ve aşağı akıştaki herhangi bir Markdown ayrıştırıcısı yanlış sınırları okuyor. İlginç biçimde, hücre içindeki yıldız ve backtick’ler kaçırılıyor; pipe karakterleri ise kaçırılmıyor. Bunun temel nedeni, MarkItDown’ın HTML yolunun markdownify’ın varsayılan tablo işleme mantığını kullanması; özel alt sınıfın bağlantılar, görseller ve başlıklar için override yapıp tablo hücreleri için yapmaması. Aynı pipe kaçırma hatası sınıfı, CSV dönüştürücü için açık bir issue olarak da mevcut (#2019); ancak bu düzeltme, benim test ettiğim HTML yoluna dokunmuyor.
Daha ince olan — bir veri mühendisinin özellikle görmesini isteyeceğim bulgu — rowspan konusu. t03 vakası yalnızca bozulmakla kalmıyor; veriyi sessizce yanlış hizalıyor. rowspan=2 olan etiket (“Fruit”) bir kez yazılıyor ve altındaki satır kısa iki sütunlu bir satıra dönüşüyor (| Banana | 8 |); bu yüzden “Banana”, Item yerine Group sütununun altına kayıyor. Token’ların hepsi yerinde. Ama naif bir şekilde “ikinci sütunu oku” diyen tüketici yanlış değer alıyor. Bu, metin korundu testinden geçen ama veri setini sessizce bozabilen türden bir hata.
Span sınırlaması zaten bilinen ve takip edilen bir tasarım kısıtı (#1211, #1248) — düz bir GFM pipe grid, span’leri ve iç içe yapıları gerçekten temsil edemez, bu yüzden dönüştürücü yapıdan çok içerik tamlığını tercih ediyor. Yine de olumlu davranışlar da var: headersız tablolar için varsayılan boş bir başlık satırı oluşturuluyor (böylece veri sessizce başlığa dönüşmüyor), boş hücreler korunuyor ve <caption> tablo üstünde metin satırı olarak kalıyor.
Kurulum ve başlangıç: “hafif araç” söyleminin size söylemediği vergi
Beni en çok şaşırtan şey buydu; “hafif Python aracı” anlatımı burada sessizce fazla vaat ediyor.
İlk olarak, pip install 'markitdown[all]' komutunu çalıştırmayın. Python 3.14 üzerinde bu komut sessizce sizi markitdown 0.0.2 sürümüne geri götürüyor — iki yıllık eski bir sürüm — ve bunu temiz bir sanal ortamda canlı olarak tekrar ürettim. Sebebi pin’lerde ortaya çıkıyor: pip install 'markitdown[all]==0.1.6' hata veriyor; çünkü [all] ekstra paketi youtube-transcript-api~=1.0.0 sürümünü sabitliyor ve PyPI’daki o aralıktaki tüm sürümler Python <3.14 ile sınırlandırılmış durumda, 3.14 ile uyumlu olan tek sürümler ise bu pin’in dışında kalıyor. Bu yüzden resolver, bağımlılıklarını karşılayabildiği son sürüme kadar geri dönüyor. Bu durum açık upstream issue (#2179) ile de örtüşüyor. Çözüm basit: sürümü sabitleyin ve ekstra paketleri tek tek yükleyin: pip install 'markitdown==0.1.6', ardından pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Bunların her biri sorunsuz çözülüyor; zehirli pin yalnızca birleşik [all] paketinde var. (Bu tuzak Python sürümüne bağlıdır — Python 3.13 veya daha eski sürümlerde bu engel devreye girmeyebilir, dolayısıyla [all] farklı şekilde çözülebilir.)
İkinci konu, paket boyutu. Çekirdek kurulum 161 MB (13 MB boş venv + 148 MB) ediyor. Bunun içinde onnxruntime (73 MB) ve numpy (34 MB) birlikte 107 MB tutuyor — çekirdek yükün tamamının %66’sı — ve ikisi de tek bir zorunlu bağımlılık tarafından çekiliyor: magika, Google’ın dosya türü algılayıcısı. Yani bir metin dönüştürücü, tek bir belge ekstrası eklemeden önce temel kurulumuna 73 MB’lık bir ONNX çıkarım çalışma zamanı ekliyor. Belge ekstralarını da eklediğinizde sanal ortam 310 MB’a ulaşıyor. Bu, headless browser yığınına göre çok daha hafif; ama “bir pip install yapıp geçeceğim” türü küçük bir araç bekliyorsanız, yanınızda bir ONNX runtime taşıdığınızı bilin.
Üçüncüsü — ve benim tüm test grubumda yeni bulgu eşiğini geçen tek sonuç bu — temiz bir kurulumdan sonra bile import markitdown bu makinede yaklaşık 3,35 saniye sürüyor. Maliyetin neredeyse tamamı import aşamasında oluşuyor: markitdown._markitdown, tüm dönüştürücü kayıt defterini eagerly import ediyor (toplam 2,56 s, yani sürenin %76’sı) ve bu süreç pandas’ı (594 ms, XLSX dönüştürücü üzerinden), python-pptx’i (427 ms), magika’yı (354 ms) ve requests’i (270 ms) yüklüyor — siz bu formatların hiçbirini dönüştürmeseniz bile. Uzun süre çalışan bir servis için bu maliyet zamanla amorti olur ve önemsizleşir. Ama bir CLI çağrısı ya da serverless cold start için bu, proses başına gerçek bir vergi; “hafif araç” etiketi bunu bekletmiyor. (Adil bir not: Bu, tek profilli bir çalıştırmadır; çoklu çalıştırmadan oluşan bir dağılım değil, tek gözlem olarak değerlendirilmelidir.)
Ölçek: çökmez, ama PDF’ler için CPU, tablolar için RAM bütçesi ayırın
Dört büyük örneği, önceki çalıştırmanın tepe belleğini kirletmemesi için her birini ayrı bir süreçte çalıştırarak test ettim. Hiçbiri çökmedi. Ama maliyet profili dengesiz.
| Konu | Girdi | Çıktı karakteri | Ortanca süre | Tepe RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (492 sayfalık PDF) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50,000 satır × 8 sütun | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (~15 sayfalık PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 satır × 64 sütun | 46 KB | 120,129 | 2.9 s | +22 MB |
492 sayfalık NIST PDF ortanca 192,5 saniye sürdü — yaklaşık 3,2 dakika ya da sayfa başına 0,39 s — çünkü pdfplumber her sayfada kelime-konumlu form algılama yapıyor. Tepe RSS yalnızca +40 MB arttı; yani sorun bellek değil CPU. 15 sayfalık arXiv PDF bile kendi izole sürecinde 12,6 saniye sürdü; bu, aynı dosyanın belge paketimde sıcak çalışmada gördüğü 3,7 saniyenin yaklaşık 3,4 katı. Bu fark, soğuk süreç maliyeti ve per-page iş yükünün asıl belirleyici olduğunu doğruluyor; ham dosya boyutu değil. O PDF için tek taşınabilir sayı istiyorsanız, izole edilmiş 12,6 saniyeyi kullanın.
Elektronik tablo yolu ise darboğazı değiştiriyor. 2,1 MB’lık, 50.000 satırlı XLSX, +374 MB tepe RSS’ye ve 3,7 milyon çıktı karakterine ulaştı; çünkü dönüştürücü tüm sayfayı belleğe alıp tek bir büyük Markdown string’i oluşturuyor. Pratik tavsiye açık: büyük PDF’ler için dakika düzeyinde CPU bütçesi ayırın; büyük elektronik tablolar için yüzlerce MB RAM düşünün. Bunlar macOS arm64 ve Python 3.14 üzerinde tek makineden alınmış sayılar; sayfa başı ve satır başı sabitler platforma bağlıdır — ama transfer olan şey, şekil: PDF yavaş ve CPU ağırlıklı, XLSX bellek yüklü ve hiçbir şey çökmez.
Thunderbit burada nereye oturur — ve nerede oturmaz?
Web Veri Çıkarma için Thunderbit’i Deneyin
Bu karşılaştırma kolayca abartılabilir; o yüzden sınırı dikkatli çizeyim. MarkItDown ve Thunderbit komşu problemleri çözer, aynı problemi değil.
MarkItDown elinizde zaten olan dosyaları dönüştürür. Thunderbit ise önce sayfayı getirir. Thunderbit’in /distill endpoint’i canlı bir web sayfasını temiz, LLM’e hazır Markdown’a çevirir — MarkItDown’da olmayan JS render, anti-bot önlemleri ve dinamik içerik desteğiyle — ve /extract endpoint’i yalnızca ham Markdown değil, şemaya uyan yapılandırılmış JSON döndürür. Geliştiriciler için bu tek bir AI motoru üzerinden API (POST /distill / POST /extract), bir MCP sunucusu ve CLI (npx @thunderbit/thunderbit-cli) olarak sunulur; aynı motor, 100.000+ kullanıcılı eklentinin arkasında da çalışır.
Yani yalnızca bir noktada örtüşüyorlar — ikisi de “LLM’e hazır Markdown” üretebilir — ama girdi alanları farklı: Thunderbit’in distill’i açık web üzerindeki bir URL alır, MarkItDown ise yerel dosya alır. Birbirinin yerine geçmezler; öyleymiş gibi davranmayacağım. Gerçekçi stack ikisini birlikte kullanır: web’i Thunderbit (veya Firecrawl tarzı bir servis) ile getirip tararsınız; sonra elinizdeki yerel karışık belgeleri — PDF’ler, sunumlar, elektronik tablolar — MarkItDown ile standartlaştırırsınız. Biri ağı yönetir; diğeri dosya dolabını.
Artılar ve eksiler
Güçlü yönler
- Temiz HTML’de tam gövdeyi korur (4/4 sayfa), başlık ağacını ve bağlantıları sadakatle saklar
- PDF/DOCX metin yakalama oranı yüksektir (arXiv 7/7 kontrol, Bitcoin 6/6) ve kendi Office örneklerinde sessiz içerik kaybı yoktur
- Office Math denklemlerini LaTeX olarak korur — gerçek bir niş avantaj
- 492 sayfalık PDF ve 50 bin satırlık XLSX’e kadar hiçbir ölçekte çökmedi
- Kullanımı kolay: CLI,
convert(), stdin pipe, isteğe bağlı MCP sunucusu - MIT lisanslı, Microsoft tarafından aktif olarak sürdürülüyor, issue takibi canlı
Zayıf yönler
- Gereksiz sayfa kalıntılarını korur — Wikipedia’da %12,4’e kadar çerçeve satırı; makale çıkarıcısı değildir
- Tablolar span, nesting ve hücre içi pipe’larda bozulur (13’ün 2’si kırık, 13’ün 4’ü bozuk), rowspan veriyi sessizce yanlış sütuna kaydırabilir
- Taranmış/görüntü tabanlı PDF’ler OCR olmadan ve hata vermeden boş çıktı üretir
- PDF çıktısında başlık yapısı yoktur (halk benchmark’larıyla uyumlu)
- 73 MB ONNX runtime taşıyan 161 MB çekirdek kurulum; soğuk başlangıçta ~3,35 s
[all]ekstra paketi Python 3.14’te sessizce iki yıllık 0.0.2 sürümüne geri döner
Kimler kullanmalı, kimler kullanmamalı?
Elinizdeki karışık yerel belgeleri — Word, Excel, PowerPoint, metin katmanlı PDF’ler — bir LLM pipeline’ı için Markdown’a standardize etmek istiyorsanız ve yapıdan çok eksiksiz metin sizin için önemliyse, MarkItDown tam size göre. Bir batch işinde son aşama dönüştürücü olarak, modele temiz metin beslemek için hızlı, sadık ve ücretsiz.
Şunlardan biri sizin işinizse, ya atlayın ya da başka bir şeyle birlikte kullanın: web sayfasından yalnızca ana makaleyi istiyorsanız (readability ya da Firecrawl tarzı bir araç kullanın); bir PDF’nin başlıkları ve tabloları bozulmadan kalsın istiyorsanız (Docling ya da Marker alanı); ya da girdileriniz OCR gerektiren taranmış belgeler içeriyorsa (Azure backend ya da bambaşka bir araç gerekir). Ve eğer bir scraper — yani web’i çekip tarayan bir araç — arıyorsanız, bu o değil.
Scraper benzeri bir değerlendirme rubriğiyle yaptığım ön puanlama MarkItDown’a 60/100 veriyor; bu düşük toplam, bir dönüştürücüyü crawler testine sokmanın doğal sonucu. Kendi alanında metin sadakati yüksek; zayıf noktaları yapısal (tablolar, PDF başlıkları) ve paketleme (boyut, import, [all] tuzağı), metin kalitesi değil. Onu olduğu gibi — dosyadan Markdown’a dönüştürücü — değerlendirdiğinizde, üretime bağlamadan önce bilmeniz gereken birkaç keskin kenarı olan sağlam ve iyi bakılan bir araç.
Sık sorulan sorular
MarkItDown bir web scraper mıdır?
Hayır. İçinde crawler, JavaScript render, link takibi ya da sayfalama yoktur. Zaten elinizde olan dosya ve belgeleri — PDF, DOCX, XLSX, PPTX, görseller, HTML — Markdown’a dönüştürür. Canlı web sayfalarını çekip taramak istiyorsanız, Thunderbit veya Firecrawl gibi bir scraping aracı gerekir; MarkItDown ise alınan ya da yerel dosyaları temiz Markdown’a çeviren sonraki adımdır.
Neden pip install markitdown[all] eski bir sürüm kuruyor?
Python 3.14’te [all] ekstra paketi youtube-transcript-api~=1.0.0 sürümünü sabitler; o aralıktaki tüm sürümler Python 3.14 altıyla sınırlıdır. Resolver bu pin’i karşılayamaz ve sessizce markitdown 0.0.2’ye geri döner; bu da iki yıllık eski bir sürümdür. Çözüm, sürümü sabitleyip ekstra paketleri ayrı ayrı kurmaktır: pip install 'markitdown==0.1.6', ardından pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Bu konu issue #2179 olarak takip ediliyor.
MarkItDown taranmış PDF’lerde OCR yapıyor mu?
Varsayılan kurulumda hayır. PDF yolu yalnızca metin çıkarır; bu yüzden metin katmanı olmayan görüntü tabanlı bir PDF boş bir string döndürür — hata yok, uyarı yok. OCR için opsiyonel Azure Document Intelligence backend’i veya bir eklenti gerekir; bunların hiçbiri varsayılan olarak gelmez. Bu, uzun süredir takip edilen bir boşluk (issue #1268).
MarkItDown tabloları ne kadar iyi işler?
İçerik açısından çok iyi — benim 13 vakalık testimde her tabloda içeriğin %100’ünü korudu. Yapısal olarak ise şekle bağlı: basit, geniş, headersız ve boş hücreli tablolar temiz GFM grid olarak çıkar; ancak rowspan ve colspan bozulur (rowspan veriyi yanlış sütuna sessizce kaydırabilir), iç içe tablolar çöp satırlara düzleşir ve hücre içindeki düz pipe karakterleri kaçırılmaz. Markdown’un düz tablo formatı zaten span’leri ve nesting’i temsil edemez.
MarkItDown büyük belgeler için yeterince hızlı mı?
Büyük dosyalarda çökmez, ama kaynak bütçesini dosya türüne göre ayırın. 492 sayfalık bir PDF yaklaşık 3,2 dakika sürdü (yaklaşık 0,39 s/sayfa); çünkü her sayfada form algılama yapıyor ve CPU ağırlıklı. 50.000 satırlık bir elektronik tablo yaklaşık bir dakikada tamamlandı ama +374 MB RAM kullandı; çünkü tüm Markdown string’ini bellekte oluşturuyor. Büyük PDF’ler için dakika düzeyinde CPU, büyük tablolar için yüzlerce MB RAM planlayın.
Web Veri Çıkarma için Thunderbit’i Deneyin Get Started Free
