Το MarkItDown συχνά μπαίνει στην ίδια κατηγορία με τα web scrapers — και αυτό είναι λάθος. Δεν έχει crawler, δεν διαθέτει μηχανή JavaScript και δεν μπορεί να πάρει ένα URL και να καθαρίσει το περιττό “boilerplate” περιεχόμενο. Αυτό που κάνει είναι να παίρνει bytes που ήδη έχεις — ένα PDF, ένα έγγραφο Word, ένα spreadsheet, μια παρουσίαση — και να τα μετατρέπει ολόκληρα σε Markdown που μπορεί να διαβάσει ένα language model.
Πέρασα μερικές εβδομάδες δοκιμάζοντας το MarkItDown της Microsoft πάνω σε πραγματικά έγγραφα, σε ένα μόνο Mac, βαθμολογώντας κάθε πίνακα με βάση ένα manifest που είχα γράψει πριν από την εκτέλεση και μετρώντας τον χρόνο κάθε μετατροπής. Η σύντομη εκδοχή: σε καθαρά αρχεία είναι γρήγορο και αξιόπιστο, το packaging του κρύβει ένα runtime machine learning 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, όχι rendering JS, όχι παρακολούθηση συνδέσμων, όχι pagination και όχι εξαγωγή κύριου περιεχομένου τύπου readability. Είναι μετατροπέας ολόκληρου εγγράφου. Εσύ του δίνεις τα bytes, κι αυτός τα μετατρέπει σε κοινόμορφη μορφή. Αυτή η διαφορά καθορίζει αν το εργαλείο χωράει στο stack σου ή όχι, γι’ αυτό θα επανέρχομαι σε αυτό το σημείο.
Το ίδιο το repo είναι βαρύ αν το δεις με τα γυαλιστερά metrics του GitHub — 165.282 stars και 11.790 forks στα μέσα Ιουλίου 2026, με άδεια MIT, και την πιο πρόσφατη έκδοση (v0.1.6) να έχει κυκλοφορήσει στις 2026-05-26. Όμως αυτό το πλήθος stars δείχνει περισσότερο την ορμή γύρω από τα LLM tooling projects της Microsoft παρά την ωριμότητα των εσωτερικών μηχανισμών μετατροπής. Υπάρχουν επίσης 833 ανοιχτά issues, και μερικά από αυτά αξίζει να τα ξέρεις πριν το εγκαταστήσεις (θα τα δούμε παρακάτω).
HTML σε Markdown: γρήγορα και πλήρως, με το boilerplate μέσα
Επειδή η υπόλοιπη σειρά αξιολόγησής μου για scrapers χρησιμοποιεί τα ίδια τέσσερα web fixtures, έδωσα στο MarkItDown ακριβώς τα ίδια τοπικά HTML αρχεία — όχι για να το βαθμολογήσω ως scraper, αλλά για να δω πόσο καλό είναι στη μετατροπή HTML σε Markdown. Σε σωστά δομημένες σελίδες είναι πραγματικά καλό.
Και οι τέσσερις σελίδες μετατράπηκαν με το βασικό install χωρίς πρόσθετα, και όλα τα probes του κύριου περιεχομένου πέρασαν. Το άρθρο της Wikipedia για το "Web scraping" (226 KB) διατήρησε σωστά τη δομή των επικεφαλίδων του — ένα h1, επτά h2 και δώδεκα h3, ακριβώς όπως η πραγματική δομή των ενοτήτων — και 418 links έμειναν ως σωστά [text](url). Ο πίνακας στατιστικών hockey 26×9 στη σελίδα Scrape This Site forms page έγινε καθαρός GFM pipe table 27 σειρών (κεφαλίδα + διαχωριστικό + 26 γραμμές δεδομένων), με όλα τα κενά κελιά στη θέση τους. Η ταχύτητα δεν ήταν πρόβλημα: διάμεσος 48 ms για τη μικρή σελίδα quotes έως 352 ms για το άρθρο της Wikipedia των 226 KB.
Το ζητούμενο εδώ, όμως, είναι μια συνειδητή επιλογή σχεδιασμού και όχι bug. Το MarkItDown δεν αφαιρεί το boilerplate. Μετατρέπει ολόκληρο το <body>, οπότε μαζί με το περιεχόμενο έρχεται και το site chrome — και αυτό μεγαλώνει όσο πιο “φορτωμένη” είναι η σελίδα.
| Σελίδα | Χαρακτήρες εξόδου | Επικεφαλίδες (h1/h2/h3) | Links | Γραμμές 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) |
Στην αρχική σελίδα του Books, που είναι σχεδόν χωρίς chrome, μόνο το 0,6% των γραμμών εξόδου είναι chrome. Στη Wikipedia, το ποσοστό ανεβαίνει στο 12,4% — 42 από τις 338 μη κενές γραμμές είναι πράγματα όπως «jump to content», «toggle the table of contents», «22 languages», «retrieved from», cookie footers και άδειες χρήσης. Τα maintenance banners της Wikipedia («This article needs additional citations») αποδίδονται πιστά ως δύο-column pipe tables, γι’ αυτό και εμφανίζονται εννέα table rows σε μια σελίδα χωρίς πραγματικό data table.
Τίποτα από αυτά δεν σημαίνει ότι το MarkItDown κάνει κάτι λάθος. Είναι μετατροπέας ολόκληρου εγγράφου, όχι εργαλείο εξαγωγής καθαρού άρθρου: η πιστή μετατροπή HTML σε Markdown είναι άλλη δουλειά από την καθαρή εξαγωγή άρθρου. Εργαλεία όπως το Trafilatura ή το Firecrawl στοχεύουν να επιστρέφουν μόνο το κύριο περιεχόμενο· το MarkItDown επιστρέφει ολόκληρη τη σελίδα. Εσωτερικά, το _html_converter.py αφαιρεί τα <script> και <style>, και μετά περνάει όλο το body στη βιβλιοθήκη markdownify — χωρίς κανέναν μηχανισμό εντοπισμού κύριου περιεχομένου. Αν θέλεις μόνο το άρθρο, αυτή δεν είναι η σωστή στρώση.
Το φυσικό του πεδίο: PDF, DOCX, XLSX, PPTX
Τα έγγραφα είναι ακριβώς αυτό για το οποίο φτιάχτηκε το MarkItDown. Το δοκίμασα σε πραγματικά δημόσια αρχεία — ένα arXiv paper με text layer, το Bitcoin whitepaper, ένα σαρωμένο PDF μόνο εικόνας που το έκανα render ώστε να μην έχει καθόλου κείμενο, και τα DOCX/XLSX/PPTX αρχεία από το test suite του ίδιου του MarkItDown (με UUIDs για να εντοπίζω τυχόν σιωπηλή απώλεια περιεχομένου).
| Έγγραφο | Είσοδος | Χαρακτήρες εξόδου | Probes | Διάμεσος χρόνος | Σημειώσεις |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF με text layer) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | title, "Transformer", "BLEU", "References" όλα παρόντα |
| Bitcoin whitepaper (PDF 9 σελίδων) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" παρόντα |
| Scanned 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 | markers αριθμού διαφάνειας, πίνακες, γράφημα → table |
Η ανάκτηση κειμένου στα PDFs με text layer ήταν εξαιρετική — 7 από 7 προ-καταγεγραμμένα probes στο paper του arXiv "Attention Is All You Need", 6 από 6 στο Bitcoin whitepaper — και κανένα από τα Office files δεν έχασε ούτε ένα UUID sentinel, άρα δεν υπήρξε σιωπηλή απώλεια περιεχομένου στα regression fixtures των maintainers. Μια ωραία, στοχευμένη νίκη: το DOCX path (μέσω mammoth) διατηρεί τις Office Math εξισώσεις ως LaTeX, μετατρέποντας το equations.docx σε πραγματικό $$...$$ math. Αν δίνεις σε LLM μαθηματικά-heavy Word έγγραφα, αυτό είναι μια ουσιαστική, αν και εξειδικευμένη, δύναμη που δεν βρήκα να έχει αναλυθεί αλλού.
Δύο ευρήματα σε αυτό το πεδίο χρειάζονται ξεχωριστή προσοχή, γιατί είναι αυτά που πιο πιθανό να σου δημιουργήσουν πρόβλημα.
Το σαρωμένο PDF που εξαφανίζεται
Δώσε στο MarkItDown ένα PDF μόνο εικόνας χωρίς text layer και θα επιστρέψει κενό string. Μηδέν χαρακτήρες, καμία εξαίρεση, καμία προειδοποίηση — και σε περίπου 15 ms, επειδή δεν υπάρχει τίποτα να εξαχθεί. Η διαδρομή PDF του MarkItDown κάνει μόνο text extraction (με pdfminer και pdfplumber από κάτω) και δεν περιλαμβάνει OCR ούτε στο βασικό install ούτε σε κανένα pip extra.
Αυτό έχει σημασία σε batch διαδικασίες. Αν ένας developer περάσει έναν φάκελο με PDF όπου κάποια είναι scans, θα πάρει σιωπηλά κενά αποτελέσματα γι’ αυτά τα αρχεία, χωρίς κανένα σήμα ότι κάτι παραλείφθηκε. Έλεγξα ότι το fixture δεν ήταν χαλασμένο τρέχοντας το extract_text του pdfminer απευθείας πάνω του — μηδέν stripped χαρακτήρες, χωρίς text layer, επιβεβαιωμένο — άρα η κενή έξοδος είναι η πραγματική συμπεριφορά του MarkItDown σε ένα πραγματικό scan. Αυτό αναπαράγει ένα χρόνιο κενό για OCR fallback (#1268) που παρακολουθείται upstream εδώ και καιρό. Η τεκμηριωμένη λύση είναι το προαιρετικό backend Azure Document Intelligence ή κάποιο plugin· κανένα από τα δύο δεν περιλαμβάνεται στο default install.
Τα PDFs βγαίνουν ως απλό κείμενο, όχι ως δομή
Και στα δύο PDFs με text layer, το MarkItDown δεν παρήγαγε κανένα Markdown heading marker. Ένα PDF δεν έχει semantic tags για headings, και το MarkItDown δεν τα συμπεραίνει από το μέγεθος της γραμματοσειράς, οπότε κάθε γραμμή καταλήγει στο επίπεδο σώματος κειμένου. Η ανάκτηση κειμένου είναι υψηλή· η δομή παραμένει επίπεδη.
Αυτό δεν είναι μόνο δικό μου αποτέλεσμα. Δημόσια benchmarks τρίτων βαθμολογούν το PDF heading hierarchy του MarkItDown περίπου στο 0.0 και την πιστότητα των πινάκων γύρω στο 0.27, πολύ κάτω από το 0.88 του Docling με TableFormer (δείτε τη σύγκριση MarkItDown vs Docling vs Marker και το READoc benchmark). Τα δικά μου fixtures αναπαράγουν τα δικά τους αποτελέσματα, κάτι που ενισχύει τα στοιχεία — οι αριθμοί μου συμφωνούν με εξωτερική πηγή. Η αντιστάθμιση που αναφέρουν τα ίδια benchmarks είναι ότι το MarkItDown τρέχει περίπου 100× πιο γρήγορα από το Docling, κάτι που ταιριάζει με τους χρόνους μου σε δευτερόλεπτα και όχι λεπτά, σε έγγραφα που ένα layout-model εργαλείο «μασάει» για λεπτά. Το συμπέρασμα: το MarkItDown σου δίνει καθαρό, γρήγορο PDF κείμενο· δεν σου δίνει τη δομή του PDF. Αν πρέπει να σωθούν headings και πίνακες, τότε χρειάζεσαι εργαλείο με layout model, όπως το Docling ή το Marker.
Πίνακες: το περιεχόμενο σώζεται πάντα, η δομή όχι πάντα
Οι πίνακες είναι το σημείο όπου τα ερωτήματα «έμεινε το κείμενο;» και «είναι χρήσιμα τα δεδομένα;» χωρίζουν τους δρόμους τους, οπότε έφτιαξα έναν πίνακα 13 περιπτώσεων — έναν <table> ανά case, με βαθμολόγηση απέναντι σε manifest γραμμένο πριν από την εκτέλεση — για να δω ακριβώς ποιες μορφές αντέχουν και ποιες σπάνε.
Το βασικό συμπέρασμα: το MarkItDown δεν έχασε ποτέ περιεχόμενο πινάκων. Και οι 13 περιπτώσεις διατήρησαν 100% των προ-καταγεγραμμένων tokens τους. Όμως η δομική πιστότητα χωρίστηκε σε τρεις κατηγορίες. Επτά από τις δεκατρείς παρήγαγαν σωστά διαμορφωμένο GFM grid (απλό, header-colspan, 24-column-wide, headerless, empty-cells, block-in-cell και right-to-left αραβικό). Τέσσερις βγήκαν ακατάστατοι, επειδή το Markdown δεν έχει έννοια για κελί που εκτείνεται σε άλλες γραμμές ή στήλες, άρα τα rowspan, colspan και τα κακοσχηματισμένα sources δίνουν κοντές γραμμές. Και δύο ήταν εντελώς σπασμένα.
Αυτές οι δύο αστοχίες αξίζει να ονομαστούν. Ένας nested table (<table> μέσα σε <td>) ισοπεδώνεται inline, ρίχνοντας τα δικά του pipes και τη γραμμή διαχωρισμού μέσα στο γονικό κελί και παράγοντας μια άχρηστη γραμμή 14 «στηλών». Και ένα κυριολεκτικό | μέσα σε κελί δεν γίνεται escape — κείμενο κελιού a | b γίνεται δύο στήλες, x || y γίνεται τρεις — οπότε ένας πίνακας δύο στηλών παράγει γραμμές δύο, τριών και τεσσάρων στηλών, και όποιος Markdown parser το διαβάσει μετά παίρνει λάθος όρια. Παράξενο, αλλά οι αστερίσκοι και τα backticks μέσα στα κελιά γίνονται escape· τα pipes απλώς όχι. Η βασική αιτία είναι ότι το HTML path του MarkItDown χρησιμοποιεί το default table handling του markdownify, ενώ η δική του custom subclass κάνει override στα links, τις εικόνες και τις επικεφαλίδες, αλλά όχι στα table cells. Η ίδια κατηγορία bug με το pipe escaping είναι και ανοιχτό issue για τον CSV converter (#2019), αν και εκείνη η διόρθωση δεν αγγίζει το HTML path που δοκίμασα.
Το πιο λεπτό — και αυτό που θα ήθελα περισσότερο να δει ένας data engineer — είναι το rowspan. Το case t03 δεν βγαίνει απλώς ακατάστατο· κάνει σιωπηλά λάθος στοίχιση δεδομένων. Μια ετικέτα rowspan=2 («Fruit») εμφανίζεται μία φορά, και η γραμμή από κάτω βγαίνει ως κοντή γραμμή δύο στηλών (| Banana | 8 |), οπότε το "Banana" καταλήγει κάτω από τη στήλη Group αντί για τη στήλη Item. Όλα τα tokens υπάρχουν. Ένας αφελής consumer που απλώς «διαβάζει τη δεύτερη στήλη» θα πάρει λάθος τιμή. Αυτό είναι το είδος bug που περνάει ένα text-survival check και αλλοιώνει αθόρυβα ένα dataset.
Το ίδιο το όριο των spans είναι γνωστό και καταγεγραμμένος περιορισμός σχεδιασμού (#1211, #1248) — ένα flat GFM pipe grid πραγματικά δεν μπορεί να αναπαραστήσει spans ή nesting, οπότε ο μετατροπέας θυσιάζει δομή για να κρατήσει το περιεχόμενο πλήρες. Υπάρχουν και καλά σημεία: οι πίνακες χωρίς header παίρνουν ένα συνθετικό κενό header row (ώστε να μην προωθηθεί σιωπηλά δεδομένο ως επικεφαλίδα), τα κενά κελιά διατηρούνται και το <caption> επιβιώνει ως γραμμή κειμένου πάνω από τον πίνακα.
Εγκατάσταση και εκκίνηση: το κόστος που δεν σου λέει ένα “ελαφρύ utility”
Πολλά πράγματα εδώ δεν με εξέπληξαν — αυτό όμως ναι, και είναι το σημείο όπου το framing «ελαφρύ Python utility» υπόσχεται περισσότερα από όσα δίνει.
Πρώτον, μην τρέξεις pip install 'markitdown[all]'. Στην Python 3.14 κάνει αθόρυβα backtrack στο markitdown 0.0.2 — έκδοση δύο ετών — κάτι που αναπαρήγαγα ζωντανά σε καθαρό venv. Το pin αποκαλύπτει το γιατί: το pip install 'markitdown[all]==0.1.6' αποτυγχάνει, επειδή το [all] extra κάνει pin το youtube-transcript-api~=1.0.0, και στο σημερινό PyPI κάθε build αυτής της σειράς επιτρέπεται μόνο για Python <3.14, ενώ τα μόνα compatible με 3.14 build βρίσκονται έξω από αυτό το pin. Έτσι ο resolver επιστρέφει όλη τη διαδρομή πίσω στην τελευταία έκδοση των οποίων οι εξαρτήσεις μπορούν να ικανοποιηθούν. Αυτό συμφωνεί με ένα ανοιχτό upstream issue (#2179). Η λύση είναι απλή — κάνε pin την έκδοση και εγκατάστησε τα extras ξεχωριστά: pip install 'markitdown==0.1.6', και μετά pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Όλα αυτά επιλύονται σωστά· μόνο το συνδυασμένο bundle [all] έχει το προβληματικό pin. (Αυτή η παγίδα εξαρτάται από την έκδοση της Python — σε Python 3.13 ή παλαιότερη το gate μπορεί να μη χτυπήσει, άρα το [all] να επιλυθεί διαφορετικά.)
Δεύτερον, το footprint. Το core install είναι 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 ήδη στο base install, πριν προσθέσεις έστω ένα extra για έγγραφα. Με τα document extras, το venv φτάνει τα 310 MB. Είναι πολύ ελαφρύτερο από ένα headless-browser stack, αλλά αν περίμενες ένα μικρό utility του τύπου «pip install και τέλος», να ξέρεις ότι κουβαλά και ONNX runtime.
Τρίτον — και αυτό είναι το μόνο εύρημα σε όλο το πακέτο μου που πέρασε όλα τα novelty checks που έτρεξα — ακόμη και μετά από καθαρή εγκατάσταση, το import markitdown κοστίζει περίπου 3,35 δευτερόλεπτα σε αυτό το μηχάνημα. Το κόστος εμφανίζεται σχεδόν όλο στο import time: το markitdown._markitdown φορτώνει πρόωρα όλο το converter registry (2,56 s αθροιστικά, 76% του συνόλου), το οποίο τραβάει μέσα pandas (594 ms, μέσω του XLSX converter), python-pptx (427 ms), magika (354 ms) και requests (270 ms) — είτε πρόκειται να μετατρέψεις αυτά τα formats είτε όχι. Για μια μακρόβια υπηρεσία, αυτό το import αποσβένεται και δεν έχει σημασία. Για ένα CLI invocation ή ένα serverless cold start, όμως, είναι πραγματικό κόστος ανά διεργασία που το label «lightweight utility» δεν σε προετοιμάζει να περιμένεις. (Δίκαιη επιφύλαξη: αυτό είναι ένα μόνο profiled run, άρα μία παρατήρηση και όχι κατανομή από πολλαπλά runs.)
Κλίμακα: δεν κρασάρει, αλλά θέλει CPU για PDFs και RAM για spreadsheets
Πέρασα τέσσερα μεγάλα subjects από μέσα του, το καθένα σε ξεχωριστή διεργασία ώστε η peak memory να μην επηρεαστεί από προηγούμενο run. Τίποτα δεν έσπασε. Το κόστος όμως είναι άνισο.
| Θέμα | Είσοδος | Χαρακτήρες εξόδου | Διάμεσος χρόνος | Peak 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 σελίδες PDF) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 γραμμές × 64 στήλες | 46 KB | 120,129 | 2.9 s | +22 MB |
Το 492σελιδο PDF του NIST πήρε διάμεσο 192,5 δευτερόλεπτα — περίπου 3,2 λεπτά, ή 0,39 s/σελίδα — επειδή το pdfplumber κάνει form-detection πάνω στη θέση των λέξεων σε κάθε σελίδα. Η peak RSS έμεινε στα +40 MB, άρα είναι CPU-bound και όχι memory-bound. Ακόμη και το 15σελιδο arXiv PDF χρειάστηκε 12,6 δευτερόλεπτα στο δικό του απομονωμένο process, περίπου 3,4× περισσότερο από τα 3,7 δευτερόλεπτα που έδειξε το ίδιο αρχείο σε warm εκτέλεση μέσα στη suite εγγράφων μου. Αυτή η διαφορά είναι το κόστος του cold process, και επιβεβαιώνει ότι η δουλειά ανά σελίδα είναι ο κύριος παράγοντας, όχι το ακατέργαστο μέγεθος του αρχείου. Αν θέλεις έναν μόνο μεταβιβάσιμο αριθμό για εκείνο το PDF, κράτα τα 12,6 s του isolated run.
Η διαδρομή των spreadsheets αντιστρέφει το bottleneck. Ένα XLSX 2,1 MB με 50.000 γραμμές φούσκωσε στα +374 MB peak RSS (και 3,7 εκατομμύρια χαρακτήρες εξόδου), επειδή ο converter φορτώνει ολόκληρο το sheet και χτίζει ένα τεράστιο Markdown string. Άρα η πρακτική οδηγία είναι απλή: για μεγάλα PDFs, υπολόγιζε λεπτά CPU· για μεγάλα spreadsheets, υπολόγιζε εκατοντάδες MB RAM. Αυτοί οι αριθμοί είναι από ένα Mac arm64 με Python 3.14 και είναι single-machine μετρήσεις — άρα τα constants ανά σελίδα και ανά γραμμή είναι εξαρτώμενα από την πλατφόρμα — αλλά το γενικό σχήμα (τα PDF είναι αργά και CPU-bound, τα XLSX είναι βαριά σε μνήμη, τίποτα δεν κρασάρει) είναι αυτό που μεταφέρεται.
Πού ταιριάζει το Thunderbit — και πού όχι
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web
Αυτή είναι η σύγκριση όπου θα ήταν εύκολο να το παρατραβήξω, οπότε θα χαράξω καθαρά τη γραμμή. Το MarkItDown και το Thunderbit λύνουν γειτονικά προβλήματα, όχι το ίδιο.
Το MarkItDown μετατρέπει αρχεία που ήδη έχεις. Το Thunderbit φέρνει πρώτα τη σελίδα. Το /distill endpoint του Thunderbit μετατρέπει μια ζωντανή web page σε καθαρό, LLM-ready Markdown — χειριζόμενο το rendering JS, τα anti-bot μέτρα και το δυναμικό περιεχόμενο που το MarkItDown δεν έχει τρόπο να επεξεργαστεί — ενώ το /extract endpoint του επιστρέφει structured 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» — αλλά το domain εισόδου είναι διαφορετικό: το distill του Thunderbit παίρνει ένα URL από τον ανοιχτό ιστό, ενώ το MarkItDown παίρνει ένα τοπικό αρχείο. Δεν είναι ισοδύναμα drop-in εργαλεία, και δεν θα προσποιηθώ το αντίθετο. Το ρεαλιστικό stack χρησιμοποιεί και τα δύο: κάνεις fetch και crawling στο web με Thunderbit (ή μια υπηρεσία τύπου Firecrawl), και μετά κανονικοποιείς τα μικτά τοπικά έγγραφα που έχεις επίσης — τα PDF, τα decks και τα spreadsheets — με το MarkItDown. Το ένα χειρίζεται το network· το άλλο το συρτάρι με τα αρχεία.
Πλεονεκτήματα και μειονεκτήματα
Δυνατά σημεία
- Πλήρης ανάκτηση σώματος κειμένου σε καθαρό HTML (4/4 σελίδες), με σωστή διατήρηση δέντρου επικεφαλίδων και links
- Υψηλή ανάκτηση κειμένου σε PDF/DOCX (arXiv 7/7 probes, Bitcoin 6/6) και καμία σιωπηλή απώλεια περιεχομένου στα Office fixtures των maintainers
- Οι Office Math εξισώσεις διατηρούνται ως LaTeX — πραγματικό, εξειδικευμένο πλεονέκτημα
- Δεν κρασάρει σε κανένα subject μεγάλης κλίμακας, μέχρι 492σελιδο PDF και XLSX 50k γραμμών
- Εύκολο στη χρήση: CLI,
convert(), stdin piping και προαιρετικό MCP server - Άδεια MIT, ενεργή συντήρηση από Microsoft, responsive issue tracker
Αδυναμίες
- Κρατάει το boilerplate — έως 12,4% γραμμές chrome στη Wikipedia· δεν είναι article extractor
- Οι πίνακες σπάνε σε spans, nesting και pipes μέσα σε κελιά (2/13 σπασμένοι, 4/13 ακατάστατοι), και το rowspan μπορεί να μεταφέρει σιωπηλά δεδομένα σε λάθος στήλη
- Τα σαρωμένα / μόνο-εικόνα PDFs επιστρέφουν κενή έξοδο χωρίς OCR και χωρίς σφάλμα
- Η έξοδος PDF δεν έχει καθόλου δομή επικεφαλίδων (σε συμφωνία με δημόσια benchmarks)
- Core install 161 MB με runtime ONNX 73 MB· περίπου 3,35 s cold import
- Το
[all]extra κάνει αθόρυβα backtrack στο 0.0.2 δύο ετών στην Python 3.14
Ποιοι πρέπει να το χρησιμοποιήσουν και ποιοι όχι
Επιλέξτε το MarkItDown αν θέλετε να τυποποιήσετε ένα σωρό μικτά τοπικά έγγραφα — Word, Excel, PowerPoint, PDF με text layer — σε Markdown για pipeline με LLM, και σας νοιάζει περισσότερο το πλήρες κείμενο παρά η διατηρημένη δομή. Ως τελευταίο βήμα μετατροπής σε batch job, για να δώσετε καθαρό κείμενο σε model, είναι γρήγορο, αξιόπιστο και δωρεάν.
Αποφύγετέ το, ή συνδυάστε το με κάτι άλλο, αν η δουλειά σας είναι ένα από τα εξής: θέλετε μόνο το κύριο άρθρο από μια web page (χρησιμοποιήστε εργαλείο readability ή τύπου Firecrawl), χρειάζεστε να σωθούν τα headings και οι πίνακες ενός PDF ανέπαφα (εκεί ανήκουν το Docling ή το Marker), ή τα inputs σας περιλαμβάνουν σαρωμένα έγγραφα που χρειάζονται OCR (θα χρειαστείτε το Azure backend ή εντελώς διαφορετικό εργαλείο). Και αν νομίζατε ότι ψάχνετε για scraper — κάτι που κάνει fetch και crawl — αυτό δεν είναι καθόλου αυτό.
Η προκαταρκτική βαθμολογία που έβγαλα, σε rubric φτιαγμένο για scraper, καταλήγει το MarkItDown στο 60/100, και αυτό το χαμηλό σύνολο είναι απλώς αποτέλεσμα του να βαθμολογείς έναν μετατροπέα με τεστ crawler. Στο φυσικό του πεδίο, οι βαθμολογίες πιστότητας κειμένου είναι υψηλές· οι αδυναμίες του είναι δομικές (πίνακες, headings σε PDF) και πακεταρίσματος (footprint, import, η παγίδα του [all]), όχι στην ποιότητα κειμένου. Αν το κρίνεις για αυτό που είναι — ένας μετατροπέας αρχείων σε Markdown — είναι ένα σταθερό, καλά συντηρημένο εργαλείο με μερικές αιχμηρές άκρες που αξίζει να γνωρίζεις πριν το βάλεις σε production.
Συχνές ερωτήσεις
Είναι το MarkItDown web scraper;
Όχι. Δεν έχει crawler, δεν κάνει rendering JavaScript, δεν ακολουθεί links και δεν υποστηρίζει pagination. Μετατρέπει αρχεία και έγγραφα που ήδη έχεις — PDF, DOCX, XLSX, PPTX, εικόνες, HTML — σε Markdown. Αν θέλεις να κάνεις fetch και crawl ζωντανές web pages, χρειάζεσαι εργαλείο scraping όπως το Thunderbit ή το Firecrawl· το MarkItDown είναι το επόμενο βήμα, όταν τα fetched ή τοπικά αρχεία πρέπει να γίνουν καθαρό Markdown.
Γιατί το pip install markitdown[all] εγκαθιστά παλιά έκδοση;
Στην Python 3.14, το [all] extra κάνει pin το youtube-transcript-api~=1.0.0, και κάθε build σε αυτή τη σειρά επιτρέπεται μόνο για Python εκδόσεις κάτω από 3.14. Ο resolver δεν μπορεί να ικανοποιήσει το pin, οπότε κάνει αθόρυβα backtrack στο markitdown 0.0.2, μια έκδοση δύο ετών. Η λύση είναι να κάνεις pin την έκδοση και να εγκαταστήσεις τα extras ξεχωριστά: pip install 'markitdown==0.1.6', και μετά να προσθέσεις 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Αυτό παρακολουθείται στο issue #2179.
Κάνει το MarkItDown OCR σε σαρωμένα PDFs;
Όχι στο default install. Η διαδρομή του PDF κάνει μόνο text extraction, οπότε ένα PDF μόνο εικόνας χωρίς text layer επιστρέφει κενό string — χωρίς σφάλμα, χωρίς προειδοποίηση. Το OCR απαιτεί το προαιρετικό backend Azure Document Intelligence ή κάποιο plugin, και κανένα από τα δύο δεν περιλαμβάνεται by default. Αυτό είναι ένα γνωστό κενό που παρακολουθείται εδώ και καιρό (issue #1268).
Πόσο καλά χειρίζεται το MarkItDown τους πίνακες;
Στο επίπεδο περιεχομένου, πολύ καλά — στη δική μου δοκιμή 13 περιπτώσεων κράτησε 100% του περιεχομένου σε κάθε case. Σε δομικό επίπεδο όμως εξαρτάται από το σχήμα: απλοί, μεγάλοι, χωρίς header και με κενά κελιά πίνακες βγαίνουν ως καθαρά GFM grids, αλλά τα rowspan και colspan γίνονται ακατάστατα (και το rowspan μπορεί να βάλει σιωπηλά δεδομένα σε λάθος στήλη), οι nested tables ισοπεδώνονται σε άχρηστες γραμμές και οι κυριολεκτικοί χαρακτήρες pipe μέσα σε κελιά δεν κάνουν escape. Το flat table format του Markdown απλώς δεν μπορεί να εκφράσει spans ή nesting.
Είναι το MarkItDown αρκετά γρήγορο για μεγάλα έγγραφα;
Δεν κρασάρει σε μεγάλα αρχεία, αλλά προϋπολόγισε πόρους ανά τύπο. Ένα PDF 492 σελίδων χρειάστηκε περίπου 3,2 λεπτά (περίπου 0,39 s/σελίδα) επειδή κάνει form detection ανά σελίδα, και είναι CPU-bound. Ένα spreadsheet 50.000 γραμμών τελείωσε σε περίπου ένα λεπτό αλλά χρησιμοποίησε +374 MB RAM, επειδή χτίζει ένα μεγάλο Markdown string στη μνήμη. Για μεγάλα PDFs να υπολογίζεις λεπτά CPU· για μεγάλα spreadsheets να υπολογίζεις εκατοντάδες MB RAM.
Δοκιμάστε το Thunderbit για εξαγωγή δεδομένων από το web Get Started Free
