MarkItDown viene spesso messo nello stesso gruppo dei web scraper, ma è un errore. Non ha crawler, non ha un motore JavaScript e non può recuperare un URL per ripulirlo dal boilerplate. Quello che fa è prendere i byte che hai già — un PDF, un documento Word, un foglio di calcolo, una presentazione — e trasformarli interamente in Markdown leggibile da un language model.
Ho passato un paio di settimane a mettere alla prova MarkItDown di Microsoft con una serie di documenti reali su un unico Mac, confrontando ogni tabella con un manifest che avevo preparato prima dei test e misurando il tempo di ogni conversione. In sintesi: con input puliti è veloce e fedele, il packaging nasconde un runtime di machine learning da 73 MB che non hai mai chiesto, e le tabelle si rompono in modi che superano un controllo del tipo “il testo è rimasto?” ma falliscono un controllo del tipo “i dati sono finiti nella colonna giusta?”. Ecco il quadro completo, con i numeri.
Cos’è davvero MarkItDown
MarkItDown è un’utilità Python di Microsoft che converte file e documenti Office in Markdown ottimizzato per gli LLM. Se gli passi un PDF, un .docx, un .xlsx, un .pptx, un’immagine, un file HTML o altri formati supportati, ti restituisce Markdown. Si può usare in tre modi: da CLI (markitdown file.pdf -o out.md, oppure da stdin), tramite API Python (MarkItDown().convert(...)) e, opzionalmente, con un server MCP per workflow agentici.
Il punto più importante è ciò che non fa, perché non lo promette nel README e l’ho verificato nei test: niente crawling, niente rendering JS, niente follow dei link, niente paginazione e nessuna estrazione del contenuto principale in stile readability. È un convertitore dell’intero documento. Tu porti i byte; lui li normalizza. Questa distinzione decide se il tool ha senso nel tuo stack oppure no, quindi tornerò spesso su questo punto.
Il repository, in termini di metriche GitHub, è un colosso — 165.282 stelle e 11.790 fork a metà luglio 2026, licenza MIT, con l’ultima release (v0.1.6) uscita il 2026-05-26. Ma quel numero di stelle riflette l’entusiasmo generale per gli strumenti LLM, non la maturità del motore di conversione. Ci sono anche 833 issue aperte, e alcune ti interessano prima ancora di installarlo (più avanti ti spiego quali).
HTML in Markdown: veloce, completo, ma con tutto il boilerplate
Dato che il resto della mia serie di review sugli scraper usa sempre gli stessi quattro fixture web, ho dato a MarkItDown gli stessi file HTML locali — non per valutarlo come scraper, ma per capire quanto sia buono nella conversione HTML-to-Markdown. Su pagine ben strutturate, funziona davvero bene.
Tutte e quattro le pagine sono state convertite con l’installazione base, senza extra, e ogni probe sul corpo del contenuto è rimasto intatto. L’articolo di Wikipedia su "Web scraping" (226 KB) ha mantenuto perfettamente la gerarchia dei titoli — un h1, sette h2, dodici h3, in linea con la struttura reale della pagina — e 418 link sono rimasti come [testo](url). La tabella hockey-stats 25×9 della pagina Scrape This Site forms è diventata una tabella GFM pulita da 27 righe (intestazione + separatore + 26 righe di dati), con celle vuote comprese. Anche la velocità non è stata un problema: mediana di 48 ms per la pagina piccola delle citazioni fino a 352 ms per la pagina Wikipedia da 226 KB.
Ecco il limite, che però è una scelta progettuale e non un bug: MarkItDown non rimuove il boilerplate. Converte l’intero <body>, quindi si porta dietro anche lo scheletro del sito — e i residui aumentano quanto più la pagina è piena di chrome.
| Pagina | Caratteri in output | Titoli (h1/h2/h3) | Link | Righe di chrome del sito |
|---|---|---|---|---|
| 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) |
Sulla homepage di Books, praticamente senza chrome, solo lo 0,6% delle righe in output è chrome. Su Wikipedia si arriva al 12,4%: 42 delle 338 righe non vuote sono "vai al contenuto", "mostra/nascondi il sommario", "22 lingue", "estratto da", footer di cookie e licenza. Perfino i banner di manutenzione di Wikipedia ("This article needs additional citations") vengono resi fedelmente in tabelle pipe a due colonne, ed è da lì che arrivano nove righe di tabella in una pagina che non ha una vera tabella dati.
Niente di tutto questo significa che MarkItDown stia sbagliando. È un convertitore dell’intero documento, non un extractor basato su readability: fare una conversione fedele HTML-to-Markdown è un lavoro diverso dall’estrazione pulita di un articolo. Strumenti come Trafilatura o Firecrawl puntano a restituire solo il contenuto principale; MarkItDown restituisce la pagina. Sotto il cofano, il file _html_converter.py elimina <script> e <style>, poi passa l’intero body alla libreria markdownify — senza alcuna euristica per il contenuto principale. Se vuoi solo l’articolo, questo è il livello sbagliato.
Il suo terreno naturale: PDF, DOCX, XLSX, PPTX
I documenti sono il vero obiettivo di MarkItDown. L’ho testato su file pubblici reali: un paper arXiv con layer di testo, il whitepaper di Bitcoin, un PDF scannerizzato solo immagine che ho renderizzato in modo da non contenere testo, e i file DOCX/XLSX/PPTX della suite di test di MarkItDown (con UUID inseriti apposta per rilevare eventuali perdite silenziose di contenuto).
| Documento | Input | Caratteri in output | Probe | Tempo mediano | Note |
|---|---|---|---|---|---|
| arXiv 1706.03762 (PDF con layer di testo) | 2.2 MB | 40,174 | 7/7 | 3.7 s (warm) | titolo, "Transformer", "BLEU", "References" tutti presenti |
| Whitepaper Bitcoin (PDF 9 pagine) | 184 KB | 22,485 | 6/6 | 1.4 s | "Satoshi Nakamoto", "proof-of-work", "Conclusion" presenti |
| PDF scannerizzato (senza layer di testo) | 89 KB | 0 | 0/4 | 15 ms | output vuoto, nessun errore, nessun OCR |
| DOCX (test.docx) | 136 KB | 4,651 | — | 70 ms | titoli + tabella GFM; gli UUID incorporati restano |
| DOCX con equazioni | 15 KB | 240 | — | 101 ms | Office Math preservato come LaTeX |
| XLSX (test.xlsx) | 12 KB | 808 | — | 57 ms | ogni foglio → ## NomeFoglio + tabella GFM |
| PPTX (test.pptx) | 278 KB | 2,047 | — | 52 ms | marker dei numeri di slide, tabelle, grafico → tabella |
Il richiamo del testo nei PDF con layer testuale è stato eccellente — 7 su 7 probe pre-registrati sul paper arXiv "Attention Is All You Need", 6 su 6 sul whitepaper di Bitcoin — e nessuno dei file Office ha perso un solo UUID sentinella, quindi nessuna perdita silenziosa di contenuto nei fixture di regressione dei manutentori. Un buon risultato di nicchia: il percorso DOCX (tramite mammoth) preserva le equazioni Office Math come LaTeX, trasformando equations.docx in vero markup matematico $$...$$. Se stai passando documenti Word pieni di formule a un LLM, questa è una forza reale, anche se molto specifica, che non ho trovato documentata altrove.
Due risultati in quest’area meritano attenzione separata, perché sono quelli che più facilmente ti creeranno problemi.
Il PDF scannerizzato che sparisce
Se dai a MarkItDown un PDF composto solo da immagini, senza layer di testo, restituisce una stringa vuota. Zero caratteri, nessuna eccezione, nessun avviso — convertito in circa 15 ms perché non c’è nulla da estrarre. Il percorso PDF di MarkItDown è solo text-extraction (con pdfminer e pdfplumber sotto il cofano) e non include OCR, né nell’installazione base né in un extra pip.
Questo conta parecchio in batch. Se uno sviluppatore processa una cartella di PDF dove alcuni sono scansioni, quei file tornano silenziosamente vuoti senza alcun segnale che siano stati saltati. Ho verificato che il fixture non fosse rotto eseguendo direttamente extract_text di pdfminer sul file — zero caratteri estratti, nessun layer di testo, confermato — quindi l’output vuoto è il comportamento reale di MarkItDown su una scansione reale. Questo riproduce una lacuna OCR aperta da tempo (#1268) già tracciata upstream da parecchio. Il percorso documentato è il backend opzionale Azure Document Intelligence oppure un plugin; nessuno dei due è incluso nell’installazione predefinita.
I PDF escono come testo piatto, non come struttura
Su entrambi i PDF con layer di testo, MarkItDown non ha prodotto nessun marcatore di intestazione Markdown. Un PDF non contiene tag semantici di heading, e MarkItDown non inferisce la struttura dalla dimensione del font, quindi ogni riga finisce al livello del body. Il recupero del testo è alto; la struttura è piatta.
Non è solo una mia osservazione. Benchmark pubblici di terze parti assegnano a MarkItDown un punteggio di circa 0,0 per la gerarchia delle intestazioni PDF e di circa 0,27 per l’affidabilità delle tabelle, molto sotto lo 0,88 di Docling basato su TableFormer (vedi il confronto MarkItDown vs Docling vs Marker e il benchmark READoc). I miei fixture riproducono quei risultati, e questo rafforza la credibilità dell’evidenza: i miei numeri coincidono con una fonte esterna. Il trade-off riportato dagli stessi benchmark è che MarkItDown gira circa 100 volte più veloce di Docling, cosa che combacia con i miei tempi di pochi secondi invece che minuti su documenti che un tool basato su modelli di layout impiega diversi minuti a elaborare. In pratica: MarkItDown ti dà testo PDF pulito e veloce; non ti restituisce la struttura del PDF. Se titoli e tabelle devono restare intatti, il livello giusto è un tool di layout model come Docling o Marker.
Tabelle: il contenuto sopravvive sempre, la struttura no, a volte
Le tabelle sono il punto in cui “il testo è sopravvissuto?” e “i dati sono utilizzabili?” si separano, quindi ho costruito una matrice di 13 casi — una <table> per caso, ciascuna valutata contro un manifest scritto prima dell’esecuzione — per capire con precisione quali forme reggono e quali si rompono.
Il verdetto principale: MarkItDown non ha mai perso il contenuto delle tabelle. Tutti i 13 casi hanno mantenuto il 100% dei token pre-registrati. La fedeltà strutturale, però, si è divisa in tre gruppi. Sette casi su tredici hanno prodotto una griglia GFM ben formata (semplice, header-colspan, larga 24 colonne, senza intestazione, celle vuote, blocco dentro cella e arabo da destra a sinistra). Quattro sono diventati irregolari, perché Markdown non ha alcun concetto di cella spanned, quindi rowspan, colspan e sorgenti malformate producono righe corte. E due sono risultati completamente rotti.
Vale la pena nominare i due casi rotti. Una tabella annidata (una <table> dentro una <td>) viene appiattita inline, riversando i suoi pipe e la sua riga separatrice nella cella padre e producendo una riga di “colonne” spazzatura da 14 elementi. E un carattere | letterale dentro una cella non viene escapato — il testo a | b diventa due colonne, x || y diventa tre — così una tabella a due colonne genera righe da due, tre e quattro colonne, e qualsiasi parser Markdown a valle legge confini sbagliati. Curiosamente, gli asterischi e i backtick dentro la cella vengono escapati; i pipe no. La causa è che il percorso HTML di MarkItDown usa la gestione standard delle tabelle di markdownify, e la sua sottoclasse personalizzata sovrascrive link, immagini e heading ma non le celle tabella. La stessa classe di bug sui pipe è già oggetto di un issue aperto per il convertitore CSV (#2019), anche se quella correzione non tocca il percorso HTML che ho testato.
Il caso più sottile — quello che vorrei vedere da un data engineer — è il rowspan. Il caso t03 non si limita a diventare irregolare; misallinea i dati in modo silenzioso. Un’etichetta con rowspan=2 ("Fruit") viene emessa una sola volta, e la riga sotto diventa una riga corta da due colonne (| Banana | 8 |), quindi "Banana" finisce sotto la colonna Group invece che sotto Item. Tutti i token ci sono. Un consumatore ingenuo che legge “la seconda colonna” ottiene il valore sbagliato. È il classico bug che supera un controllo sulla sopravvivenza del testo e corrompe silenziosamente un dataset.
Il limite degli span in sé è una restrizione progettuale nota e tracciata (#1211, #1248): una griglia GFM piatta non può davvero rappresentare span o nesting, quindi il convertitore scambia struttura con completezza del contenuto. Ci sono anche comportamenti positivi: le tabelle senza intestazione ricevono una riga header vuota sintetica (così nessun dato viene promosso di nascosto a intestazione), le celle vuote vengono preservate e <caption> sopravvive come riga di testo sopra la tabella.
Installazione e startup: il costo che una “utility leggera” non ti avvisa di pagare
Nulla mi ha sorpreso più di questo, ed è qui che il framing da “utility Python leggera” finisce per promettere troppo senza dirlo.
Prima cosa: non eseguire pip install 'markitdown[all]'. Su Python 3.14, fa un fallback silenzioso a markitdown 0.0.2, una release di due anni fa, cosa che ho riprodotto in tempo reale in un venv pulito. Il motivo emerge se lo si fissa: pip install 'markitdown[all]==0.1.6' va in errore perché l’extra [all] blocca youtube-transcript-api~=1.0.0, e su PyPI tutte le build di quell’intervallo sono vincolate a Python <3.14, mentre le sole build compatibili con 3.14 cadono fuori dal pin. Il resolver allora torna indietro fino all’ultima release con dipendenze soddisfabili. Questo coincide con un issue upstream aperto (#2179). La soluzione è semplice: blocca la versione e installa gli extra separatamente: pip install 'markitdown==0.1.6', poi pip install 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. Ognuno di questi funziona correttamente; solo il bundle combinato [all] contiene il pin “avvelenato”. (Questo problema dipende dalla versione di Python — su Python 3.13 o precedente il vincolo potrebbe non scattare, quindi [all] potrebbe risolversi in modo diverso.)
Seconda cosa: il footprint. L’installazione core pesa 161 MB (un venv vuoto da 13 MB più 148 MB). Di questi, onnxruntime (73 MB) e numpy (34 MB) insieme fanno 107 MB — il 66% dell’intero footprint base — e sono trascinati dentro da una sola dipendenza rigida: magika, il rilevatore ML di tipo file di Google. Quindi un convertitore di testo si porta dietro, già nell’installazione base, un runtime ONNX da 73 MB prima ancora che tu aggiunga un solo extra per i documenti. Se aggiungi gli extra per i documenti, il venv arriva a 310 MB. È molto più leggero di uno stack browserless, ma se ti aspettavi una micro-utility da pip install e via, sappi che un runtime ONNX viaggia con lei.
Terza cosa — e questa è l’osservazione che, nel mio pacchetto di test, supera ogni filtro di novità che ho applicato — anche dopo un’installazione pulita, import markitdown costa circa 3,35 secondi su questa macchina. Il costo è quasi tutto all’import: markitdown._markitdown importa in anticipo l’intero registry dei converter (2,56 s cumulativi, il 76% del totale), che a sua volta carica pandas (1,21 s, tramite il converter XLSX), python-pptx (427 ms), magika (354 ms) e requests (270 ms), anche se poi non converterai mai quei formati. Per un servizio long-running questo import si ammortizza e non conta. Per una chiamata CLI o un cold start serverless, è una tassa reale per processo che l’etichetta “utility leggera” non ti fa aspettare. (Nota corretta: è un singolo run profilato, quindi va considerato un’osservazione, non una distribuzione multi-run.)
Scalabilità: non va in crash, ma per i PDF serve budget CPU e per i fogli di calcolo RAM
Ho spinto quattro soggetti di grandi dimensioni, ciascuno in un processo separato così che la memoria di picco non fosse contaminata da run precedenti. Nulla è andato in crash. Però il profilo dei costi è sbilanciato.
| Soggetto | Input | Caratteri in output | Tempo mediano | Δ RSS di picco |
|---|---|---|---|---|
| NIST SP 800-53r5 (PDF da 492 pagine) | 6.07 MB | 1,625,365 | 192.5 s | +40 MB |
| XLSX 50.000 righe × 8 colonne | 2.1 MB | 3,722,955 | 62.1 s | +374 MB |
| arXiv 1706.03762 (PDF di ~15 pagine) | 2.2 MB | 40,174 | 12.6 s | +25 MB |
| XLSX 200 righe × 64 colonne | 46 KB | 120,129 | 2.9 s | +22 MB |
Il PDF NIST da 492 pagine ha richiesto una mediana di 192,5 secondi — circa 3,2 minuti, cioè 0,39 s/pagina — perché pdfplumber esegue il rilevamento dei form sulle posizioni delle parole in ogni pagina. Il picco RSS è rimasto a +40 MB, quindi il collo di bottiglia è la CPU, non la memoria. Persino il PDF arXiv di 15 pagine ha richiesto 12,6 secondi nel suo processo isolato, circa 3,4 volte i 3,7 secondi visti in warm run dentro la mia suite documenti. Quel divario è il costo del processo a freddo e conferma che è il lavoro per pagina, non la dimensione grezza del file, a guidare i tempi. Se vuoi un unico numero trasferibile per quel PDF, usa i 12,6 s isolati.
Il percorso spreadsheet ribalta il collo di bottiglia. Un XLSX da 2,1 MB e 50.000 righe è esploso fino a +374 MB di RSS di picco (e 3,7 milioni di caratteri in output) perché il convertitore carica l’intero foglio e costruisce una stringa Markdown gigantesca. Quindi il consiglio pratico è brutale: per PDF grandi, metti in conto minuti di CPU; per fogli di calcolo grandi, metti in conto centinaia di MB di RAM. Questi sono numeri misurati su una singola macchina macOS arm64 con Python 3.14, e le costanti per pagina e per riga dipendono dalla piattaforma — ma la forma generale (PDF lento e legato alla CPU, XLSX pesante in memoria, nessun crash) è quella che conta davvero.
Dove si inserisce Thunderbit — e dove no
Prova Thunderbit per l’estrazione di dati dal web
Questo è il confronto in cui sarebbe facile esagerare, quindi traccio il confine con attenzione. MarkItDown e Thunderbit risolvono problemi vicini, ma non identici.
MarkItDown converte file che hai già. Thunderbit prima recupera la pagina. L’endpoint /distill di Thunderbit trasforma una pagina web live in Markdown pulito, pronto per gli LLM — gestendo rendering JS, anti-bot e contenuti dinamici che MarkItDown non è in grado di trattare — e l’endpoint /extract restituisce JSON strutturato allineato a uno schema, non solo Markdown grezzo. Per gli sviluppatori, tutto questo è disponibile come API (POST /distill / POST /extract), server MCP e CLI (npx @thunderbit/thunderbit-cli), tutti alimentati dallo stesso motore AI, lo stesso alla base dell’estensione con oltre 100.000 utenti.
Quindi si sovrappongono su un solo punto — entrambi possono produrre “Markdown pronto per LLM” — ma il dominio di input è diverso: il distill di Thunderbit prende un URL sul web aperto, mentre MarkItDown prende un file locale. Non sono equivalenti plug-and-play, e non farò finta che lo siano. Uno stack realistico li usa entrambi: fetch e crawling del web con Thunderbit (o un servizio in stile Firecrawl), poi normalizzazione dei documenti locali misti che hai già — PDF, deck e spreadsheet — con MarkItDown. Uno gestisce la rete; l’altro gestisce il cassetto dei file.
Pro e contro
Punti di forza
- Recupero completo del corpo su HTML pulito (4/4 pagine), con gerarchia dei titoli e link preservati fedelmente
- Elevato recupero del testo in PDF/DOCX (probe arXiv 7/7, Bitcoin 6/6) e nessuna perdita silenziosa di contenuto nei fixture Office dei manutentori
- Le equazioni Office Math vengono preservate come LaTeX — un vero vantaggio di nicchia
- Nessun crash su nessun soggetto testato, fino a un PDF da 492 pagine e un XLSX da 50k righe
- Semplicissimo da usare: CLI,
convert(), piping da stdin e server MCP opzionale - Licenza MIT, mantenuto attivamente da Microsoft, issue tracker reattivo
Punti deboli
- Mantiene il boilerplate — fino al 12,4% di righe di chrome su Wikipedia; non è un extractor di articoli
- Le tabelle si rompono con span, nesting e pipe dentro le celle (2/13 rotte, 4/13 irregolari), e il rowspan può allineare male i dati senza segnalarlo
- I PDF scannerizzati/solo immagine restituiscono output vuoto senza OCR e senza errore
- L’output dei PDF non ha struttura di heading (in linea con i benchmark pubblici)
- Installazione core da 161 MB con un runtime ONNX da 73 MB; cold import di circa 3,35 s
- L’extra
[all]fa backtracking silenzioso fino alla 0.0.2 di due anni fa su Python 3.14
Chi dovrebbe usarlo e chi no
Scegli MarkItDown se devi standardizzare una grande quantità di documenti locali misti — Word, Excel, PowerPoint, PDF con layer di testo — in Markdown per una pipeline LLM, e ti interessa più il testo completo che la struttura preservata. Come convertitore dell’ultimo miglio in un job batch, che porta testo pulito a un modello, è veloce, fedele e gratuito.
Evitalo, o affiancalo a un altro strumento, se il tuo lavoro è uno di questi: ti serve solo l’articolo principale da una pagina web (usa uno strumento readability o in stile Firecrawl); vuoi che titoli e tabelle di un PDF sopravvivano intatti (qui servono Docling o Marker); oppure i tuoi input includono documenti scannerizzati che richiedono OCR (ti servirà il backend Azure o uno strumento diverso). E se pensavi di comprare uno scraper — qualcosa che recupera e fa crawling — questo non lo è affatto.
Il punteggio provvisorio che ho assegnato, con una griglia pensata per uno scraper, è 60/100, e quel totale basso è il risultato di aver valutato un convertitore con un test da crawler. Sul suo terreno, i punteggi di fedeltà del testo sono alti; i suoi punti deboli sono strutturali (tabelle, heading nei PDF) e di packaging (footprint, import, trappola [all]), non la qualità del testo. Se lo giudichi per quello che è — un convertitore da file a Markdown — è uno strumento solido, ben mantenuto, con alcuni spigoli vivi che conviene conoscere prima di metterlo in produzione.
Domande frequenti
MarkItDown è un web scraper?
No. Non ha crawler, non rende JavaScript, non segue i link e non gestisce la paginazione. Converte file e documenti che hai già — PDF, DOCX, XLSX, PPTX, immagini, HTML — in Markdown. Se devi recuperare e fare crawling di pagine web live, ti serve uno strumento di scraping come Thunderbit o Firecrawl; MarkItDown è il passaggio successivo, quello che trasforma file già ottenuti o locali in Markdown pulito.
Perché pip install markitdown[all] installa una versione vecchia?
Su Python 3.14, l’extra [all] blocca youtube-transcript-api~=1.0.0, e tutte le build di quell’intervallo sono limitate a versioni di Python inferiori alla 3.14. Il resolver non riesce a soddisfare il pin, quindi torna silenziosamente a markitdown 0.0.2, una release di due anni fa. La soluzione è bloccare la versione e installare gli extra singolarmente: pip install 'markitdown==0.1.6', poi aggiungere 'markitdown[pdf,docx,pptx,xlsx,xls]==0.1.6'. La questione è tracciata in issue #2179.
MarkItDown fa OCR sui PDF scannerizzati?
Non nell’installazione predefinita. Il suo percorso PDF è solo text-extraction, quindi un PDF solo immagine senza layer di testo restituisce una stringa vuota — nessun errore, nessun avviso. L’OCR richiede il backend opzionale Azure Document Intelligence oppure un plugin, nessuno dei quali è incluso di default. È una lacuna tracciata da tempo (issue #1268).
Come gestisce le tabelle MarkItDown?
Sul contenuto, molto bene: nel mio test a 13 casi ha mantenuto il 100% del contenuto tabellare in ogni scenario. A livello strutturale, dipende dalla forma: tabelle semplici, larghe, senza intestazione e con celle vuote escono come griglie GFM pulite, ma rowspan e colspan diventano irregolari (e il rowspan può allineare silenziosamente i dati nella colonna sbagliata), le tabelle annidate vengono appiattite in righe spazzatura e i caratteri pipe letterali dentro le celle non vengono escapati. Il formato tabellare piatto di Markdown non può rappresentare span o nesting.
MarkItDown è abbastanza veloce per documenti grandi?
Non va in crash con file grandi, ma devi pianificare le risorse in base al tipo di file. Un PDF da 492 pagine ha richiesto circa 3,2 minuti (circa 0,39 s/pagina) perché esegue il rilevamento dei form per pagina, quindi è limitato dalla CPU. Un foglio di calcolo da 50.000 righe ha finito in circa un minuto, ma ha usato +374 MB di RAM perché costruisce in memoria una grande stringa Markdown. Per PDF grandi, pianifica minuti di CPU; per spreadsheet grandi, pianifica centinaia di MB di RAM.
Prova Thunderbit per l’estrazione di dati dal web Get Started Free
