Το MarkItDown συχνά μπαίνει στο ίδιο τσουβάλι με τα web scrapers, αλλά αυτό είναι λάθος. Δεν έχει crawler, δεν διαθέτει μηχανή JavaScript και δεν μπορεί να κατεβάσει μια URL και να καθαρίσει το boilerplate από τη σελίδα. Αυτό που κάνει είναι να παίρνει δεδομένα που ήδη έχεις — ένα PDF, ένα έγγραφο Word, ένα spreadsheet, μια παρουσίαση — και να τα μετατρέπει ολόκληρα σε Markdown που μπορεί να διαβάσει ένα γλωσσικό μοντέλο.
Πέρασα μερικές εβδομάδες δοκιμάζοντας το Microsoft MarkItDown πάνω σε πραγματικά έγγραφα σε ένα μόνο Mac, βαθμολογώντας κάθε πίνακα με βάση ένα manifest που είχα γράψει πριν από την εκτέλεση και μετρώντας τον χρόνο κάθε μετατροπής. Η σύντομη εκδοχή: σε καθαρά αρχεία είναι γρήγορο και πιστό, όμως στη διανομή του κρύβει ένα runtime μηχανικής μάθησης 73 MB που δεν θα περίμενες, και οι πίνακές του χαλάνε με τρόπους που περνούν ένα τεστ του τύπου «σώθηκε το κείμενο;» αλλά αποτυγχάνουν στο «μπήκαν τα δεδομένα στη σωστή στήλη;». Ακολουθεί η πλήρης εικόνα, με αριθμούς.
Τι είναι πραγματικά το MarkItDown
Το MarkItDown είναι ένα Python utility της Microsoft που μετατρέπει αρχεία και έγγραφα Office σε Markdown βελτιστοποιημένο για LLMs. Δώσε του ένα PDF, ένα .docx, ένα .xlsx, ένα .pptx, μια εικόνα, ένα HTML αρχείο ή μερικές ακόμη μορφές και σου επιστρέφει Markdown. Διατίθεται με τρεις τρόπους χρήσης: CLI (markitdown file.pdf -o out.md, ή μέσω stdin), Python API (MarkItDown().convert(...)) και προαιρετικό MCP server για agent workflows.
Η πιο κρίσιμη διευκρίνιση είναι τι δεν κάνει, γιατί ούτε το README το ισχυρίζεται ούτε το επιβεβαίωσα στις δοκιμές: δεν κάνει crawling, δεν αποδίδει JavaScript, δεν ακολουθεί συνδέσμους, δεν χειρίζεται pagination και δεν κάνει εξαγωγή κύριου περιεχομένου τύπου readability. Είναι ένας μετατροπέας ολόκληρου εγγράφου. Εσύ φέρνεις τα bytes, εκείνος τα τυποποιεί. Αυτή η μία διαφορά καθορίζει αν αυτό το εργαλείο ανήκει στο stack σου ή όχι, γι’ αυτό και θα επανέρχομαι συχνά σε αυτήν.
Το ίδιο το repo είναι «βαρύ» με βάση τα vanity metrics του GitHub — 165.282 stars και 11.790 forks στα μέσα Ιουλίου 2026, με άδεια MIT και τελευταία έκδοση (v0.1.6) στις 2026-05-26. Όμως αυτό το star count αντανακλά περισσότερο τον ενθουσιασμό γύρω από τα LLM εργαλεία και το όνομα της Microsoft, όχι απαραίτητα ωριμότητα των εσωτερικών μηχανισμών μετατροπής. Υπάρχουν επίσης 833 ανοιχτά issues, και μερικά από αυτά σε αφορούν άμεσα πριν το εγκαταστήσεις (περισσότερα παρακάτω).
HTML σε Markdown: γρήγορο και πλήρες, μαζί όμως και το boilerplate
Επειδή η υπόλοιπη σειρά αξιολόγησής μου για scrapers χρησιμοποιεί τα ίδια τέσσερα web fixtures, έδωσα στο MarkItDown τα ίδια τοπικά HTML αρχεία — όχι για να το κρίνω ως scraper, αλλά για να δω πόσο καλό είναι στο HTML-to-Markdown. Σε σελίδες με σωστή σήμανση είναι πραγματικά καλό.
Και οι τέσσερις σελίδες μετατράπηκαν με τη βασική εγκατάσταση, χωρίς επιπλέον πακέτα, και κάθε probe του body-content διατηρήθηκε. Το άρθρο της Wikipedia για το Web scraping (226 KB) διατήρησε το δέντρο επικεφαλίδων του — μία h1, επτά h2, δώδεκα h3, ακριβώς όπως η πραγματική δομή των ενοτήτων του άρθρου — και οι 418 σύνδεσμοι έμειναν ως σωστά [text](url). Ο πίνακας 25×9 με στατιστικά χόκεϊ στη σελίδα Scrape This Site forms page έγινε ένας καθαρός GFM pipe table 27 σειρών (κεφαλίδα + διαχωριστική γραμμή + 26 γραμμές δεδομένων), με κενά κελιά όπως πρέπει. Η ταχύτητα εδώ δεν ήταν θέμα: διάμεσος χρόνος 48 ms για τη μικρή σελίδα αποσπασμάτων έως 352 ms για τη σελίδα της Wikipedia των 226 KB.
Υπάρχει όμως μια παγίδα, και είναι συνειδητή επιλογή σχεδίασης, όχι bug. Το MarkItDown δεν αφαιρεί το boilerplate. Μετατρέπει ολόκληρο το <body>, οπότε το site chrome περνάει μαζί — και το υπόλοιπο μεγαλώνει όσο πιο «φορτωμένη» είναι η σελίδα.
| Σελίδα | Χαρακτήρες εξόδου | Επικεφαλίδες (h1/h2/h3) | Σύνδεσμοι | Γραμμές site 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) |
Στην σχεδόν καθαρή από chrome σελίδα Books, το 0.6% των γραμμών εξόδου είναι chrome. Στη Wikipedia, το ποσοστό είναι 12.4% — 42 από τις 338 μη κενές γραμμές είναι «jump to content», «toggle the table of contents», «22 languages», «retrieved from», καθώς και footers για cookies και άδειες χρήσης. Τα maintenance banners της Wikipedia («This article needs additional citations») αποδίδονται επίσης πιστά σε πίνακες δύο στηλών, και από εκεί προκύπτουν εννέα γραμμές πίνακα σε μια σελίδα χωρίς πραγματικό πίνακα δεδομένων.
Δεν σημαίνει ότι το MarkItDown κάνει κάτι λάθος. Είναι μετατροπέας ολόκληρου εγγράφου, όχι extractor καθαρού άρθρου: το πιστό HTML-to-Markdown είναι διαφορετική δουλειά από το καθαρό article extraction. Εργαλεία όπως το Trafilatura ή τα Firecrawl-style tools στοχεύουν να επιστρέφουν μόνο το κύριο περιεχόμενο· το MarkItDown επιστρέφει τη σελίδα. Εσωτερικά, το _html_converter.py αφαιρεί <script> και <style> και μετά δίνει ολόκληρο το body στη βιβλιοθήκη markdownify — χωρίς κανένα heuristic για το κύριο περιεχόμενο. Αν θέλεις μόνο το άρθρο, αυτό είναι λάθος επίπεδο.
Το φυσικό του περιβάλλον: PDF, DOCX, XLSX, PPTX
Τα έγγραφα είναι ο λόγος που φτιάχτηκε το MarkItDown. Το δοκίμασα σε πραγματικά δημόσια αρχεία — ένα arXiv paper με text layer, το Bitcoin whitepaper, ένα image-only σαρωμένο PDF που είχα αποδώσει ώστε να μην έχει καθόλου κείμενο, και τα DOCX/XLSX/PPTX files από το δικό του test suite (με UUIDs για να εντοπίζω τυχόν αθόρυβη απώλεια περιεχομένου).
| Έγγραφο | Input | Χαρακτήρες εξόδου | Probes | Διάμεσος χρόνος | Σημειώσεις |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF με text layer) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" όλα παρόντα |
| Bitcoin whitepaper (9 σελ. PDF) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" παρόντα |
| Σαρωμένο PDF (χωρίς text layer) | 89 KB | 0 | 0/4 | 15 ms | κενή έξοδος, χωρίς σφάλμα, χωρίς OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | επικεφαλίδες + GFM table· τα ενσωματωμένα UUIDs επιβιώνουν |
| DOCX με εξισώσεις | 15 KB | 240 | — | 101 ms | Office Math διατηρείται ως LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | κάθε sheet → ## SheetName + GFM table |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | δείκτες αριθμού διαφάνειας, πίνακες, γράφημα → πίνακας |
Η ανάκτηση κειμένου στα PDFs με text layer ήταν εξαιρετική — 7 από 7 pre-registered probes στο arXiv paper Attention Is All You Need, 6 από 6 στο Bitcoin whitepaper — και κανένα από τα Office αρχεία δεν έχασε ούτε ένα UUID sentinel, άρα δεν υπήρξε αθόρυβη απώλεια περιεχομένου στα δικά του regression fixtures. Ένα ιδιαίτερα καλό, και συγκεκριμένο, εύρημα: το DOCX path (μέσω mammoth) διατηρεί τις Office Math εξισώσεις ως LaTeX, μετατρέποντας το equations.docx σε πραγματικά $$...$$ μαθηματικά. Αν τροφοδοτείς ένα LLM με Word έγγραφα γεμάτα μαθηματικά, αυτό είναι ένα ουσιαστικό, έστω και εξειδικευμένο, πλεονέκτημα που δεν βρήκα να περιγράφεται αλλού.
Δύο ευρήματα σε αυτό το πεδίο αξίζουν ξεχωριστή προσοχή, γιατί είναι αυτά που πιθανότερα θα σε χτυπήσουν.
Το σαρωμένο PDF που εξαφανίζεται
Δώσε στο MarkItDown ένα image-only PDF χωρίς text layer και επιστρέφει κενή συμβολοσειρά. Μηδέν χαρακτήρες, χωρίς εξαίρεση, χωρίς προειδοποίηση — μετατροπή σε περίπου 15 ms, επειδή δεν υπάρχει τίποτα να εξαχθεί. Η διαδρομή PDF του MarkItDown κάνει μόνο text extraction (με pdfminer και pdfplumber από κάτω), και δεν περιλαμβάνει OCR στη βασική εγκατάσταση ούτε σε κάποιο pip extra.
Αυτό έχει σημασία σε batch επεξεργασία. Αν ένας developer περάσει έναν φάκελο με PDFs όπου κάποια είναι scans, θα πάρει σιωπηλά κενά αποτελέσματα γι’ αυτά τα αρχεία, χωρίς κανένα σήμα ότι παραλείφθηκαν. Έλεγξα ότι το fixture δεν ήταν χαλασμένο τρέχοντας το extract_text του pdfminer απευθείας επάνω του — μηδέν stripped characters, επιβεβαιωμένο ότι δεν υπάρχει text layer — άρα η κενή έξοδος είναι η πραγματική συμπεριφορά του MarkItDown σε ένα πραγματικό scan. Αυτό αναπαράγει ένα από καιρό ανοιχτό κενό για OCR fallback (#1268) που παρακολουθείται upstream εδώ και καιρό. Η τεκμηριωμένη διαδρομή είναι το προαιρετικό Azure Document Intelligence backend ή κάποιο plugin· τίποτα από τα δύο δεν περιλαμβάνεται στην default εγκατάσταση.
Τα PDFs βγαίνουν ως επίπεδο κείμενο, όχι ως δομή
Και στα δύο PDFs με text layer, το MarkItDown παρήγαγε μηδέν Markdown heading markers. Ένα PDF δεν περιέχει semantic heading tags, και το MarkItDown δεν τα συμπεραίνει από το μέγεθος της γραμματοσειράς, οπότε κάθε γραμμή καταλήγει σε επίπεδο body. Η ανάκτηση κειμένου είναι υψηλή, η δομή όμως είναι επίπεδη.
Δεν είναι μόνο δικό μου εύρημα. Δημόσια benchmarks τρίτων δίνουν στο MarkItDown βαθμολογία γύρω στο 0.0 για την ιεραρχία επικεφαλίδων στα PDFs και περίπου 0.27 για την πιστότητα πινάκων, πολύ κάτω από το 0.88 του Docling με TableFormer (δείτε τη σύγκριση MarkItDown vs Docling vs Marker και το READoc benchmark). Τα δικά μου fixtures αναπαράγουν τα ίδια αποτελέσματα, κάτι που ενισχύει τα στοιχεία — οι δικοί μου αριθμοί συμφωνούν με εξωτερική πηγή. Η ίδια σύγκριση αναφέρει και το trade-off ότι το MarkItDown τρέχει περίπου 100 φορές γρηγορότερα από το Docling, κάτι που ταιριάζει με τους χρόνους μου σε δευτερόλεπτα και όχι λεπτά σε έγγραφα που ένα layout-model εργαλείο «μασάει» για αρκετά λεπτά. Το συμπέρασμα: το MarkItDown σου δίνει καθαρό, γρήγορο PDF κείμενο· δεν σου δίνει τη δομή του PDF. Αν οι επικεφαλίδες και οι πίνακες πρέπει να διατηρηθούν, ένα εργαλείο με layout model όπως το Docling ή το Marker είναι το σωστό επίπεδο.
Πίνακες: το περιεχόμενο σχεδόν πάντα σώζεται, η δομή όμως όχι πάντα
Οι πίνακες είναι το σημείο όπου το «σώθηκε το κείμενο;» και το «είναι αξιοποιήσιμα τα δεδομένα;» χωρίζουν δρόμους, οπότε έφτιαξα έναν πίνακα 13 περιπτώσεων — ένα <table> ανά case, με βαθμολόγηση βάσει ενός manifest που είχε γραφτεί πριν από την εκτέλεση — για να χαρτογραφήσω ακριβώς ποιες μορφές αντέχουν και ποιες χαλάνε.
Το βασικό συμπέρασμα: το MarkItDown δεν έχασε ποτέ το περιεχόμενο των πινάκων. Και οι 13 περιπτώσεις διατήρησαν το 100% των pre-registered tokens. Η δομική πιστότητα όμως χωρίστηκε σε τρία είδη. Επτά από τις δεκατρείς περιπτώσεις παρήγαγαν σωστό GFM πλέγμα (απλοί πίνακες, header-colspan, πίνακες 24 στηλών, χωρίς κεφαλίδα, με κενά κελιά, block-in-cell και δεξιά-προς-αριστερά αραβικά). Τέσσερις βγήκαν «σχισμένες», επειδή το Markdown δεν έχει έννοια για cell spanning, οπότε rowspan, colspan και κακοσχηματισμένες πηγές παράγουν σύντομες γραμμές. Και δύο ήταν εντελώς χαλασμένες.
Αξίζει να ονομαστούν οι δύο αστοχίες. Ένας nested table (πίνακας μέσα σε <td>) ισοπεδώνεται inline, πετώντας τις δικές του κάθετες γραμμές και τη γραμμή διαχωρισμού μέσα στο γονικό κελί και δημιουργώντας μια γραμμή-σκουπίδι 14 «στηλών». Και ένα κυριολεκτικό | μέσα σε κελί δεν γίνεται escape — το κείμενο κελιού a | b γίνεται δύο στήλες, το x || y γίνεται τρεις — με αποτέλεσμα ένας πίνακας δύο στηλών να παράγει γραμμές δύο, τριών και τεσσάρων στηλών, και κάθε downstream Markdown parser να διαβάζει λάθος τα όρια. Παραδόξως, τα αστεράκια και τα backticks μέσα στα κελιά γίνονται escape· οι κάθετες γραμμές απλώς όχι. Η βασική αιτία είναι ότι η HTML διαδρομή του MarkItDown χρησιμοποιεί το default table handling του markdownify, ενώ η δική του custom subclass αντικαθιστά links, images και headings, όχι όμως τα table cells. Το ίδιο bug-class για το escaping των pipes είναι ήδη ανοιχτό issue για τον CSV converter (#2019), αν και αυτή η διόρθωση δεν αγγίζει την HTML διαδρομή που δοκίμασα εδώ.
Το πιο ύπουλο — το εύρημα που θα ήθελα περισσότερο να δει ένας data engineer — είναι το rowspan. Το case t03 δεν απλώς βγαίνει «σχισμένο»· ευθυγραμμίζει λάθος τα δεδομένα, χωρίς να το καταλάβεις. Μια ετικέτα rowspan=2 («Fruit») εκδίδεται μία φορά και η γραμμή από κάτω καταλήγει ως σύντομη γραμμή δύο στηλών (| Banana | 8 |), άρα το «Banana» πέφτει κάτω από τη στήλη Group αντί για Item. Όλα τα tokens υπάρχουν. Ένας αφελής καταναλωτής που διαβάζει «τη δεύτερη στήλη» θα πάρει λάθος τιμή. Αυτό είναι το είδος bug που περνάει έναν έλεγχο επιβίωσης κειμένου και σιωπηλά αλλοιώνει ένα dataset.
Ο ίδιος ο περιορισμός των spans είναι γνωστή, καταγεγραμμένη σχεδιαστική δέσμευση (#1211, #1248) — ένα επίπεδο GFM pipe grid πραγματικά δεν μπορεί να αναπαραστήσει spans ή nesting, άρα ο μετατροπέας ανταλλάσσει δομή με πληρότητα περιεχομένου. Υπάρχουν όμως και σωστές συμπεριφορές μέσα σε αυτά: οι πίνακες χωρίς κεφαλίδα παίρνουν μια συνθετική κενή γραμμή header (ώστε να μη μετατρέπεται αθόρυβα το περιεχόμενο σε header), τα κενά κελιά διατηρούνται και το <caption> επιβιώνει ως γραμμή κειμένου πάνω από τον πίνακα.
Εγκατάσταση και εκκίνηση: ο φόρος που δεν σε προειδοποιεί ένα «ελαφρύ utility»
Τίποτα εδώ δεν με εξέπληξε περισσότερο, και είναι το σημείο όπου το framing «lightweight Python utility» υπόσχεται περισσότερο απ’ ό,τι παραδίδει.
Πρώτον, μην τρέξεις pip install 'markitdown[all]'. Στην Python 3.14, κάνει αθόρυβα backtrack στο markitdown 0.0.2 — μια έκδοση δύο ετών — κάτι που αναπαρήγαγα ζωντανά σε ένα καθαρό venv. Το γιατί φαίνεται όταν καρφιτσώσεις την έκδοση: pip install 'markitdown[all]==0.1.6' αποτυγχάνει, επειδή το [all] extra καρφιτσώνει youtube-transcript-api~=1.0.0, και στο τρέχον PyPI κάθε build σε αυτό το εύρος απαιτεί Python <3.14, ενώ τα μόνα 3.14-compatible builds βρίσκονται εκτός του pin. Άρα ο resolver γυρίζει μέχρι την τελευταία έκδοση της οποίας οι εξαρτήσεις μπορούν να ικανοποιηθούν. Αυτό ταιριάζει με ένα ανοιχτό upstream issue (#2179). Η λύση είναι απλή — καρφιτσώστε την έκδοση και εγκαταστήστε τα extras ξεχωριστά: pip install 'markitdown==0.1.6', έπειτα pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Κάθε ένα από αυτά επιλύεται σωστά· μόνο το συνδυασμένο [all] bundle περιέχει το προβληματικό pin. (Αυτή η παγίδα εξαρτάται από την έκδοση της Python — στην Python 3.13 ή παλαιότερη το gate ίσως να μη χτυπήσει, άρα το [all] μπορεί να επιλυθεί διαφορετικά.)
Δεύτερον, το αποτύπωμα. Η βασική εγκατάσταση είναι 161 MB (ένα άδειο venv 13 MB συν 148 MB). Από αυτό, τα onnxruntime (73 MB) και numpy (34 MB) μαζί είναι 107 MB — δηλαδή 66% ολόκληρου του core footprint — και τα δύο έρχονται από μία μόνο hard dependency: το magika, το ML file-type detector της Google. Άρα ένας μετατροπέας κειμένου κουβαλάει ένα ONNX inference runtime 73 MB στη βασική εγκατάσταση, πριν προσθέσεις ούτε ένα document extra. Με τα document extras, το venv φτάνει τα 310 MB. Είναι πολύ ελαφρύτερο από ένα headless-browser stack, αλλά αν περίμενες ένα μικρό utility του τύπου «pip install και τέλος», να ξέρεις ότι έρχεται μαζί και ένα ONNX runtime.
Τρίτον — και αυτό είναι το ένα εύρημα σε όλο το σύνολο που περνάει κάθε novelty check που έτρεξα — ακόμη και μετά από καθαρή εγκατάσταση, το import markitdown κοστίζει περίπου 3.35 δευτερόλεπτα σε αυτό το μηχάνημα. Το κόστος είναι σχεδόν εξ ολοκλήρου στο import: το markitdown._markitdown κάνει eager import ολόκληρο το converter registry (2.56 s αθροιστικά, το 76% του συνόλου), το οποίο τραβάει μαζί pandas (1.21 s, μέσω του XLSX converter), python-pptx (427 ms), magika (354 ms) και requests (270 ms) — είτε μετατρέψεις αυτά τα formats είτε όχι. Για μια υπηρεσία που τρέχει συνεχώς, αυτό αποσβένεται και δεν έχει σημασία. Για μια CLI κλήση ή ένα serverless cold start, είναι πραγματικός φόρος ανά process, κάτι που η ετικέτα «lightweight utility» δεν σε προετοιμάζει να περιμένεις. (Δίκαιη σημείωση: αυτό είναι ένα μόνο profiled run, αντιμετωπίζεται ως μία παρατήρηση και όχι ως κατανομή πολλών runs.)
Κλίμακα: δεν κρασάρει, αλλά θέλει CPU για PDFs και RAM για spreadsheets
Πέρασα τέσσερα μεγάλα subjects μέσα από ξεχωριστές διεργασίες, ώστε η μέγιστη μνήμη να μην επηρεάζεται από προηγούμενο run. Τίποτα δεν έσκασε. Το προφίλ κόστους όμως είναι άνισο.
| Θέμα | Input | Χαρακτήρες εξόδου | Διάμεσος χρόνος | Peak RSS Δ |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF 492 σελίδων) | 6.07 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σελιδο PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 γραμμές × 64 στήλες | 46 KB | 120,129 | 2.9 s | +22 MB |
Το PDF των 492 σελίδων του NIST χρειάστηκε διάμεσο χρόνο 192.5 δευτερολέπτων — περίπου 3.2 λεπτά, ή 0.39 s/σελίδα — επειδή το pdfplumber τρέχει ανίχνευση λέξεων και θέσεων σε κάθε σελίδα. Το peak RSS έμεινε στο +40 MB, άρα είναι CPU-bound, όχι memory-bound. Ακόμη και το arXiv PDF των 15 σελίδων χρειάστηκε 12.6 δευτερόλεπτα σε απομονωμένη διεργασία, περίπου 3.4 φορές πάνω από τα 3.7 δευτερόλεπτα που έδειξε το ίδιο αρχείο όταν τρέχτηκε warm μέσα στη δική μου δέσμη εγγράφων. Αυτή η διαφορά είναι το κόστος του cold process και επιβεβαιώνει ότι το per-page έργο είναι ο βασικός οδηγός, όχι το μέγεθος σε bytes. Αν θέλεις έναν μόνο μεταφέρσιμο αριθμό για αυτό το PDF, χρησιμοποίησε τα 12.6 s της απομονωμένης εκτέλεσης.
Η διαδρομή των spreadsheets αντιστρέφει το bottleneck. Ένα XLSX 2.1 MB με 50.000 γραμμές φούσκωσε σε +374 MB peak RSS (και 3.7 εκατομμύρια χαρακτήρες εξόδου), επειδή ο converter φορτώνει όλο το sheet και χτίζει μία μεγάλη συμβολοσειρά Markdown. Άρα η πρακτική σύσταση είναι ξεκάθαρη: για μεγάλα PDFs, υπολόγισε λεπτά CPU· για μεγάλα spreadsheets, υπολόγισε εκατοντάδες MB RAM. Αυτά είναι νούμερα από ένα μόνο μηχάνημα σε macOS arm64 και Python 3.14, και οι σταθερές ανά σελίδα και ανά γραμμή είναι πλατφορμοεξαρτώμενες — όμως το σχήμα (το PDF είναι αργό και CPU-bound, το XLSX είναι βαρύ σε μνήμη, τίποτα δεν κρασάρει) είναι αυτό που μεταφέρεται.
Πού ταιριάζει το Thunderbit — και πού όχι
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web
Αυτή είναι η μία σύγκριση που θα ήταν εύκολο να υπερβάλω, οπότε θα βάλω το όριο προσεκτικά. Το MarkItDown και το Thunderbit λύνουν γειτονικά προβλήματα, όχι το ίδιο.
Το MarkItDown μετατρέπει αρχεία που ήδη έχεις. Το Thunderbit φέρνει πρώτα τη σελίδα. Το /distill endpoint του Thunderbit μετατρέπει μια ζωντανή web page σε καθαρό Markdown έτοιμο για LLM — χειριζόμενο το rendering του JS, τα anti-bot εμπόδια και το δυναμικό περιεχόμενο που το MarkItDown δεν έχει μηχανισμό να αντιμετωπίσει — ενώ το /extract endpoint επιστρέφει δομημένο JSON που ταιριάζει σε schema, όχι απλώς raw Markdown. Για developers, αυτό είναι διαθέσιμο ως API (POST /distill / POST /extract), ως MCP server και ως CLI (npx @thunderbit/thunderbit-cli) πάνω σε μία AI engine, την ίδια που τροφοδοτεί το extension με 100.000+ χρήστες.
Άρα συμπίπτουν μόνο σε ένα πράγμα — και τα δύο μπορούν να δώσουν «LLM-ready Markdown» — αλλά το input domain είναι διαφορετικό: το distill του Thunderbit παίρνει μια URL στο ανοιχτό web, ενώ το MarkItDown παίρνει ένα τοπικό αρχείο. Δεν είναι drop-in ισοδύναμα, και δεν θα προσποιηθώ ότι είναι. Το ρεαλιστικό stack χρησιμοποιεί και τα δύο: fetch και crawl του web με Thunderbit (ή κάποιο Firecrawl-style service) και μετά κανονικοποίηση των τοπικών εγγράφων που έχεις επίσης — τα PDFs, τις παρουσιάσεις και τα spreadsheets — με το MarkItDown. Το ένα χειρίζεται το δίκτυο· το άλλο το ντουλάπι με τα αρχεία.
Πλεονεκτήματα και μειονεκτήματα
Πλεονεκτήματα
- Πλήρης ανάκτηση σώματος σε καθαρό HTML (4/4 σελίδες), με πιστή διατήρηση δέντρων επικεφαλίδων και συνδέσμων
- Υψηλή ανάκτηση κειμένου σε PDF/DOCX (arXiv 7/7 probes, Bitcoin 6/6) και καμία αθόρυβη απώλεια περιεχομένου στα δικά του Office fixtures
- Οι Office Math εξισώσεις διατηρούνται ως LaTeX — πραγματική, εξειδικευμένη νίκη
- Δεν κράσαρε σε κανένα subject της δοκιμής, μέχρι PDF 492 σελίδων και XLSX 50k γραμμών
- Πολύ εύκολο στη χρήση: CLI,
convert(), piping από stdin και προαιρετικό MCP server - MIT-licensed, ενεργά συντηρούμενο από τη Microsoft, με responsive issue tracker
Μειονεκτήματα
- Διατηρεί το boilerplate — έως 12.4% γραμμές chrome στη Wikipedia· δεν είναι article extractor
- Οι πίνακες χαλάνε με spans, nesting και pipes μέσα σε κελιά (2/13 χαλασμένοι, 4/13 «σχισμένοι»), και το rowspan ευθυγραμμίζει σιωπηλά λάθος τα δεδομένα
- Τα σαρωμένα/image-only PDFs επιστρέφουν κενή έξοδο χωρίς OCR και χωρίς σφάλμα
- Η έξοδος των PDFs δεν έχει δομή επικεφαλίδων (όπως δείχνουν και δημόσια benchmarks)
- 161 MB core installation με 73 MB ONNX runtime· ~3.35 s cold import
- Το
[all]extra κάνει αθόρυβα backtrack σε παλιά έκδοση 0.0.2 στην Python 3.14
Ποιοι να το χρησιμοποιήσουν και ποιοι όχι
Επίλεξε το MarkItDown αν τυποποιείς μια στοίβα από τοπικά έγγραφα — Word, Excel, PowerPoint, PDFs με text layer — σε Markdown για ένα LLM pipeline, και σε νοιάζει περισσότερο το πλήρες κείμενο παρά η διατηρημένη δομή. Ως last-mile converter σε batch job, που τροφοδοτεί ένα μοντέλο με καθαρό κείμενο, είναι γρήγορο, πιστό και δωρεάν.
Απόφευγέ το, ή συνδύασέ το με κάτι άλλο, αν η δουλειά σου είναι μία από τις παρακάτω: χρειάζεσαι μόνο το κύριο άρθρο από μια web page (χρησιμοποίησε readability ή Firecrawl-style tool)· χρειάζεσαι οι επικεφαλίδες και οι πίνακες ενός PDF να επιβιώσουν αυτούσιοι (εκεί ανήκει το Docling ή το Marker)· ή τα inputs σου περιλαμβάνουν σαρωμένα έγγραφα που απαιτούν OCR (θα χρειαστείς το Azure backend ή εντελώς διαφορετικό εργαλείο). Και αν νόμιζες ότι αγόραζες scraper — κάτι που fetchάρει και κάνει crawling — αυτό δεν είναι καθόλου αυτό.
Η προσωρινή βαθμολογία που έδωσα, με rubric τύπου scraper, καταλήγει το MarkItDown στο 60/100, και αυτό το χαμηλό σύνολο είναι αποτέλεσμα του ότι βαθμολογείς έναν converter με τεστ crawler. Στο δικό του πεδίο, οι βαθμοί πιστότητας κειμένου είναι υψηλοί· οι αδυναμίες του είναι δομικές (πίνακες, PDF headings) και σχετικές με το packaging (footprint, import, το [all] trap), όχι με την ποιότητα του κειμένου. Κρίνετέ το ως αυτό που είναι — file-to-Markdown converter — και θα δείτε ένα στιβαρό, καλά συντηρούμενο εργαλείο με μερικά αιχμηρά σημεία που καλό είναι να ξέρετε πριν το βάλετε σε production.
Συχνές ερωτήσεις
Είναι το MarkItDown web scraper;
Όχι. Δεν έχει crawler, δεν αποδίδει JavaScript, δεν ακολουθεί συνδέσμους και δεν κάνει pagination. Μετατρέπει αρχεία και έγγραφα που ήδη έχεις — PDF, DOCX, XLSX, PPTX, εικόνες, HTML — σε Markdown. Αν χρειάζεσαι να fetchάρεις και να κάνεις crawl ζωντανές web σελίδες, χρειάζεσαι ένα scraping εργαλείο όπως το Thunderbit ή το Firecrawl· το MarkItDown είναι το βήμα που ακολουθεί, μετατρέποντας τα fetched ή τοπικά αρχεία σε καθαρό Markdown.
Γιατί το pip install markitdown[all] εγκαθιστά παλιά έκδοση;
Στην Python 3.14, το [all] extra καρφιτσώνει το youtube-transcript-api~=1.0.0, και κάθε build σε αυτό το εύρος απαιτεί Python κάτω από 3.14. Ο resolver δεν μπορεί να ικανοποιήσει το pin, οπότε κάνει αθόρυβα backtrack στο markitdown 0.0.2, μια έκδοση δύο ετών. Η λύση είναι να καρφιτσώσεις την έκδοση και να εγκαταστήσεις τα extras ξεχωριστά: pip install 'markitdown==0.1.6', και μετά να προσθέσεις 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Αυτό παρακολουθείται ως issue #2179.
Κάνει το MarkItDown OCR σε σαρωμένα PDFs;
Όχι στη default εγκατάσταση. Η διαδρομή PDF είναι μόνο για text extraction, άρα ένα image-only PDF χωρίς text layer επιστρέφει κενή συμβολοσειρά — χωρίς σφάλμα, χωρίς προειδοποίηση. Το OCR απαιτεί το προαιρετικό Azure Document Intelligence backend ή κάποιο plugin, κανένα από τα οποία δεν περιλαμβάνεται by default. Αυτό είναι ένα κενό που παρακολουθείται εδώ και καιρό (issue #1268).
Πόσο καλά χειρίζεται το MarkItDown τους πίνακες;
Ως προς το περιεχόμενο, πολύ καλά — στη δοκιμή μου με 13 cases διατήρησε το 100% του περιεχομένου κάθε πίνακα. Δομικά, εξαρτάται από το σχήμα: απλοί πίνακες, πολύ πλατείς πίνακες, πίνακες χωρίς κεφαλίδα και με κενά κελιά βγαίνουν ως καθαρά GFM grids, αλλά τα rowspan και colspan βγαίνουν «σχισμένα» (και το rowspan μπορεί σιωπηλά να ευθυγραμμίσει λάθος τα δεδομένα στη λάθος στήλη), οι nested tables ισοπεδώνονται σε γραμμές-σκουπίδια και οι κυριολεκτικές κάθετες γραμμές μέσα σε κελιά δεν γίνονται escape. Η επίπεδη μορφή πίνακα του Markdown απλώς δεν μπορεί να αναπαραστήσει spans ή nesting.
Είναι το MarkItDown αρκετά γρήγορο για μεγάλα έγγραφα;
Δεν κρασάρει σε μεγάλα αρχεία, αλλά υπολόγισε πόρους ανά τύπο. Ένα PDF 492 σελίδων χρειάστηκε περίπου 3.2 λεπτά (περίπου 0.39 s/σελίδα) επειδή κάνει per-page form-detection, και είναι CPU-bound. Ένα spreadsheet 50.000 γραμμών ολοκληρώθηκε σε περίπου ένα λεπτό αλλά χρησιμοποίησε +374 MB RAM επειδή χτίζει μία μεγάλη συμβολοσειρά Markdown στη μνήμη. Για μεγάλα PDFs υπολόγισε λεπτά CPU· για μεγάλα spreadsheets υπολόγισε εκατοντάδες MB RAM.
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web Get Started Free
