MarkItDown sering banget dimasukkan ke kategori web scraper, dan itu keliru. Tidak ada crawler, tidak ada mesin JavaScript, dan tidak ada cara untuk mengambil URL lalu membersihkan boilerplate di dalamnya. Yang dilakukan alat ini adalah mengambil byte yang sudah kamu punya β PDF, dokumen Word, spreadsheet, slide deck β lalu mengubah semuanya menjadi Markdown yang bisa dibaca model bahasa.
Saya menghabiskan beberapa minggu menguji MarkItDown dari Microsoft pada serangkaian dokumen nyata di satu Mac, memberi skor pada setiap tabel terhadap manifest yang saya tulis sebelum pengujian, dan mengukur waktu setiap konversi. Versi singkatnya: untuk input yang bersih, alat ini cepat dan cukup akurat; kemasannya menyembunyikan runtime machine learning 73 MB yang mungkin tidak kamu minta; dan tabelnya bisa rusak dengan cara yang lolos dari cek "apakah teksnya masih ada?" tetapi gagal pada cek "apakah datanya ada di kolom yang benar?". Berikut gambaran lengkap beserta angkanya.
Apa sebenarnya MarkItDown itu
MarkItDown adalah utilitas Python dari Microsoft yang mengonversi file dan dokumen Office menjadi Markdown yang dioptimalkan untuk LLM. Arahkan ke PDF, .docx, .xlsx, .pptx, gambar, file HTML, atau beberapa format lain, lalu hasilnya adalah Markdown. Ada tiga cara untuk memakainya: lewat CLI (markitdown file.pdf -o out.md, atau dari stdin), lewat Python API (MarkItDown().convert(...)), dan server MCP opsional untuk workflow agen.
Hal paling penting untuk dipahami adalah apa yang tidak dilakukan alat ini, karena README juga tidak mengklaimnya dan saya sudah memastikannya lewat pengujian: tidak ada crawling, tidak ada rendering JS, tidak ada mengikuti link, tidak ada pagination, dan tidak ada ekstraksi konten utama ala readability. Ini adalah konverter satu dokumen penuh. Kamu membawa file-nya; alat ini menstandarkan isinya. Perbedaan tunggal ini menentukan apakah alat ini cocok masuk ke stack kamu atau tidak, jadi saya akan terus kembali ke poin ini.
Repositori ini sendiri sangat besar kalau dilihat dari metrik kosmetik GitHub β 165.282 bintang dan 11.790 fork per pertengahan Juli 2026, berlisensi MIT, dengan rilis terbaru (v0.1.6) keluar pada 2026-05-26. Namun angka bintang itu lebih mencerminkan antusiasme terhadap tool LLM dari organisasi Microsoft daripada sinyal kematangan bagian konversinya. Ada juga 833 issue terbuka, dan beberapa di antaranya penting untuk kamu ketahui sebelum memasang alat ini (lebih lanjut di bawah).
HTML ke Markdown: cepat dan lengkap, termasuk boilerplate
Karena bagian lain dari seri ulasan scraper saya memakai empat fixture web yang sama, saya memberi MarkItDown file HTML lokal yang identik β bukan untuk menilainya sebagai scraper, melainkan untuk melihat seberapa bagus konversi HTML-ke-Markdown-nya. Pada halaman yang ditandai dengan baik, hasilnya memang bagus.
Keempat halaman berhasil dikonversi dengan instalasi inti tanpa tambahan apa pun, dan semua probe isi utama tetap lolos. Artikel Wikipedia "Web scraping" (226 KB) keluar dengan struktur heading yang mirip aslinya β satu h1, tujuh h2, dua belas h3, sesuai struktur bagian artikel sebenarnya β dan 418 tautan dipertahankan sebagai [teks](url) yang benar. Tabel statistik hoki 26Γ9 pada halaman Scrape This Site forms berubah menjadi tabel pipe GFM yang rapi dengan 27 baris (header + separator + 26 baris data), termasuk sel kosongnya. Kecepatan juga bukan masalah pada kasus ini: median 48 ms untuk halaman kutipan yang kecil hingga 352 ms untuk halaman Wikipedia 226 KB.
Nah, ini catatannya, dan ini memang keputusan desain, bukan bug. MarkItDown tidak membuang boilerplate. Ia mengonversi seluruh <body>, jadi elemen-elemen chrome situs ikut terbawa β dan residunya meningkat seiring banyaknya chrome di halaman tersebut.
| Halaman | Karakter output | Heading (h1/h2/h3) | Tautan | Baris chrome situs |
|---|---|---|---|---|
| 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) |
Pada homepage Books yang hampir bersih dari chrome, 0,6% baris output adalah chrome. Di Wikipedia, angkanya 12,4% β 42 dari 338 baris non-kosong berisi hal seperti "jump to content," "toggle the table of contents," "22 languages," "retrieved from," serta footer cookie dan lisensi. Banner pemeliharaan Wikipedia seperti ("This article needs additional citations") bahkan dirender setia menjadi tabel pipe dua kolom, dan dari situlah sembilan baris tabel berasal pada halaman yang sebenarnya tidak punya tabel data.
Semua itu bukan berarti MarkItDown bekerja salah. Ini konverter satu dokumen penuh, bukan extractor readability: HTML-ke-Markdown yang setia adalah pekerjaan yang berbeda dari ekstraksi artikel bersih. Alat seperti Trafilatura dan Firecrawl bertujuan hanya mengembalikan konten utama; MarkItDown mengembalikan seluruh halaman. Di balik layar, _html_converter.py membuang <script> dan <style>, lalu menyerahkan seluruh body ke library markdownify β tidak ada heuristik konten utama di jalurnya. Kalau kamu hanya ingin artikel, ini adalah lapisan yang salah.
Medan utamanya: PDF, DOCX, XLSX, PPTX
Dokumen adalah area yang memang ditujukan untuk MarkItDown. Saya mengujinya pada file publik nyata β makalah arXiv dengan text layer, whitepaper Bitcoin, PDF hasil scan berbasis gambar yang saya render tanpa teks sama sekali, serta file DOCX/XLSX/PPTX dari test suite MarkItDown sendiri (diberi UUID agar saya bisa mendeteksi kehilangan konten secara diam-diam).
| Dokumen | Input | Karakter output | Probe | Waktu median | Catatan |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF dengan text layer) | 2,2 MB | 40,174 | 7/7 | 3,7 dtk (warm) | judul, "Transformer", "BLEU", "References" semuanya ada |
| Whitepaper Bitcoin (PDF 9 hlm) | 184 KB | 22,485 | 6/6 | 1,4 dtk | "Satoshi Nakamoto", "proof-of-work", "Conclusion" ada |
| PDF hasil scan (tanpa text layer) | 89 KB | 0 | 0/4 | 15 ms | output kosong, tanpa error, tanpa OCR |
| DOCX (test.docx) | 136 KB | 4,651 | β | 70 ms | heading + tabel GFM; UUID tertanam tetap ada |
| DOCX dengan persamaan | 15 KB | 240 | β | 101 ms | Office Math dipertahankan sebagai LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | β | 57 ms | setiap sheet β ## SheetName + tabel GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | β | 52 ms | penanda nomor slide, tabel, chart β tabel |
Recall teks pada PDF dengan text layer sangat bagus β 7 dari 7 probe yang sudah saya tetapkan sebelumnya pada makalah arXiv "Attention Is All You Need" dan 6 dari 6 pada whitepaper Bitcoin β dan tidak satu pun file Office kehilangan sentinel UUID, jadi tidak ada kehilangan konten diam-diam pada fixture regresi milik maintainer sendiri. Satu kemenangan kecil yang menarik: jalur DOCX (melalui mammoth) mempertahankan persamaan Office Math sebagai LaTeX, mengubah equations.docx menjadi matematika $$...$$ yang valid. Kalau kamu memberi dokumen Word penuh rumus ke LLM, ini adalah kekuatan nyata, meski sangat spesifik, yang tidak saya temukan dibahas di tempat lain.
Ada dua temuan di area ini yang pantas mendapat perhatian khusus, karena keduanya paling mungkin jadi masalah buat kamu.
PDF hasil scan yang menghilang
Berikan MarkItDown PDF berbasis gambar tanpa text layer, dan hasilnya adalah string kosong. Nol karakter, tanpa exception, tanpa peringatan β selesai sekitar 15 ms karena memang tidak ada yang bisa diekstrak. Jalur PDF MarkItDown hanya melakukan ekstraksi teks (di balik layar memakai pdfminer dan pdfplumber), dan tidak menyertakan OCR di instalasi inti maupun extra pip apa pun.
Ini penting dalam proses batch. Developer yang memproses folder PDF yang sebagian merupakan scan akan mendapat hasil kosong diam-diam untuk file-file itu tanpa sinyal bahwa ada yang dilewati. Saya memastikan fixture-nya bukan rusak dengan menjalankan extract_text dari pdfminer langsung pada file tersebut β hasilnya nol karakter yang di-strip, tidak ada text layer, terkonfirmasi β jadi output kosong memang perilaku nyata MarkItDown pada scan sungguhan. Ini mereproduksi gap OCR fallback yang sudah lama terbuka (#1268) dan sudah lama dilacak di upstream. Jalur yang terdokumentasi adalah backend opsional Azure Document Intelligence atau plugin; keduanya tidak ada di instalasi default.
PDF keluar sebagai teks datar, bukan struktur
Pada kedua PDF dengan text layer, MarkItDown tidak menghasilkan satu pun penanda heading Markdown. PDF tidak membawa tag heading semantik, dan MarkItDown tidak menebak struktur dari ukuran font, jadi setiap baris jatuh ke level body. Recall teksnya tinggi; strukturnya datar.
Ini bukan cuma hasil saya. Benchmark publik pihak ketiga memberi skor sekitar 0,0 untuk hierarki heading PDF MarkItDown dan sekitar 0,27 untuk fidelitas tabelnya, jauh di bawah 0,88 milik Docling yang didukung TableFormer (lihat perbandingan MarkItDown vs Docling vs Marker dan benchmark READoc). Fixture saya mereproduksi hasil mereka, dan itu justru memperkuat bukti β angka saya sejalan dengan sumber eksternal. Trade-off yang juga dilaporkan benchmark tersebut adalah MarkItDown berjalan kira-kira 100Γ lebih cepat daripada Docling, dan itu cocok dengan hasil saya yang hitungan detik, bukan menit, pada dokumen yang tool berbasis layout model prosesnya dalam menit. Intinya: MarkItDown memberi kamu teks PDF yang bersih dan cepat; ia tidak memberi kamu struktur PDF. Kalau heading dan tabel harus tetap utuh, tool berbasis layout model seperti Docling atau Marker adalah lapisan yang tepat.
Tabel: konten selalu selamat, strukturnya belum tentu
Tabel adalah tempat di mana pertanyaan "apakah teksnya masih ada?" dan "apakah datanya masih bisa dipakai?" berpisah, jadi saya membuat matriks 13 kasus β satu <table> per kasus, masing-masing dinilai terhadap manifest yang ditulis sebelum pengujian β untuk memetakan bentuk mana yang bertahan dan mana yang rusak.
Kesimpulan utamanya: MarkItDown tidak pernah kehilangan konten tabel. Semua 13 kasus mempertahankan 100% token yang sudah saya daftarkan sebelumnya. Namun fidelitas strukturalnya terbagi tiga. Tujuh dari 13 menghasilkan grid GFM yang rapi (plain, header-colspan, lebar 24 kolom, headerless, empty-cells, block-in-cell, dan Arab kanan-ke-kiri). Empat menjadi berantakan, karena Markdown tidak punya konsep sel yang di-span, jadi rowspan, colspan, dan sumber yang malformed akan menghasilkan baris pendek. Dua lagi benar-benar rusak.
Dua kerusakan itu layak disebut. Nested table (sebuah <table> di dalam <td>) diratakan inline, sehingga pipe dan baris separator miliknya masuk ke sel induk dan menghasilkan baris sampah berkubah 14 "kolom". Dan karakter literal | di dalam sel tidak di-escape β teks sel a | b menjadi dua kolom, x || y menjadi tiga β jadi tabel dua kolom bisa memunculkan baris dua, tiga, dan empat kolom, dan parser Markdown downstream akan membaca batas yang salah. Menariknya, tanda bintang dan backtick di dalam sel memang di-escape; pipe saja yang tidak. Akar masalahnya adalah jalur HTML MarkItDown memakai penanganan tabel default dari markdownify, dan subclass kustomnya hanya menimpa link, image, dan heading, bukan sel tabel. Bug escape pipe yang sama juga muncul sebagai issue terbuka untuk converter CSV (#2019), meski perbaikan itu tidak menyentuh jalur HTML yang saya uji.
Yang lebih halus β temuan yang paling ingin saya tunjukkan ke data engineer β adalah rowspan. Kasus t03 bukan hanya jadi berantakan; ia diam-diam menggeser data. Label rowspan=2 ("Fruit") hanya muncul sekali, lalu baris di bawahnya menjadi baris pendek dua kolom (| Banana | 8 |), sehingga "Banana" jatuh di bawah kolom Group, bukan Item. Semua token ada. Konsumen yang naif dan hanya membaca kolom kedua akan mendapatkan nilai yang salah. Ini jenis bug yang lolos dari cek keberadaan teks dan diam-diam merusak dataset.
Keterbatasan span itu sendiri adalah batasan desain yang sudah diketahui dan dilacak (#1211, #1248) β grid pipe GFM yang datar memang tidak bisa merepresentasikan span atau nesting, jadi konverter menukar struktur demi kelengkapan konten. Ada juga perilaku yang bagus: tabel tanpa header mendapat baris header kosong sintetis (jadi tidak ada data yang diam-diam naik menjadi header), sel kosong tetap dipertahankan, dan <caption> tetap muncul sebagai baris teks di atas tabel.
Instalasi dan startup: pajak yang tidak diberitahukan oleh utilitas "ringan"
Tidak ada hal yang lebih mengejutkan saya di sini, dan inilah bagian ketika framing "utilitas Python ringan" diam-diam terlalu menjanjikan.
Pertama, jangan jalankan pip install 'markitdown[all]'. Pada Python 3.14, perintah ini diam-diam mundur ke markitdown 0.0.2 β rilis berumur dua tahun β yang saya reproduksi langsung di venv baru. Saat dipin, penyebabnya terlihat: pip install 'markitdown[all]==0.1.6' gagal karena extra [all] mengunci youtube-transcript-api~=1.0.0, dan di PyPI saat ini semua build dalam rentang itu dibatasi untuk Python <3.14, sedangkan build yang kompatibel dengan 3.14 justru berada di luar pin tersebut. Akibatnya resolver mundur jauh ke rilis terakhir yang dependensinya masih bisa dipenuhi. Ini sejalan dengan issue upstream terbuka (#2179). Solusinya sederhana β pin versinya lalu pasang extra satu per satu: pip install 'markitdown==0.1.6', lalu pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Masing-masing akan ter-resolve dengan bersih; hanya bundle [all] yang membawa pin bermasalah itu. (Jebakan ini bergantung pada versi Python β pada Python 3.13 atau lebih lama, pembatas tersebut mungkin tidak kena, jadi [all] bisa ter-resolve berbeda.)
Kedua, jejak ukurannya. Instalasi inti mencapai 161 MB (venv kosong 13 MB plus 148 MB). Dari total itu, onnxruntime (73 MB) dan numpy (34 MB) bersama-sama menyumbang 107 MB β 66% dari seluruh footprint inti β dan keduanya dibawa oleh satu dependensi keras: magika, pendeteksi tipe file berbasis ML milik Google. Jadi sebuah konverter teks membawa runtime inferensi ONNX 73 MB pada instalasi dasarnya bahkan sebelum kamu menambahkan extra dokumen apa pun. Setelah extra dokumen dipasang, venv naik menjadi 310 MB. Ini masih jauh lebih ringan daripada stack headless browser, tetapi kalau kamu mengira cukup pip install lalu selesai sebagai utilitas mikro, ketahuilah bahwa runtime ONNX ikut terbawa.
Ketiga β dan ini satu-satunya temuan di seluruh paket saya yang lolos semua cek kebaruan yang saya jalankan β bahkan setelah instalasi bersih, import markitdown memakan sekitar 3,35 detik di mesin ini. Biayanya hampir seluruhnya terjadi saat import: markitdown._markitdown memuat seluruh registry konverter secara eager (total kumulatif 2,56 detik, 76% dari total), yang menarik pandas (594 ms, lewat konverter XLSX), python-pptx (427 ms), magika (354 ms), dan requests (270 ms) β entah kamu mengonversi format-format itu atau tidak. Untuk layanan jangka panjang, biaya import ini akan teramortisasi dan tidak relevan. Untuk panggilan CLI atau cold start serverless, ini adalah pajak nyata per proses yang tidak kamu duga dari label "utilitas ringan". (Catatan adil: ini satu profiling run, diperlakukan sebagai satu observasi, bukan distribusi multi-run.)
Skala: tidak crash, tetapi siapkan CPU untuk PDF dan RAM untuk spreadsheet
Saya mendorong empat subjek besar melewati alat ini, masing-masing dalam proses terpisah agar penggunaan memori puncak tidak tercemar oleh run sebelumnya. Tidak ada yang crash. Namun profil biayanya timpang.
| Subjek | Input | Karakter output | Waktu median | Ξ RSS puncak |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF 492 halaman) | 5,9 MB | 1,625,365 | 192,5 dtk | +40 MB |
| XLSX 50,000 baris Γ 8 kolom | 2,1 MB | 3,722,955 | 62,1 dtk | +374 MB |
| arXiv 1706.03762 (~15 halaman PDF) | 2,2 MB | 40,174 | 12,6 dtk | +25 MB |
| XLSX 200 baris Γ 64 kolom | 46 KB | 120,129 | 2,9 dtk | +22 MB |
PDF NIST SP 800-53r5 492 halaman memakan median 192,5 detik β sekitar 3,2 menit, atau 0,39 dtk/halaman β karena pdfplumber menjalankan deteksi form berbasis posisi kata pada setiap halaman. RSS puncak tetap +40 MB, jadi ini terbatas pada CPU, bukan memori. Bahkan PDF arXiv 15 halaman memakan 12,6 detik dalam proses terisolasi sendiri, sekitar 3,4Γ dari 3,7 detik yang ditunjukkannya saat warm di suite dokumen saya. Selisih itu adalah biaya proses dingin, dan ini menegaskan bahwa kerja per halaman adalah pendorong utamanya, bukan ukuran byte mentah. Kalau kamu ingin satu angka yang bisa dipakai untuk PDF itu, pakailah 12,6 detik yang terisolasi.
Jalur spreadsheet membalik bottleneck-nya. XLSX 2,1 MB berisi 50.000 baris melonjak menjadi +374 MB RSS puncak (dan 3,7 juta karakter output) karena konverter memuat seluruh sheet lalu membangun satu string Markdown besar. Jadi panduan praktisnya tegas: untuk PDF besar, siapkan CPU dalam hitungan menit; untuk spreadsheet besar, siapkan ratusan MB RAM. Ini adalah angka satu mesin di macOS arm64 dan Python 3.14, dan konstanta per halaman serta per baris memang spesifik platform β tetapi bentuk umumnya (PDF lambat dan berat CPU, XLSX berat di memori, tidak ada crash) adalah bagian yang tetap berlaku.
Di mana Thunderbit cocok β dan di mana tidak
Coba Thunderbit untuk Ekstraksi Data Web
Ini satu-satunya perbandingan yang mudah untuk dilebih-lebihkan, jadi saya akan membatasi garisnya dengan hati-hati. MarkItDown dan Thunderbit menyelesaikan masalah yang berdekatan, bukan yang sama.
MarkItDown mengonversi file yang sudah kamu miliki. Thunderbit mengambil halaman terlebih dahulu. Endpoint /distill milik Thunderbit mengubah halaman web live menjadi Markdown yang bersih dan siap untuk LLM β menangani rendering JS, anti-bot, dan konten dinamis yang tidak dimiliki MarkItDown β dan endpoint /extract mengembalikan JSON terstruktur yang cocok dengan skema, bukan sekadar Markdown mentah. Buat developer, semuanya tersedia sebagai API (POST /distill / POST /extract), server MCP, dan CLI (npx @thunderbit/thunderbit-cli) dengan satu mesin AI, mesin yang sama di balik ekstensi dengan lebih dari 100.000 pengguna.
Jadi keduanya hanya bertemu di satu titik β sama-sama bisa menghasilkan "Markdown siap untuk LLM" β tetapi domain inputnya berbeda: distill Thunderbit mengambil URL di web publik, sedangkan MarkItDown mengambil file lokal. Keduanya bukan pengganti langsung, dan saya tidak akan berpura-pura begitu. Stack yang realistis memakai keduanya: ambil dan crawl web dengan Thunderbit (atau layanan bergaya Firecrawl), lalu normalisasi dokumen lokal campuran yang juga kamu miliki β PDF, deck, spreadsheet β dengan MarkItDown. Satu menangani jaringan; yang lain menangani lemari file.
Kelebihan dan kekurangan
Kelebihan
- Recall penuh pada HTML bersih (4/4 halaman), dengan tree heading dan tautan dipertahankan secara setia
- Recall teks PDF/DOCX tinggi (arXiv 7/7 probe, Bitcoin 6/6) dan tidak ada kehilangan konten diam-diam pada fixture Office milik maintainer sendiri
- Office Math dipertahankan sebagai LaTeX β kemenangan niche yang nyata
- Tidak crash pada subjek ukuran apa pun, hingga PDF 492 halaman dan XLSX 50 ribu baris
- Sangat mudah dipanggil: CLI,
convert(), piping stdin, dan server MCP opsional - Berlisensi MIT, aktif dipelihara Microsoft, dan tracker issue responsif
Kekurangan
- Mempertahankan boilerplate β hingga 12,4% baris chrome di Wikipedia; bukan extractor artikel
- Tabel rusak pada span, nesting, dan pipe di dalam sel (2/13 rusak, 4/13 berantakan), dan rowspan bisa diam-diam menggeser data ke kolom yang salah
- PDF hasil scan/gambar saja mengembalikan output kosong tanpa OCR dan tanpa error
- Output PDF tidak punya struktur heading sama sekali (sesuai benchmark publik)
- Instalasi inti 161 MB membawa runtime ONNX 73 MB; cold import sekitar 3,35 dtk
- Extra
[all]diam-diam mundur ke 0.0.2 yang berumur dua tahun pada Python 3.14
Siapa yang cocok memakainya, dan siapa yang sebaiknya tidak
Pilih MarkItDown jika kamu sedang menstandarkan tumpukan dokumen lokal campuran β Word, Excel, PowerPoint, PDF dengan text layer β menjadi Markdown untuk pipeline LLM, dan kamu lebih peduli pada kelengkapan teks daripada struktur yang tetap terjaga. Sebagai konverter last-mile dalam batch job, yang memberi model teks bersih, alat ini cepat, setia, dan gratis.
Lewati, atau pasangkan dengan alat lain, jika pekerjaan kamu termasuk salah satu dari ini: kamu hanya butuh artikel utama dari halaman web (pakai tool readability atau gaya Firecrawl); kamu membutuhkan heading dan tabel PDF tetap utuh (itu wilayah Docling atau Marker); atau input kamu termasuk dokumen hasil scan yang butuh OCR (kamu memerlukan backend Azure atau alat lain sama sekali). Dan kalau kamu mengira sedang membeli scraper β sesuatu yang mengambil dan crawl halaman β ini sama sekali bukan itu.
Skor sementara yang saya jalankan, memakai rubrik ala scraper, menempatkan MarkItDown di angka 60/100, dan total rendah itu adalah artefak dari menilai konverter dengan tes crawler. Di wilayahnya sendiri, skor fidelitas teksnya tinggi; titik lemahnya bersifat struktural (tabel, heading PDF) dan packaging (footprint, import, jebakan [all]), bukan kualitas teks. Nilailah sebagai apa adanya β konverter file ke Markdown β dan ini adalah alat yang solid, terawat, dengan beberapa sisi tajam yang perlu kamu ketahui sebelum memasukkannya ke produksi.
Pertanyaan yang sering diajukan
Apakah MarkItDown web scraper?
Tidak. Tidak ada crawler, tidak ada rendering JavaScript, tidak ada mengikuti link, dan tidak ada pagination. Alat ini mengonversi file dan dokumen yang sudah kamu miliki β PDF, DOCX, XLSX, PPTX, gambar, HTML β menjadi Markdown. Kalau kamu perlu mengambil dan crawl halaman web live, kamu butuh alat scraping seperti Thunderbit atau Firecrawl; MarkItDown adalah langkah setelahnya, yaitu mengubah file yang sudah diambil atau file lokal menjadi Markdown yang bersih.
Mengapa pip install markitdown[all] memasang versi lama?
Pada Python 3.14, extra [all] mengunci youtube-transcript-api~=1.0.0, dan semua build dalam rentang itu dibatasi untuk Python di bawah 3.14. Resolver tidak bisa memenuhi pin tersebut, jadi ia diam-diam mundur ke markitdown 0.0.2, rilis berumur dua tahun. Solusinya adalah pin versinya lalu pasang extra satu per satu: pip install 'markitdown==0.1.6', lalu tambahkan 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Ini dilacak sebagai issue #2179.
Apakah MarkItDown melakukan OCR pada PDF hasil scan?
Tidak pada instalasi default. Jalur PDF-nya hanya mengekstrak teks, jadi PDF berbasis gambar tanpa text layer akan menghasilkan string kosong β tanpa error, tanpa peringatan. OCR membutuhkan backend opsional Azure Document Intelligence atau plugin, dan keduanya tidak disertakan secara default. Ini adalah gap yang sudah lama dilacak (issue #1268).
Seberapa bagus MarkItDown menangani tabel?
Dari sisi konten, sangat bagus β pada tes 13 kasus saya, semuanya mempertahankan 100% konten tabel. Dari sisi struktur, tergantung bentuknya: tabel sederhana, lebar, tanpa header, dan dengan sel kosong keluar sebagai grid GFM yang bersih, tetapi rowspan dan colspan menjadi berantakan (dan rowspan bisa diam-diam menggeser data ke kolom yang salah), nested table diratakan menjadi baris sampah, dan karakter pipe literal di dalam sel tidak di-escape. Format tabel Markdown yang datar memang tidak bisa merepresentasikan span atau nesting.
Apakah MarkItDown cukup cepat untuk dokumen besar?
Tidak crash pada file besar, tetapi siapkan sumber daya sesuai jenisnya. PDF 492 halaman memakan sekitar 3,2 menit (sekitar 0,39 dtk/halaman) karena ada deteksi form per halaman, dan beban utamanya ada di CPU. Spreadsheet 50.000 baris selesai dalam kira-kira satu menit tetapi memakai +374 MB RAM karena membangun satu string Markdown besar di memori. Untuk PDF besar, rencanakan waktu CPU dalam menit; untuk spreadsheet besar, rencanakan ratusan MB RAM.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
