MarkItDown לא פעם נופל לקטגוריה של סקרייפרים, אבל בפועל זה פשוט לא מדויק. אין לו crawler, אין מנוע JavaScript, ואין לו דרך לקחת URL ולנקות ממנו את כל התוכן המיותר. מה שהוא כן עושה הוא לקחת את הבייטים שכבר יש לכם — PDF, מסמך Word, גיליון אלקטרוני, מצגת — ולהפוך את כולם ל‑Markdown שמודל שפה יכול לקרוא.
במשך כמה שבועות הרצתי את MarkItDown של Microsoft על סט של מסמכים אמיתיים במק, על מכונה אחת, השוויתי כל טבלה למניפסט שכתבתי לפני ההרצה, ומדדתי את זמני ההמרה. השורה התחתונה: בקלט נקי הוא מהיר ונאמן למקור, אבל בחבילה שלו מסתתרת סביבת ריצה של 73 MB ללמידת מכונה שלא ביקשתם, וטבלאות נוטות להישבר באופן שעובר בדיקת "האם הטקסט שרד?" אבל נכשל בדיקת "האם הנתונים נשארו בעמודה הנכונה?". הנה התמונה המלאה, עם המספרים.
מה MarkItDown באמת עושה
MarkItDown הוא כלי Python של Microsoft שממיר קבצים ומסמכי Office ל‑Markdown שמותאם ל‑LLMs. תנו לו PDF, קובץ .docx, קובץ .xlsx, מצגת .pptx, תמונה, קובץ HTML או עוד כמה פורמטים, והוא יחזיר Markdown. אפשר להשתמש בו בשלוש דרכים: CLI (markitdown file.pdf -o out.md, או דרך stdin), API של Python (MarkItDown().convert(...)), ואפשרות לשרת MCP לתהליכי עבודה של agents.
ההבדל החשוב ביותר הוא מה הוא לא עושה, כי זה גם לא מופיע ב‑README וגם אישרתי בבדיקה: אין crawling, אין רינדור של JS, אין מעבר על קישורים, אין pagination, ואין חילוץ של התוכן הראשי בסגנון readability. זה ממיר מסמך שלם. אתם מביאים את הבייטים; הוא עושה להם סטנדרטיזציה. ההבחנה הזו קובעת אם הכלי הזה בכלל מתאים לסטאק שלכם, ולכן אחזור אליה שוב ושוב.
המאגר עצמו כבד לפי מדדי היוקרה של GitHub — 165,282 כוכבים ו‑11,790 forks נכון לאמצע יולי 2026, ברישיון MIT, עם גרסה אחרונה (v0.1.6) שיצאה ב‑2026-05-26. אבל ספירת הכוכבים משקפת בעיקר את ההתלהבות הכללית מכלי LLM ואת העובדה שזה מאגר של Microsoft, ולא בהכרח בשלות של מנגנון ההמרה עצמו. יש גם 833 issues פתוחים, וחלקם חשובים לכם עוד לפני ההתקנה (עוד על זה בהמשך).
HTML ל‑Markdown: מהיר ומלא, כולל כל ה‑boilerplate
מכיוון ששאר סדרת הביקורות שלי על סקרייפרים משתמשת באותן ארבע דוגמאות מהאינטרנט, הזנתי ל‑MarkItDown את אותם קבצי HTML מקומיים — לא כדי לדרג אותו כסקרייפר, אלא כדי לבדוק עד כמה ההמרה שלו מ‑HTML ל‑Markdown טובה. בדפים עם סימון מסודר הוא באמת טוב.
כל ארבעת הדפים הומרו עם ההתקנה הבסיסית, בלי תוספות מיוחדות, וכל בדיקות תוכן הגוף שרדו. מאמר ה‑Wikipedia על "Web scraping" (226 KB) יצא עם עץ הכותרות שלו משוכפל היטב — h1 אחד, שבעה h2, ו‑12 h3, בדיוק כמו במבנה האמיתי של המאמר — ועם 418 קישורים שנשמרו בפורמט תקין של [text](url). טבלת הסטטיסטיקה של ההוקי בגודל 26×9 בעמוד Scrape This Site forms הפכה לטבלת GFM נקייה עם 27 שורות (כותרת + מפריד + 26 שורות נתונים), כולל תאים ריקים. המהירות לא הייתה בעיה: חציון של 48 ms בעמוד הציטוטים הקטן, ועד 352 ms למאמר ה‑Wikipedia בגודל 226 KB.
אבל כאן יש טוויסט, והוא החלטת עיצוב ולא באג. MarkItDown לא מסיר boilerplate. הוא ממיר את כל ה‑<body>, ולכן כל ה‑site chrome נגרר איתו — והעודף הזה גדל ככל שיש יותר chrome בדף.
| עמוד | תווים בפלט | כותרות (h1/h2/h3) | קישורים | שורות chrome של האתר |
|---|---|---|---|---|
| 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) |
בעמוד הבית של Books, שבו כמעט אין chrome, רק 0.6% משורות הפלט הן chrome. ב‑Wikipedia זה כבר 12.4% — 42 מתוך 338 שורות לא ריקות הן "jump to content", "toggle the table of contents", "22 languages", "retrieved from", וכותרות תחתית של קובצי cookie ורישוי. אפילו באנרים תחזוקתיים של Wikipedia (כמו "This article needs additional citations") נשמרים נאמנה ומעוצבים לטבלאות pipe דו‑עמודתיות, ומכאן מגיעות תשע שורות טבלה בעמוד שאין בו בכלל טבלת נתונים אמיתית.
אבל זה לא משהו ש‑MarkItDown עושה לא נכון. הוא ממיר מסמך שלם, לא מחלץ קריאה נוחה: המרה נאמנה מ‑HTML ל‑Markdown היא משימה אחרת מחילוץ נקי של מאמר. כלים כמו Trafilatura או Firecrawl שואפים להחזיר רק את התוכן הראשי; MarkItDown מחזיר את העמוד כולו. מאחורי הקלעים, הקובץ _html_converter.py מסיר <script> ו‑<style>, ואז מעביר את כל ה‑body ל‑markdownify — בלי שום היוריסטיקה של תוכן ראשי. אם אתם רוצים רק את המאמר, זה לא השכבה הנכונה.
המגרש הביתי: PDF, DOCX, XLSX, PPTX
מסמכים הם המקום שבו MarkItDown נבנה לעבוד. בדקתי אותו מול קבצים ציבוריים אמיתיים — מאמר arXiv עם שכבת טקסט, whitepaper של Bitcoin, PDF סרוק שמבוסס רק על תמונה ושאותו עיבדתי כך שלא תהיה בו שכבת טקסט בכלל, וקבצי DOCX/XLSX/PPTX מתוך חבילת הבדיקות של MarkItDown עצמו (עם UUIDs כדי שאוכל לזהות אובדן תוכן שקט).
| מסמך | קלט | תווים בפלט | בדיקות | זמן חציוני | הערות |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF עם שכבת טקסט) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" כולם קיימים |
| Bitcoin whitepaper (9 עמודים) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" קיימים |
| PDF סרוק (ללא שכבת טקסט) | 89 KB | 0 | 0/4 | 15 ms | פלט ריק, בלי שגיאה, בלי OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | כותרות + טבלת GFM; UUIDs מוטמעים נשמרים |
| DOCX עם משוואות | 15 KB | 240 | — | 101 ms | Office Math נשמר כ‑LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | כל sheet → ## SheetName + טבלת GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | סימוני מספר שקופית, טבלאות, תרשים → טבלה |
השחזור של הטקסט ב‑PDF עם שכבת טקסט היה מצוין — 7 מתוך 7 בדיקות שהוגדרו מראש על מאמר ה‑arXiv "Attention Is All You Need" ו‑6 מתוך 6 על Bitcoin whitepaper — ואף אחד מקבצי Office לא איבד ולו UUID‑sentinel אחד, כך שלא היה אובדן תוכן שקט גם על פי קבצי הרגרסיה של המתחזקים. ניצחון צר אבל חשוב: הנתיב של DOCX (דרך mammoth) משמר משוואות Office Math כ‑LaTeX, וממיר את equations.docx ל‑$$...$$ אמיתי. אם אתם מזינים ל‑LLM מסמכי Word עמוסי מתמטיקה, זה יתרון אמיתי, אם כי ממוקד מאוד, שלא מצאתי מתועד במקום אחר.
שני ממצאים כאן ראויים ליחס מיוחד, כי הם הכי סבירים לפגוע בכם בפועל.
ה‑PDF הסרוק שנעלם
תנו ל‑MarkItDown PDF מבוסס תמונה בלי שכבת טקסט, והוא יחזיר מחרוזת ריקה. אפס תווים, בלי חריגה, בלי אזהרה — וההמרה תסתיים בכ‑15 ms כי אין מה לחלץ. נתיב ה‑PDF של MarkItDown הוא חילוץ טקסט בלבד (עם pdfminer ו‑pdfplumber מאחורי הקלעים), ואין לו OCR בהתקנה הבסיסית או באף תוספת pip.
זה משמעותי מאוד בעיבוד אצווה. מפתח שמזין תיקייה של PDF‑ים, שחלקם סריקות, יקבל תוצאות ריקות בשקט עבור אותם קבצים, בלי שום סימן שמשהו דולג. בדקתי שהבעיה לא נובעת מקובץ פגום על ידי הרצה ישירה של extract_text של pdfminer על הקובץ — אפס תווים מחולצים, אין שכבת טקסט, אושר — ולכן הפלט הריק הוא באמת ההתנהגות של MarkItDown על סריקה אמיתית. זה משחזר את פער ה‑OCR fallback המוכר והפתוח כבר זמן רב. הנתיב המתועד הוא backend אופציונלי של Azure Document Intelligence או plugin; אף אחד מהם לא כלול בהתקנה ברירת המחדל.
PDF‑ים יוצאים כטקסט שטוח, לא כעץ מבני
בשני ה‑PDF‑ים עם שכבת טקסט, MarkItDown לא הפיק ולו סימון כותרת Markdown אחד. ל‑PDF אין תגי heading סמנטיים, ו‑MarkItDown גם לא מנחש כותרות לפי גודל גופן, לכן כל שורה נוחתת ברמת body. שחזור הטקסט גבוה; המבנה שטוח.
זה לא רק הממצא שלי. בנצ'מרקים ציבוריים של צד שלישי מדרגים את היררכיית הכותרות של MarkItDown ב‑PDF סביב 0.0, ואת נאמנות הטבלאות סביב 0.27 — הרבה מתחת ל‑0.88 של Docling המבוסס על TableFormer (ראו את ההשוואה MarkItDown vs Docling vs Marker ואת READoc benchmark). הנתונים שלי משחזרים את שלהם, וזה דווקא מחזק את הראיות — המספרים שלי תואמים מקור חיצוני. אותו בנצ'מרק גם מראה ש‑MarkItDown רץ בערך פי 100 מהר יותר מ‑Docling, וזה תואם את זמני השניות ולא הדקות שמצאתי במסמכים שכלי מבוסס מודל‑פריסה מעבד במשך דקות. המסקנה: MarkItDown נותן לכם טקסט PDF נקי ומהיר; הוא לא נותן לכם את המבנה של ה‑PDF. אם כותרות וטבלאות חייבות לשרוד, כלי מבוסס layout model כמו Docling או Marker הוא השכבה הנכונה.
טבלאות: התוכן תמיד שורד, המבנה לא תמיד
טבלאות הן המקום שבו "האם הטקסט שרד?" ו"האם הנתונים שמישים?" מתפצלים, אז בניתי מטריצת 13 מקרים — <table> אחד לכל מקרה, כל אחד מדורג מול מניפסט שנכתב לפני ההרצה — כדי למפות בדיוק אילו צורות מחזיקות ואילו נשברות.
הכותרת הראשית: MarkItDown לא איבד אף פעם את תוכן הטבלה. בכל 13 המקרים נשמרו 100% מהטוקנים שהוגדרו מראש. אבל נאמנות מבנית התפצלה לשלושה מצבים. שבעה מתוך שלושה‑עשר יצאו כגריד GFM תקין — טבלאות רגילות, header-colspan, טבלה רחבה של 24 עמודות, טבלאות בלי header, תאים ריקים, block-in-cell, וערבית מימין לשמאל. ארבעה יצאו עקומים, כי ב‑Markdown אין מושג של תא מתפרש, ולכן rowspan, colspan ומקורות פגומים מייצרים שורות קצרות. ושניים נשברו לגמרי.
שני השברים האלה שווים שם. טבלה מקוננת (<table> בתוך <td>) משוטחת לתוך השורה, עם ה‑pipes שלה ושורת המפריד שלה, ומייצרת שורת זבל של 14 "עמודות". ו־| ליטרלי בתוך תא לא מקבל escape — טקסט התא a | b הופך לשתי עמודות, x || y הופך לשלוש — כך שטבלה של שתי עמודות פולטת שורות עם שתיים, שלוש וארבע עמודות, וכל parser של Markdown בהמשך יקרא את הגבולות בצורה שגויה. מעניין שלוכסנים * ו‑backticks בתוך התא כן עוברים escape; רק pipes לא. הסיבה היא שבנתיב ה‑HTML של MarkItDown משתמשים בברירת המחדל של markdownify לטיפול בטבלאות, והמחלקה המותאמת אישית שלו עוקפת קישורים, תמונות וכותרות אבל לא תאי טבלה. אותו באג של אי‑הימלטות pipes הוא issue פתוח גם בממיר CSV (#2019), אבל התיקון שם לא משפיע על נתיב ה‑HTML שבדקתי.
המקרה העדין יותר — זה שהכי חשוב למהנדס נתונים לראות — הוא rowspan. מקרה t03 לא רק יוצא עקום; הוא גם מזיז נתונים בלי להתריע. תווית עם rowspan=2 ("Fruit") נכתבת פעם אחת, והשורה שמתחתיה נהיית שורה קצרה של שתי עמודות (| Banana | 8 |), כך ש‑"Banana" נוחת בעמודת Group במקום בעמודת Item. כל הטוקנים שם. צרכן תמים ש"קורא את העמודה השנייה" יקבל ערך שגוי. זה סוג הבאג שעובר בדיקה של הישרדות טקסט, אבל מזהם מערך נתונים בשקט.
המגבלה של spans עצמה היא אילוץ תכנוני מוכר ומתועד (#1211, #1248) — גריד pipe שטוח של GFM באמת לא יכול לייצג spans או nesting, ולכן הממיר מקריב מבנה לטובת שלמות תוכן. יש גם התנהגויות טובות יותר: טבלאות בלי header מקבלות שורת כותרת ריקה מסונתזת (כך שלא מקדמים בטעות נתונים לכותרת), תאים ריקים נשמרים, ו‑<caption> שורד כשורת טקסט מעל הטבלה.
התקנה והפעלה ראשונית: המס שלא מזהירים עליו בכלי "קל משקל"
שום דבר כאן לא הפתיע אותי יותר, וזה בדיוק המקום שבו המסגור של "כלי Python קל משקל" מבטיח יותר מדי בשקט.
ראשית, אל תריצו pip install 'markitdown[all]'. ב‑Python 3.14 זה מבצע backtracking שקט ל‑markitdown 0.0.2 — גרסה בת שנתיים — ושחזרתי את זה חי בתוך venv נקי. כשמקבעים את הגרסה רואים למה: pip install 'markitdown[all]==0.1.6' נכשל כי התוספת [all] נועלת את youtube-transcript-api~=1.0.0, וב‑PyPI הנוכחי כל build בטווח הזה מוגבל ל‑Python <3.14, בעוד שה‑build‑ים היחידים שתואמים ל‑3.14 נמצאים מחוץ לטווח שהוגדר. לכן הפותר יורד עד לגרסה האחרונה שאת התלויות שלה הוא מצליח לספק. זה תואם issue פתוח (#2179). התיקון פשוט — נועלים את הגרסה ומתקינים תוספות בנפרד: pip install 'markitdown==0.1.6', ואז pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. כל אחד מהם נפתר בלי בעיה; רק ה‑bundle המאוחד [all] מכיל את ה‑pin הבעייתי. (המלכודת הזו תלויה בגרסת Python — ב‑Python 3.13 או מוקדם יותר ההגבלה אולי לא תפגע, ולכן [all] עלול להיפתר אחרת.)
שנית, טביעת הרגל. ההתקנה הבסיסית היא 161 MB (venv ריק של 13 MB ועוד 148 MB). מתוכם onnxruntime (73 MB) ו‑numpy (34 MB) יחד הם 107 MB — 66% מכל טביעת הרגל של ההתקנה הבסיסית — ושניהם נמשכים בגלל תלות קשיחה אחת: magika, מזהה סוגי הקבצים של Google מבוסס ML. כך ממיר טקסט מגיע עם runtime של 73 MB ל‑ONNX inference כבר בהתקנה הראשית, עוד לפני שהוספתם תוספת אחת למסמך. הוסיפו את תוספות המסמכים וה‑venv מגיע ל‑310 MB. זה הרבה יותר קל מסטאק של דפדפן headless, אבל אם ציפיתם ל‑pip install וגמרנו, חשוב לדעת ש‑ONNX runtime מגיע איתו.
שלישית — וזה הממצא היחיד בכל החבילה שלי שעבר כל בדיקת חידוש שניסיתי — גם אחרי התקנה נקייה, import markitdown עולה בערך 3.35 שניות על המכונה הזו. כמעט כל המחיר הוא בזמן ה‑import: markitdown._markitdown מייבא מראש את כל registry של הממירים (2.56 שניות מצטברות, 76% מהסך), וזה מושך פנימה pandas (594 ms, דרך ממיר XLSX), python-pptx (427 ms), magika (354 ms) ו‑requests (270 ms) — גם אם אתם לא ממירים אף אחד מהפורמטים האלה. עבור שירות שרץ זמן רב זה מתמזג ונעשה לא משמעותי. עבור CLI או cold start של serverless זה מס של ממש לכל תהליך, והתיוג "utility קל משקל" לא מרמז על זה. (הערת הוגנות: זו הרצה אחת עם profiling, ולכן מדובר בתצפית אחת ולא בהתפלגות של ריצות מרובות.)
סקייל: זה לא קורס, אבל צריך לתקצב CPU ל‑PDF‑ים ו‑RAM לגיליונות
דחפתי דרך המנוע ארבעה נושאים כבדים, כל אחד בתהליך נפרד כדי שזיכרון השיא לא יושפע מהרצה קודמת. שום דבר לא קרס. אבל פרופיל העלויות לא סימטרי.
| נושא | קלט | תווים בפלט | זמן חציוני | שינוי שיא RSS |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF של 492 עמודים) | 5.9 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX עם 50,000 שורות × 8 עמודות | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (כ‑15 עמודים) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX עם 200 שורות × 64 עמודות | 46 KB | 120,129 | 2.9 s | +22 MB |
ה‑PDF של NIST בן 492 העמודים לקח חציון של 192.5 שניות — בערך 3.2 דקות, או 0.39 שניות לעמוד — כי pdfplumber מריץ זיהוי טפסים לפי מיקום מילים על כל עמוד. שיא ה‑RSS נשאר על +40 MB, כלומר צוואר הבקבוק הוא CPU ולא זיכרון. אפילו ה‑PDF של arXiv בן 15 העמודים לקח 12.6 שניות בתהליך מבודד, בערך פי 3.4 מה‑3.7 שניות שאותו קובץ הראה במצב warm בתוך חבילת המסמכים שלי. הפער הזה הוא מחיר של תהליך קר, והוא מאשר שעבודה לפי עמודים היא המניע, לא גודל הבייטים. אם אתם רוצים מספר יחיד שאפשר להעביר הלאה עבור ה‑PDF הזה, השתמשו ב‑12.6 השניות המבודדות.
נתיב הגיליונות הופך את צוואר הבקבוק. קובץ XLSX של 2.1 MB עם 50,000 שורות התנפח ל‑+374 MB שיא RSS (ו‑3.7 מיליון תווי פלט) כי הממיר טוען את כל הגיליון ובונה מחרוזת Markdown אחת גדולה. לכן ההמלצה הפרקטית פשוטה: עבור PDF‑ים גדולים, תקצבו דקות של CPU; עבור גיליונות גדולים, תקצבו מאות MB של RAM. אלה נתונים ממכונה אחת על macOS arm64 ו‑Python 3.14, והקבועים לפי עמוד ולפי שורה הם תלויי פלטפורמה — אבל הצורה הכללית (PDF איטי ותלוי CPU, XLSX כבד בזיכרון, ושום דבר לא קורס) היא החלק שעובר גם הלאה.
איפה Thunderbit נכנס — ואיפה לא
נסו את Thunderbit לחילוץ נתוני אינטרנט
זה ההשוואה הכי קלה להפרזה, אז אצייר את הקו בזהירות. MarkItDown ו‑Thunderbit פותרים בעיות סמוכות, לא אותה בעיה.
MarkItDown ממיר קבצים שכבר יש לכם. Thunderbit מושך את העמוד קודם. נקודת הקצה /distill של Thunderbit הופכת דף אינטרנט חי ל‑Markdown נקי שמוכן ל‑LLM — כולל רינדור JS, התמודדות עם אנטי‑בוט ותוכן דינמי שאין ל‑MarkItDown שום מנגנון עבורו — ונקודת הקצה /extract מחזירה JSON מובנה שמותאם לסכימה, לא רק Markdown גולמי. למפתחים זה זמין כ‑API (POST /distill / POST /extract), כשרת MCP, וכ‑CLI (npx @thunderbit/thunderbit-cli) על גבי אותו מנוע AI, זה שגם עומד מאחורי התוסף עם יותר מ‑100,000 משתמשים.
אז יש ביניהם חפיפה בדבר אחד בלבד — שניהם יכולים להפיק "Markdown מוכן ל‑LLM" — אבל תחום הקלט שונה: ה‑distill של Thunderbit מקבל URL מהאינטרנט הפתוח, ו‑MarkItDown מקבל קובץ מקומי. הם לא תחליפים זהים, ואני לא אעמיד פנים שכן. סטאק ריאלי משתמש בשניהם: מחלץ וסורק את ה‑web עם Thunderbit (או שירות בסגנון Firecrawl), ואז מנרמל את המסמכים המקומיים המעורבים שיש לכם גם — ה‑PDF‑ים, המצגות והגיליונות — עם MarkItDown. אחד מטפל ברשת; השני מטפל במגירת הקבצים.
יתרונות וחסרונות
חוזקות
- שחזור מלא של גוף התוכן ב‑HTML נקי (4/4 עמודים), עם שימור נאמן של עץ הכותרות והקישורים
- שחזור טקסט גבוה ב‑PDF/DOCX (arXiv 7/7 בדיקות, Bitcoin 6/6) וללא אובדן תוכן שקט בקבצי Office של המתחזקים
- משוואות Office Math נשמרות כ‑LaTeX — יתרון נישתי אבל אמיתי
- לא קרס על אף נושא שנבדק, עד PDF בן 492 עמודים ו‑XLSX עם 50k שורות
- קל מאוד לשימוש: CLI,
convert(), piping דרך stdin, ואפשרות לשרת MCP - רישיון MIT, מתוחזק באופן פעיל על ידי Microsoft, ומעקב issues מגיב
חולשות
- משאיר boilerplate — עד 12.4% שורות chrome ב‑Wikipedia; לא מחלץ רק את המאמר
- טבלאות נשברות ב‑spans, nesting ו‑pipes בתוך תאים (2/13 נשברו, 4/13 יצאו עקומות), ו‑rowspan מזיז נתונים בשקט לעמודה הלא נכונה
- PDF סרוק/מבוסס תמונה מחזיר פלט ריק בלי OCR ובלי שגיאה
- פלט ה‑PDF חסר מבנה כותרות לחלוטין (בהתאם לבנצ'מרקים ציבוריים)
- התקנה בסיסית של 161 MB עם runtime של 73 MB ל‑ONNX; import קר של כ‑3.35 שניות
- תוספת
[all]מחזירה בשקט לגרסת 0.0.2 בת שנתיים ב‑Python 3.14
למי זה מתאים ולמי לא
כדאי לבחור ב‑MarkItDown אם אתם מיישרים ערימה של מסמכים מקומיים מעורבים — Word, Excel, PowerPoint, PDF עם שכבת טקסט — ל‑Markdown עבור pipeline של LLM, ואכפת לכם יותר משלמות הטקסט מאשר משמירת המבנה. כמרה האחרונה בתהליך batch, שמזינה טקסט נקי למודל, הוא מהיר, נאמן וחינמי.
עדיף לדלג עליו, או לשלב אותו עם משהו אחר, אם אחת מהמשימות שלכם היא: אתם צריכים רק את המאמר הראשי מתוך דף אינטרנט (השתמשו בכלי readability או Firecrawl); אתם צריכים שכותרות וטבלאות של PDF יישמרו בשלמותם (זה תחום של Docling או Marker); או שהקלטים שלכם כוללים מסמכים סרוקים שדורשים OCR (תצטרכו את ה‑Azure backend או כלי אחר לגמרי). ואם חשבתם שאתם קונים סקרייפר — משהו שמושך וסורק — זה בכלל לא זה.
הציון הזמני שרצתי עליו, על רובריקה שנראית כמו של סקרייפר, מציב את MarkItDown על 60/100, והציון הנמוך הזה הוא תוצר של לדרג ממיר לפי מבחן של סורק. בשטח שלו, ציוני נאמנות הטקסט שלו גבוהים; נקודות התורפה הן מבניות (טבלאות, כותרות PDF) ושייכות לחבילה (טביעת רגל, import, מלכודת [all]), לא לאיכות הטקסט. אם שופטים אותו לפי מה שהוא באמת — ממיר מקובץ ל‑Markdown — מדובר בכלי מוצק ומתוחזק היטב, עם כמה קצוות חדים שכדאי להכיר לפני שמכניסים אותו לייצור.
שאלות נפוצות
האם MarkItDown הוא סקרייפר אינטרנט?
לא. אין לו crawler, אין רינדור JavaScript, אין מעבר על קישורים ואין pagination. הוא ממיר קבצים ומסמכים שכבר יש לכם — PDF, DOCX, XLSX, PPTX, תמונות, HTML — ל‑Markdown. אם אתם צריכים למשוך ולסרוק דפי אינטרנט חיים, צריך כלי סקרייפינג כמו Thunderbit או Firecrawl; MarkItDown הוא השלב שאחר כך, כשהופכים קבצים שנמשכו או קבצים מקומיים ל‑Markdown נקי.
למה pip install markitdown[all] מתקין גרסה ישנה?
ב‑Python 3.14, התוספת [all] נועלת את youtube-transcript-api~=1.0.0, וכל build בטווח הזה מוגבל לגרסאות Python מתחת ל‑3.14. הפותר לא מצליח לספק את ה‑pin, ולכן הוא חוזר בשקט ל‑markitdown 0.0.2, גרסה בת שנתיים. הפתרון הוא לנעול את הגרסה ולהתקין תוספות בנפרד: pip install 'markitdown==0.1.6', ואז להוסיף 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. זה מתועד ב‑issue #2179.
האם MarkItDown עושה OCR על PDF סרוק?
לא בהתקנה הבסיסית. נתיב ה‑PDF שלו הוא לחילוץ טקסט בלבד, לכן PDF מבוסס תמונה בלי שכבת טקסט מחזיר מחרוזת ריקה — בלי שגיאה, בלי אזהרה. OCR דורש את ה‑backend האופציונלי של Azure Document Intelligence או plugin, ואף אחד מהם לא מגיע כברירת מחדל. זה פער מוכר כבר זמן רב (issue #1268).
עד כמה MarkItDown מטפל טוב בטבלאות?
מבחינת תוכן — מצוין. במבחן שלי עם 13 מקרים הוא שמר על 100% מתוכן הטבלאות בכל מקרה. מבחינת מבנה — זה תלוי בצורה: טבלאות פשוטות, רחבות, בלי header ועם תאים ריקים יוצאות כגרידי GFM נקיים, אבל rowspan ו‑colspan יוצאים עקומים (ו‑rowspan יכול להזיז נתונים בשקט לעמודה הלא נכונה), טבלאות מקוננות משתטחות לשורות זבל, ו‑pipe ליטרלי בתוך תאים לא מקבל escape. פורמט הטבלה השטוח של Markdown פשוט לא מסוגל לייצג spans או nesting.
האם MarkItDown מהיר מספיק למסמכים גדולים?
הוא לא קורס על קבצים גדולים, אבל צריך לתקצב משאבים לפי סוג. PDF בן 492 עמודים לקח בערך 3.2 דקות (כ‑0.39 שניות לעמוד) כי יש בו זיהוי טפסים לכל עמוד, ולכן הוא CPU-bound. גיליון אלקטרוני עם 50,000 שורות הסתיים בערך בדקה אבל השתמש בעוד 374 MB של RAM, כי הוא בונה מחרוזת Markdown אחת גדולה בזיכרון. עבור PDF‑ים גדולים תכננו דקות של CPU; עבור גיליונות גדולים תכננו מאות MB של RAM.
נסו את Thunderbit לחילוץ נתוני אינטרנט Get Started Free
