html2text ne pèse que 0,2 MiB pour un seul package. Il est aussi sous GPL-3.0.

html2text s’installe en un seul package pour seulement 0,2 MiB — soit neuf fois moins que l’alternative Python la plus proche et quarante fois moins que l’option Node. Il a traité avec succès les quatre pages de la suite de conversion et conservé les 16 sondes de corps enregistrées. Ces sondes vérifient si certaines chaînes du corps survivent ; elles ne notent ni la hiérarchie, ni l’imbrication des listes, ni les destinations des liens, ni les contenus répétés, ni la fidélité complète des tableaux.

Il est aussi distribué sous licence GPL-3.0-or-later, ce qui est la seule caractéristique de cette comparaison qui n’apparaît dans aucun benchmark — et qui peut, à elle seule, écarter une bibliothèque.

Ce qu’est html2text

html2text est une bibliothèque Python qui convertit du HTML en texte brut proche du Markdown. La lignée remonte à la version originale d’Aaron Swartz, et la branche maintenue actuelle est à 2025.4.15 — une version datée d’avril 2025, avec 2 168 étoiles GitHub, 95 issues ouvertes et un dernier push en octobre 2025.

Référence officielle : le dépôt officiel de html2text.

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # voir ci-dessous ; la valeur par défaut peut surprendre
md = h.handle(html)

pip install html2text installe 1 package et 0,2 MiB, avec un cold import de 0,077 s. Zéro dépendance. Dans une image conteneur ou une Lambda layer, c’est une différence significative par rapport aux 1,8 MiB de markdownify et aux 8,8 MiB de turndown.

La valeur par défaut qui change tous les chiffres

body_width est réglé par défaut sur 78. html2text force un retour à la ligne tous les 78 caractères, sauf si vous le désactivez.

C’est un réglage raisonnable pour une bibliothèque conçue à l’origine pour produire du texte lisible dans un terminal ou dans des e-mails. C’est en revanche un mauvais choix pour tout usage destiné à un modèle ou à un diff, où les retours à la ligne ajoutés modifient la tokenisation, coupent les longs liens sur plusieurs lignes et rendent les comparaisons de sortie peu pertinentes.

J’ai réglé body_width = 0 pour tout ce qui suit, et je préfère le signaler explicitement : avec l’habillage activé, chaque comptage de caractères et de tokens de cet article serait différent. Si vous benchmarkez vous-même des convertisseurs, c’est ce paramètre qui peut rendre vos chiffres silencieusement incomparables.

La mesure

J’ai exécuté html2text sur une suite nommée de quatre pages, également utilisée pour la comparaison markitdown, avec des chaînes de sondes préenregistrées — des chaînes du corps sélectionnées qui doivent survivre, ainsi que des chaînes de gabarit dont la présence montre que le chrome de la page est bien passé. Les mêmes quatre fichiers, les mêmes sondes, un seul scoreur pour les quatre convertisseurs. La survie des sondes mesure la présence de chaînes enregistrées, pas la correction structurelle ; c’est précisément pour cela que les colonnes des tableaux et des liens sont séparées.

fourway-scores.json. Quatre fixtures, tokens comptés avec o200k_base.

La sortie la plus compacte des quatre avec 76 452 caractères, et pratiquement à égalité sur les tokens avec markdownify et markitdown — 21 176 contre 21 062 et 21 336, soit un écart de 1,3 % que je ne qualifierais pas de différence.

32 lignes de tableau contre 36 pour markdownify et markitdown dans la suite des quatre pages. L’écart de quatre lignes apparaît sur la fixture Wikipédia irrégulière, et non dans la différence de formatage avec barres externes décrite plus bas.

Le moins de liens, avec 545, contre 598 à 611 pour les autres. À vérifier sur vos propres pages si la préservation des liens compte — c’est la seule colonne où html2text se situe nettement en dessous du groupe, au lieu de se fondre dans celui-ci.

Les tableaux que ma regex ne voyait pas

Cela vaut la peine d’être raconté, parce que j’ai failli publier une conclusion erronée à ce sujet.

Mon premier compteur de lignes de tableau exigeait des barres verticales au début et à la fin — ^\|.*\|$. Avec cette règle, html2text n’obtenait que 1 ligne de tableau sur cinq fichiers : la suite de conversion des quatre pages plus une fixture synthétique séparée de tableau complexe. Ce compteur mesurait un style Markdown, pas les tableaux.

Il les émet ainsi :

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

Pas de barres externes. C’est une syntaxe classique de tableau à barres, mais le harness ne l’a pas validée sur plusieurs rendus Markdown. Elle est invisible pour une regex qui attend le style avec barres externes. En réécrivant le compteur pour rechercher une suite de lignes contenant des pipes avec une ligne de séparation à l’intérieur, html2text est passé de 1 ligne à 32 dans la suite des quatre pages et 91 sur les cinq fichiers.

La conclusion n’est donc pas qu’html2text n’a pas de tableaux. C’est que deux de ces quatre convertisseurs émettent des barres externes et un ne le fait pas, ce qui compte si vous post-traitez le Markdown avec vos propres motifs. C’est une information concrète, et je l’aurais complètement manquée en faisant confiance à mon premier chiffre.

Ce qu’il supprime, et où il perd des lignes

Deux constats qui tirent dans des directions opposées.

Il retire <script> et <style>. Mesuré via des marqueurs qui n’apparaissent que dans ces éléments, la sortie d’html2text sur les fixtures contient zéro marqueur de script et zéro marqueur de style. Celle de turndown en contient 10 et 84 — sur la fixture Wikipédia, huit lignes de configuration JavaScript inline de MediaWiki et de CSS, pour 14 644 caractères (script-style-stripping.json). Pour une sortie destinée à un modèle, c’était la plus grande source observée de texte évitable sur cette fixture. Aucun coût aval n’a été mesuré.

Il perd des lignes de tableau sur la page difficile. La suite de quatre pages se réconcilie ainsi :

La fixture synthétique séparée de tableau complexe ajoute 59 lignes pour html2text et 62 pour markdownify, portant le total sur cinq fichiers à 91 et 98. Elle ne fait pas partie du comparatif principal des quatre pages. Les deux outils sont d’accord sur le tableau de hockey, qui est propre. Sur Wikipédia, où les tableaux sont imbriqués et irréguliers, html2text produit cinq lignes contre neuf pour markdownify.

Le schéma est donc le suivant : tableaux simples, identiques ; tableaux difficiles, html2text en conserve moins. Si vos pages ressemblent à celles de Wikipédia, testez avant d’adopter. Si elles ressemblent à une page de statistiques, les deux sont interchangeables sur cet axe.

La licence

Référence officielle : html2text sur PyPI.

Confirmé à trois endroits : les métadonnées PyPI, le dépôt GitHub et le fichier METADATA du package installé, qui indique License-Expression: GPL-3.0-or-later.

Ce que cela implique dépend de la façon dont le logiciel est intégré, diffusé et redistribué. Un usage interne ou en réseau seul relève généralement d’un cadre GPL différent de celui d’un logiciel distribué qui inclut le package ou s’y combine, mais cet article n’est pas une analyse juridique. Les équipes qui distribuent du logiciel devraient faire relire le modèle exact d’intégration et de distribution par un conseil juridique.

Le point délicat, c’est la corrélation. La bibliothèque au plus petit empreinte, celle qu’on choisirait précisément pour garder un artefact distribuable léger, est aussi celle dont la licence contraint le plus la distribution. Les deux alternatives sont sous MIT.

Je ne suis pas juriste et ce n’est pas un conseil — simplement un fait, sourcé, parce que c’est la propriété la plus susceptible de compter et la moins susceptible d’apparaître dans un tableau comparatif.

Maintenance

Dernière publication 2025.4.15, dernier push du dépôt en octobre 2025 — environ dix mois avant le test, avec 41 releases derrière. requires_python >= 3.9, et l’installation comme l’exécution se sont faites proprement sur Python 3.14.2.

C’est plus discret que markdownify (dernière release six semaines avant le test) et turndown (quatre mois), tout en restant bien plus vivant que l’absence d’activité. Pour une bibliothèque qui convertit du HTML en texte — un problème qui évolue peu — un écart de dix mois ressemble davantage à de la stabilité qu’à un abandon. Les 95 issues ouvertes sont le vrai signal d’alerte, et méritent un coup d’œil pour tout ce qui ressemble à votre cas d’usage avant d’adopter.

Mémoire, et effet du HTML cassé

Deux questions d’exploitation sont mesurées séparément ici.

Le contexte du test de charge plus large se trouve dans la comparaison mémoire et HTML malformé sur dix bibliothèques.

Mémoire résidentielle maximale, via /usr/bin/time -l, un processus neuf par cellule — le plancher d’import correspond au coût de la bibliothèque chargée et idle, les pics incluent le document.

memory-results.json. Les bases Python et Node ne sont pas comparables entre elles ; l’interpréteur est inclus dans les deux.

html2text est l’entrée la plus légère ici sur les deux axes mesurés. Son plancher d’import de 18,7 MiB et son pic de 71,2 MiB sur la fixture de 10 MiB donnent un RSS incrémental de 52,5 MiB : (71,2 - 18,7) / 10 = 5,25× la taille de la fixture. À comparer avec les lignes absolues et incrémentales du tableau, en gardant à l’esprit l’avertissement de baseline Python/Node.

HTML cassé. Douze documents cassant chacun exactement une chose — balises non fermées, éléments inline mal imbriqués, attributs non quotés avec des espaces, fermetures parasites, absence totale de <html>, attributs en double, document tronqué au milieu d’une balise, entités invalides, <script> non fermé, déclaration de charset mensongère, commentaire contenant du balisage et 600 niveaux d’imbrication — plus deux contrôles bien formés de tailles identiques, parce que « il n’a rien renvoyé » ne dit quelque chose sur le malformé que si la bibliothèque reste aussi silencieuse sur un document propre de même taille.

html2text a levé une erreur sur 0 des 14 cas et n’a rien renvoyé sur 0, en récupérant 33/33 marqueurs sur les fixtures cassées (malformed-results.json). Une fixture est exclue de ce total : selon HTML5, tout ce qui suit un <script> non fermé est du contenu script, donc le perdre est correct et le récupérer serait une déviation.

Avantages et inconvénients

En sa faveur. Un package, 0,2 MiB, zéro dépendance — de loin le plus petit de la comparaison. La sortie la plus compacte des quatre et pratiquement à égalité sur les tokens avec markdownify et markitdown. Produit une syntaxe de tableau à barres reconnaissable. Fonctionne sur Python 3.14. Lignée longue et stable.

Contre lui. GPL-3.0-or-later, contrairement aux alternatives. body_width=78 par défaut, ce qui force des retours à la ligne et change les mesures ou les diffs sauf désactivation. Moins de liens conservés (545 contre 598–611). Les tableaux utilisent le style sans barres externes, ce qui casse les regex aval naïves. Quatre-vingt-quinze issues ouvertes et un rythme de publication plus calme que markdownify.

Qui devrait l’utiliser, et qui ne devrait pas

Utilisez html2text lorsque le budget de dépendances est réellement serré et que le modèle d’intégration et de distribution prévu a passé la revue de licence. Un seul package sans dépendance, c’est un avantage opérationnel réel : une surface de dépendances plus petite à auditer et à déployer.

Réglez body_width = 0 dès la première ligne, sauf si vous voulez explicitement du texte brut avec retour à la ligne.

Passez votre chemin si vous distribuez du logiciel et que le copyleft pose problème — markdownify est sous MIT, égalise html2text sur les tokens et fait jeu égal avec markitdown sur les tableaux pour 1,6 MiB de plus. Passez aussi votre chemin si la préservation des liens est importante pour vous, puisqu’il en a conservé le moins. Et abstenez-vous si vos outils aval supposent des barres externes sur les lignes de tableau.

Où une API managée trouve sa place

html2text convertit du HTML que vous possédez déjà. Il ne va pas chercher les pages, n’exécute pas JavaScript et ne gère pas une couche anti-bot — aucun des quatre convertisseurs ne le fait, et sur beaucoup de cibles réelles, c’est la moitié la plus difficile du travail.

Pour les mêmes fixtures sur les cinq convertisseurs, voir la comparaison HTML vers Markdown en cinq voies.

Un service hébergé de fetch/rendu/extraction, y compris notre Thunderbit, opère à un autre niveau. Thunderbit n’a pas été benchmarké ici. La frontière pertinente est celle entre la conversion d’un HTML fourni et un service qui récupère et traite une URL ; cet article ne propose aucune comparaison de qualité, de latence ou de coût sur une base identique.

Le cadrage honnête : si vous avez le HTML, que vous voulez du Markdown, et que la GPL ne pose pas de problème pour votre mode de diffusion, html2text est gratuit et remarquablement compact. Si vous devez récupérer les pages, ou si vous voulez des lignes plutôt que de la prose, c’est un autre achat.

Pour un panorama plus large, notre tour d’horizon des API de web scraping couvre les options hébergées, et le pilier des scrapers open source couvre les solutions auto-hébergées. Convertir du HTML en Markdown en Python est le guide pratique.

Essayez Thunderbit pour l’extraction de données web

Faut-il utiliser html2text ?

C’est un bon candidat lorsque l’empreinte compte, que l’habillage est désactivé volontairement et que le modèle de distribution a passé la revue de licence.

Son nombre de tokens était à moins de 1,3 % de markdownify et markitdown dans la suite des quatre pages. Cela ne signifie pas que la qualité globale soit équivalente : html2text a conservé moins de liens et moins de lignes sur la fixture Wikipédia irrégulière. Deux détails d’exploitation comptent immédiatement : body_width = 0 et le style de tableau sans barres externes.

Si la revue GPL l’écarte, markdownify est sous MIT, affichait ici une taille de sortie et un nombre de tokens similaires, conservait davantage de liens et de lignes de tableaux irréguliers, et occupait 1,6 MiB de plus sur ce système.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

html2text convertit-il les tableaux ? Oui. Mon premier compteur m’avait dit qu’il produisait une seule ligne de tableau sur cinq fichiers, et ce compteur était faux — il exigeait des barres au début et à la fin, alors que html2text émet Team Name | Year | Wins sans elles. C’est du Markdown classique de tableau à barres, même si ce harness n’a pas exécuté de test de compatibilité entre plusieurs rendus. Avec le compteur corrigé, html2text a produit 32 lignes contre 36 pour markdownify dans la suite des quatre pages, et 91 contre 98 lorsqu’on ajoute la fixture séparée de tableau complexe.

Que fait body_width, et pourquoi le modifier ? Il force par défaut des retours à la ligne tous les 78 caractères, un choix cohérent pour du texte lisible en terminal et mauvais pour presque tout le reste. L’habillage insère des sauts de ligne au milieu des phrases, coupe les longues URL sur plusieurs lignes et modifie la tokenisation. Tous les chiffres de cet article utilisent body_width = 0 ; avec la valeur par défaut, ils seraient tous différents.

La licence GPL est-elle une vraie contrainte ? Cela dépend du modèle exact d’intégration et de distribution. L’usage interne ou en réseau seul, et la redistribution de logiciel, sont des situations de contrôle différentes, mais cet article ne tranche pas leur issue juridique. Les équipes qui distribuent du logiciel devraient faire vérifier les termes GPL-3.0-or-later par un conseil juridique ; markdownify et turndown sont sous MIT. L’expression de licence d’html2text est confirmée dans les métadonnées PyPI, GitHub et le fichier METADATA du package installé.

Une version d’avril 2025 est-elle un problème ? Probablement pas, en soi. La conversion HTML vers texte est un problème stable, la bibliothèque s’est installée et a fonctionné proprement sur Python 3.14.2, et 41 versions la précèdent. Les 95 issues ouvertes sont le chiffre que je regarderais vraiment — parcourez-les pour tout ce qui ressemble à votre entrée avant d’adopter, car un dépôt calme peut signifier que vous serez celui qui devra corriger.

Qu’est-ce qui n’a pas été testé ici ? Quatre fixtures de conversion et une fixture séparée de tableau complexe restent une suite assez réduite. Le test a bien couvert douze documents malformés synthétiques plus deux contrôles : html2text a levé 0/14, a renvoyé 0/14 vide et a récupéré les 33 marqueurs scorés. Il ne couvre pas les pages abîmées du monde réel, des patterns malformés plus variés, les listes imbriquées, les listes de définitions, les notes de bas de page ou les formules. L’ensemble des options — ignore_links, ignore_images, unicode_snob, single_line_break et les autres — est resté à ses valeurs par défaut, sauf body_width. L’écart sur les liens a été observé mais pas diagnostiqué, et la réversibilité Markdown n’a pas été testée.