html2text pesa 0,2 MiB e occupa un solo pacchetto. Inoltre è GPL-3.0.

html2text installa un solo pacchetto per un totale di 0,2 MiB — nove volte meno della più vicina alternativa Python e quaranta volte meno di quella Node. Ha completato tutte e quattro le pagine della suite di conversione e ha mantenuto tutti i 16 probe del corpo registrati. Questi probe verificano se specifiche stringhe del body sopravvivono; non valutano gerarchia, annidamento delle liste, destinazioni dei link, contenuti ripetuti o la fedeltà completa delle tabelle.

È inoltre distribuito con licenza GPL-3.0-or-later, l’unica caratteristica di questo confronto che non emerge da nessun benchmark e che può escludere del tutto una libreria.

Cos'è html2text

html2text è una libreria Python che trasforma l’HTML in testo semplice in stile Markdown. La sua storia risale all’implementazione originale di Aaron Swartz, e la linea attualmente mantenuta è alla versione 2025.4.15 — un rilascio datato aprile 2025, con 2.168 stelle su GitHub, 95 issue aperte e l’ultimo push a ottobre 2025.

Riferimento ufficiale: repository ufficiale di html2text.

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # vedi sotto; il valore predefinito ti sorprenderà
md = h.handle(html)

pip install html2text scarica 1 pacchetto e 0,2 MiB, con un cold import di 0,077 s. Nessuna dipendenza. In un’immagine container o in un layer Lambda, la differenza rispetto ai 1,8 MiB di markdownify e agli 8,8 MiB di turndown è tutt’altro che trascurabile.

Il valore predefinito che cambia tutti i numeri

body_width ha come valore predefinito 78. html2text va a capo forzatamente su ogni riga dell’output dopo 78 caratteri, a meno che tu non lo disattivi.

È una scelta sensata per una libreria nata per produrre testo leggibile su terminali e nelle email. È però la scelta sbagliata per qualunque flusso destinato a un modello o a un diff, dove i ritorni a capo inseriti cambiano la tokenizzazione, spezzano i link lunghi su più righe e rendono inutile il confronto dell’output.

Per tutto il resto dell’articolo ho impostato body_width = 0, e lo segnalo apertamente invece di nasconderlo: con il wrapping attivo, ogni conteggio di caratteri e token sarebbe diverso. Se fai benchmark sui convertitori, è questo il settaggio che può rendere silenziosamente incomparabili i tuoi numeri.

La misurazione

Ho eseguito html2text su una suite di conversione da quattro pagine, la stessa usata anche per il confronto con markitdown, con probe string pre-registrate — stringhe selezionate del corpo che devono sopravvivere e stringhe di boilerplate la cui presenza indica che è passato anche il chrome della pagina. Stessi quattro file, stessi probe, un unico sistema di scoring su tutti e quattro i convertitori. La sopravvivenza dei probe misura la presenza di stringhe registrate, non la correttezza strutturale; per questo le colonne relative alle tabelle e ai link sono separate.

fourway-scores.json. Quattro fixture, token contati con o200k_base.

Output più compatto dei quattro con 76.452 caratteri, e praticamente in pari sui token con markdownify e markitdown — 21.176 contro 21.062 e 21.336, uno scarto dell’1,3% che non definirei una differenza.

32 righe di tabella contro le 36 di markdownify e markitdown nella suite da quattro pagine. Il gap di quattro righe emerge nella fixture Wikipedia irregolare, non nella differenza di formattazione con pipe esterni descritta più avanti.

Meno link di tutti, 545, contro i 598–611 degli altri. Vale la pena confrontarlo con le tue pagine se la conservazione dei link è importante: è l’unica colonna in cui html2text si colloca nettamente sotto il gruppo, invece che al suo interno.

Le tabelle che la mia regex non vedeva

Vale la pena raccontare questo punto perché stavo per pubblicare una conclusione sbagliata.

Il mio primo contatore di righe delle tabelle richiedeva pipe iniziali e finali — ^\|.*\|$. Con quella regola, html2text risultava avere 1 sola riga di tabella su cinque file: la suite da quattro pagine più una fixture sintetica separata con tabella complessa. Quel contatore misurava uno stile Markdown, non le tabelle.

In realtà html2text genera tabelle in questo modo:

Team Name  |  Year  |  Wins  |  Losses  |  Win %
---|---|---|---|---
Boston Bruins  |  1990  |  44  |  24  |  0.55

Niente pipe esterni. È una sintassi pipe-table del tutto normale, ma il harness non la validava su diversi renderer Markdown. Una regex che si aspetta lo stile con pipe esterni non la vede. Riscrivendo il contatore in modo da cercare una sequenza di righe con pipe e una riga separatrice al loro interno, html2text è passato da 1 riga a 32 nella suite da quattro pagine e 91 su tutti e cinque i file.

Quindi il risultato non è che html2text non supporti le tabelle. Il punto è che due di questi quattro convertitori producono pipe esterni e uno no, e questo conta se poi elabori il Markdown con pattern matching personalizzato. È un dettaglio reale che avrei perso del tutto fidandomi del primo numero.

Cosa rimuove e dove perde righe

Due risultati che vanno in direzioni opposte.

Rimuove <script> e <style>. Contati tramite marker che compaiono solo all’interno di quegli elementi, l’output di html2text nelle fixture contiene zero marker script e zero marker style. Quello di turndown ne contiene 10 e 84 — nella fixture Wikipedia, otto righe di JavaScript inline di MediaWiki e CSS per un totale di 14.644 caratteri (script-style-stripping.json). Per output destinati a modelli, è stata la principale fonte osservata di testo evitabile su quella fixture. Non è stato misurato alcun costo downstream.

Perde righe di tabella sulla pagina difficile. La suite da quattro pagine si riconcilia così:

La fixture sintetica complessa separata aggiunge 59 righe per html2text e 62 per markdownify, portando i totali su cinque file a 91 e 98. Non fa parte del confronto principale delle quattro pagine. Sulla tabella pulita dell’hockey i due strumenti coincidono. Su Wikipedia, dove le tabelle sono annidate e irregolari, html2text produce cinque righe contro le nove di markdownify.

Il pattern, quindi, è questo: tabelle semplici, identiche; tabelle difficili, html2text perde più righe. Se le tue pagine contengono il tipo di tabelle che si vedono su Wikipedia, verifica prima di scegliere. Se invece contengono il tipo di tabelle di una pagina di statistiche, su questo aspetto i due sono intercambiabili.

La licenza

Riferimento ufficiale: html2text su PyPI.

Confermata in tre punti: i metadati su PyPI, il repository GitHub e il file METADATA del pacchetto installato, che riporta License-Expression: GPL-3.0-or-later.

Cosa significhi dipende da come il software viene integrato, distribuito e reso disponibile. L’uso interno o solo via rete è in genere uno scenario GPL diverso dallo shipping di software che include o combina il pacchetto, ma questo articolo non è un’analisi legale. I team che distribuiscono software dovrebbero far verificare da un legale il modello esatto di integrazione e distribuzione.

La parte scomoda è la correlazione. La libreria con il footprint più piccolo, quella che sceglieresti proprio perché vuoi mantenere piccolo un artefatto distribuibile, è anche quella con la licenza che limita di più la distribuzione. Le due alternative sono entrambe MIT.

Non sono un avvocato e questo non è un consiglio legale — è solo un fatto, documentato, perché è la proprietà che più probabilmente conta e meno probabilmente compare in una tabella di confronto.

Manutenzione

Ultimo rilascio 2025.4.15, ultimo push del repository a ottobre 2025 — circa dieci mesi prima del test, con 41 release alle spalle. requires_python >= 3.9, e il pacchetto si è installato ed eseguito senza problemi su Python 3.14.2.

È un ritmo più tranquillo di markdownify (ultimo rilascio sei settimane prima del test) e turndown (quattro mesi), ma molto più attivo di niente. Per una libreria che converte HTML in testo — un problema che cambia poco — un intervallo di dieci mesi suggerisce stabilità, non abbandono. Le 95 issue aperte sono il segnale più importante, e vale la pena scorrerle prima di adottarlo per vedere se c’è qualcosa di vicino al tuo caso d’uso.

Memoria e cosa fa l’HTML rotto

Qui misuriamo separatamente due domande operative.

Il contesto più ampio del test di stress è nel confronto su memoria e HTML malformato tra dieci librerie.

Picco di memoria residente, via /usr/bin/time -l, con un processo nuovo per ogni cella — il floor di import è il costo della libreria caricata e inattiva, i picchi includono il documento.

memory-results.json. I baseline Python e Node non sono confrontabili tra loro; l’interprete è presente in entrambi.

html2text è l’entry più leggera in entrambi gli assi misurati. Il suo floor di import di 18,7 MiB e il picco di 71,2 MiB sulla fixture da 10 MiB danno un RSS incrementale di 52,5 MiB: (71.2 - 18.7) / 10 = 5.25× la dimensione della fixture. Confrontalo con le righe assolute e incrementali della tabella, tenendo presente la nota di cautela sulle baseline Python/Node.

HTML malformato. Dodici documenti, ognuno rotto in modo diverso — tag non chiusi, elementi inline mal annidati, attributi senza virgolette con spazi, chiusure in eccesso, nessun <html> affatto, attributi duplicati, un documento troncato a metà tag, entità errate, un <script> non chiuso, una dichiarazione charset mendace, un commento che contiene markup e 600 livelli di annidamento — più due controlli ben formati di dimensioni corrispondenti, perché “non ha restituito nulla” dice qualcosa sulla malformazione solo se la libreria non tace anche su un documento pulito della stessa dimensione.

html2text ha sollevato un errore in 0 su 14 e non ha restituito nulla in 0, recuperando 33/33 sentinelle nelle fixture malformate (malformed-results.json). Una fixture è esclusa da questo conteggio: secondo HTML5 tutto ciò che viene dopo un <script> non chiuso è contenuto dello script, quindi perderlo lì è corretto e recuperarlo sarebbe la deviazione.

Pro e contro

A favore. Un solo pacchetto, 0,2 MiB, zero dipendenze — di gran lunga il più piccolo del confronto. Output più compatto dei quattro e praticamente pari sui token con markdownify e markitdown. Produce una sintassi riconoscibile per le tabelle pipe. Funziona su Python 3.14. Linea evolutiva lunga e stabile.

Contro. GPL-3.0-or-later, cosa che le alternative non hanno. body_width=78 come valore predefinito, che forza il wrapping e altera misurazioni o diff se non viene disattivato. Meno link preservati di tutti (545 contro 598–611). Le tabelle usano lo stile senza pipe esterni, che rompe regex naive a valle. Novantacinque issue aperte e un ritmo di rilascio più lento di markdownify.

Chi dovrebbe usarlo e chi no

Usa html2text quando il budget per le dipendenze è davvero limitato e il modello di integrazione e distribuzione previsto ha già superato la revisione della licenza. Un solo pacchetto senza dipendenze è un vantaggio operativo concreto: una superficie di dipendenze più piccola da controllare e distribuire.

Imposta body_width = 0 già alla prima riga, a meno che tu non voglia esplicitamente testo semplice con wrapping.

Evitalo se distribuisci software e il copyleft è un problema — markdownify è MIT, è alla pari sui token e qui eguaglia markitdown sulle tabelle con 1,6 MiB in più. Evitalo anche se per te la conservazione dei link è importante, visto che ne ha preservati meno di tutti. E evitalo se il tuo tooling downstream presume pipe esterni nelle righe di tabella.

Dove entra in gioco un’API gestita

html2text converte HTML che hai già. Non scarica contenuti, non esegue JavaScript e non gestisce livelli anti-bot — nessuno dei quattro convertitori lo fa, e su molti target reali quella è la metà più difficile del lavoro.

Per gli stessi fixture su tutti e cinque i convertitori, vedi il confronto HTML-to-Markdown a cinque vie.

Un servizio hosted di fetch/render/extraction, incluso il nostro Thunderbit, opera a un livello diverso. Thunderbit non è stato benchmarkato qui. Il confine rilevante è la conversione di HTML già fornito rispetto a un servizio che acquisisce ed elabora un URL; questo articolo non offre un confronto omogeneo su qualità, latenza o costi.

Il quadro corretto è questo: se hai già l’HTML, vuoi Markdown e la GPL non è un problema per il modo in cui distribuisci, html2text è gratuito e straordinariamente piccolo. Se invece devi acquisire pagine, o vuoi tabelle invece di prosa, stai acquistando un’altra cosa.

Per una visione più ampia del settore, il nostro rundown delle web scraping API copre le opzioni hosted e la guida pillar sugli scraper open source quelle self-hosted. Convertire HTML in Markdown in Python è la guida pratica.

Prova Thunderbit per l'estrazione di dati dal web

Dovresti usare html2text?

È un candidato forte quando il footprint conta, il wrapping viene disattivato di proposito e il modello di distribuzione supera la revisione della licenza.

Nel test da quattro pagine il suo numero di token è rimasto entro l’1,3% da markdownify e markitdown. Questo non significa che la qualità complessiva sia equivalente: html2text ha conservato meno link e meno righe nella fixture Wikipedia irregolare. Due dettagli operativi sono subito rilevanti: body_width = 0 e lo stile delle tabelle senza pipe esterni.

Se la revisione GPL lo esclude, markdownify è MIT, in questo test ha avuto dimensioni e token simili, ha mantenuto più link e più righe nelle tabelle irregolari, e ha richiesto 1,6 MiB in più su disco in questo ambiente.

Prova Thunderbit per l'estrazione di dati dal web Get Started Free

FAQ

html2text converte le tabelle? Sì. Il mio primo contatore diceva che produceva una sola riga di tabella su cinque file, ma quel contatore era sbagliato — richiedeva pipe iniziali e finali, mentre html2text emette Team Name | Year | Wins senza di essi. Questa è una normale sintassi Markdown per tabelle con pipe, anche se in questo harness non è stato eseguito un test di compatibilità tra renderer diversi. Con il contatore corretto, html2text ha prodotto 32 righe contro le 36 di markdownify nella suite da quattro pagine e 91 contro 98 includendo la fixture separata con tabella complessa.

Cosa fa body_width e perché cambiarlo? Per default forza il ritorno a capo a 78 caratteri, una scelta sensata per testo semplice leggibile da terminale e poco adatta a tutto il resto. Il wrapping inserisce newline a metà frase, spezza gli URL lunghi su più righe e cambia la tokenizzazione. Tutti i numeri di questa recensione usano body_width = 0; col valore predefinito sarebbero diversi.

La licenza GPL è un vincolo reale? Dipende dal modello esatto di integrazione e distribuzione. L’uso interno o solo via rete e la distribuzione del software sono scenari diversi, ma questo articolo non ne determina l’esito legale. I team che distribuiscono software dovrebbero far esaminare i termini GPL-3.0-or-later da un legale; markdownify e turndown sono MIT. L’espressione di licenza di html2text è confermata nei metadati PyPI, su GitHub e nel file METADATA del pacchetto installato.

Un rilascio di aprile 2025 è un problema? Probabilmente no, da solo. La conversione HTML-to-text è un problema stabile, la libreria si è installata ed eseguita correttamente su Python 3.14.2 e ha 41 release alle spalle. Le 95 issue aperte sono il numero che controllerei davvero — le esaminerei per trovare qualcosa di simile al mio input prima di adottarlo, perché un repository silenzioso spesso significa che potresti essere tu a doverlo sistemare.

Cosa non è stato testato qui? Quattro fixture di conversione e una fixture separata con tabella complessa sono comunque una suite piccola. Il test ha però coperto dodici documenti malformati sintetici più due controlli: html2text ha sollevato errori in 0/14, non ha restituito output vuoto in 0/14 e ha recuperato tutte le 33 sentinelle valutate. Non ha coperto pagine realmente danneggiate, pattern di malformazione più ampi, liste annidate, liste di definizione, note a piè di pagina o formule matematiche. L’intera superficie delle opzioni — ignore_links, ignore_images, unicode_snob, single_line_break e le altre — è rimasta ai valori predefiniti, a parte body_width. Il gap sui link è stato osservato ma non diagnosticato, e non è stato testato il round-tripping Markdown.