Convertisseur de HTML en texte

Par Bogdan Sandu (EN) · Publié 9 juin 2025 · Dernière mise à jour 13 septembre 2026

Transformez du code HTML en texte propre et lisible. Ce convertisseur léger de HTML en texte traite votre balisage avec l’analyseur HTML du navigateur, supprime les balises et restitue le texte qu’elles contiennent.

Ce que l'outil fait :

• Supprime toutes les balises HTML et les blocs <script>, <iframe>, <object> et <embed> ainsi que leur contenu
• Décode les entités comme &,   et – en caractères réels
• Conserve les sauts de ligne de votre source, donc le HTML écrit un élément par ligne reste lisible
• Accepte jusqu'à 500 Ko de balisage par conversion
• Fonctionne entièrement dans votre navigateur : rien n'est téléchargé, rien n'est stocké

Comment utiliser ce convertisseur HTML en texte

1. Collez votre code HTML dans la zone supérieure
2. Cliquez sur Convertir en texte
3. Vérifiez le texte brut dans la zone inférieure
4. Cliquez sur Copier le résultat pour le saisir, ou Effacer pour recommencer

Un rapide avant et après :

<h2>Order &amp; shipping</h2>
<p>Ships in <strong>2&ndash;3 days</strong>.</p>
<ul>
  <li>Free returns</li>
  <li>Tracked delivery</li>
</ul>

Order & shipping
Ships in 2–3 days.

  Free returns
  Tracked delivery

Deux choses à savoir avant de coller : le HTML minifié sans sauts de ligne apparaît comme une longue ligne, et les blocs <style> ne sont pas supprimés, donc supprimez-les d'abord si votre source contient du CSS en ligne. Pour tout ce qui va au-delà d'un seul document, la section bibliothèque plus bas est la meilleure voie.

Travaux typiques : créer une alternative en texte brut pour un e-mail HTML, extraire une copie lisible des pages récupérées, nettoyer le contenu avant une migration vers un CMS ou introduire du texte propre dans un pipeline NLP.

Qu'est-ce qu'un convertisseur HTML en texte

Un convertisseur HTML en texte est un utilitaire logiciel qui supprime le balisage, les balises et les entités encodées d'un document tout en conservant le texte lisible en dessous.

Il fonctionne sur la source brute d'une page ou d'un fichier, pas sur une capture d'écran rendue.

La sortie est du texte brut. Pas de formatage, pas de style, rien dont un navigateur aurait besoin pour dessiner une mise en page.

Les gens confondent cela avec quelques autres choses qu'il n'est pas.

• Pas un rendu. Un renderer dessine la page visuellement, ceci élimine entièrement la couche visuelle
• Pas un outil de capture d'écran. Il n'y a pas d'image, seulement des caractères
• Pas un moteur OCR. L'OCR lit les pixels, un convertisseur HTML en texte lit le balisage qui contient déjà du texte

La valeur apparaît partout où le balisage brut doit devenir quelque chose qu’un humain, un script ou un pipeline d’apprentissage automatique peut réellement utiliser.

Mailchimp génère automatiquement une version en texte brut de chaque campagne d'email HTML envoyée via sa plateforme. Il existe principalement pour les boîtes de réception et les clients de messagerie qui rejettent le formatage enrichi.

Ce cas d’utilisation unique (contenu de secours d’e-mail) est l’un des dizaines où le même processus sous-jacent s’applique.

HTML vers Texte vs HTML vers Markdown

La sortie en texte brut ne conserve que les mots. La sortie Markdown conserve les mots ainsi qu'une version allégée de la structure, des titres, des caractères gras, des liens et des listes rendus sous forme de symboles au lieu de balises.

Les deux cibles résolvent des problèmes différents, et choisir la mauvaise cause des maux de tête plus tard.

Ce que le texte brut garde :

• Phrases, paragraphes et texte brut
• Rien d'autre. Pas d'emphase, pas de niveaux de titre, pas de syntaxe de lien

Ce que Markdown garde :

• Tout ce que le texte brut garde
• Niveaux de rubriques marqués par des symboles de hachage
• Marqueurs gras et italiques, listes à puces et syntaxe de lien

Pandoc (EN), le convertisseur de documents open-source largement utilisé, les traite comme deux formats de sortie distincts plutôt que des variations de la même chose.

Choisissez du texte brut pour les index de recherche, les filtres anti-spam et les pipelines NLP qui ne se soucient que des mots.

Choisissez Markdown pour les systèmes de documentation, les générateurs de sites statiques, ou partout où la structure doit survivre au voyage.

Si vous avez besoin de la direction inverse, de retourner Markdown en HTML, un Markdown to HTML tool dédié gère cette conversion à la place.

Comment fonctionne un convertisseur HTML en texte

Chaque convertisseur exécute la même séquence approximative : charger le balisage, supprimer les balises, décoder les entités, nettoyer les espaces, renvoyer le texte.

Les détails de chaque étape varient beaucoup entre les outils, et ces détails décident si la sortie est utilisable ou déformée.

Extraction basée sur l'analyseur vs extraction basée sur Regex

L'extraction basée sur Regex fait correspondre les modèles de balises avec des expressions régulières et supprime tout ce qui ressemble à une balise.

Il est rapide et simple, et il se casse sur des balises imbriquées ou mal formé HTML plus souvent que les gens s'y attendent.

Extraction par analyseur : construit d'abord un véritable arbre de modèle d'objet de document à partir du balisage, puis parcourt cet arbre pour extraire les nœuds de texte.

Extraction basée sur Regex : ignore entièrement l'arborescence et traite l'ensemble du document comme une chaîne avec laquelle effectuer une correspondance de modèle.

Readability.js (EN) de Mozilla, la bibliothèque derrière la vue de lecteur de Firefox, utilise l'analyse DOM complète plutôt que la correspondance d'expression régulière. C'est en partie pourquoi il survit aux pages en désordre du monde réel que les outils à expressions régulières étouffent.

Décodage d'entité

Conversions d'entités communes :

• & devient un et
•   devient un espace vide
• < et > deviennent les caractères moins-que et plus-que

Un convertisseur doit inverser cet encodage, sinon la sortie est pleine de codes d'entités littéraux au lieu des caractères qu'ils représentent.

Décoder deux fois la même entité corrompt le texte au lieu de le réparer, ce qui est un échec plus courant que la plupart des gens ne le pensent.

Whitespace Normalisation

Le HTML brut est plein d'espaces blancs qui ne signifient rien pour un navigateur et ressembleraient au chaos en texte brut.

L'indentation, les tabulations et les sauts de ligne dans la source sont réduits, car le navigateur ignore déjà la plupart d'entre eux lors du rendu.

• Plusieurs espaces consécutifs s'effondrent en un seul
• Les sauts de ligne à l'intérieur d'une seule balise de paragraphe sont supprimés ou remplacés par un espace
• Les sauts entre les éléments de niveau bloc (paragraphes, divs, éléments de liste) sont conservés sous forme de sauts de ligne réels

Formats d'entrée et encodages de caractères pris en charge

Un convertisseur doit identifier correctement deux choses avant de toucher le contenu : la version du balisage et l'encodage des caractères.

Si vous vous trompez, la sortie se transformera en symboles déformés au lieu de texte lisible.

Adoption du codage et du balisage :

• UTF-8 encode 98.5% de tous les sites web suivis par W3Techs (EN), ce qui en fait l'hypothèse par défaut pour tout convertisseur moderne
• HTML5 est le langage de balisage derrière 95,7% des sites web actuellement en ligne, selon la même enquête (EN)
• L’ISO-8859-1, l’encodage le plus répandu après l’UTF-8, n’est utilisé que par 1,1 % des sites. Cet écart est suffisamment grand pour que la plupart des outils le traitent comme une solution de rechange plutôt que comme une cible.

Les documents XHTML suivent les règles de syntaxe plus strictes du XML (EN), ce qui signifie que chaque balise doit se fermer correctement, sinon l'analyse échoue complètement.

Les sections CDATA se trouvent à l'intérieur du balisage spécifiquement pour contenir du contenu qu'un analyseur ne devrait pas toucher. Les blocs de script et les données en ligne sont des exemples courants, et un convertisseur est censé les ignorer plutôt que d'extraire leur contenu brut en tant que texte lisible.

Un HTML mal formé (balises non fermées, imbrication incorrecte) est la raison la plus courante pour laquelle un convertisseur produit une sortie brisée ou incomplète. Cela vaut la peine de tester avant de faire confiance à un outil avec du contenu de production.

Comment les liens, les tableaux et les listes sont gérés en texte brut

Les éléments HTML structurels ne survivent pas au passage au texte brut de la même manière.

Chacun d'eux est aplati selon les règles définies par le convertisseur, et ces règles diffèrent d'un outil à l'autre.

Trois résultats pour un hyperlien :

• Supprimé entièrement, seul le texte du lien reste
• Inline, l'URL apparaît juste à côté du texte entre parenthèses ou crochets
• Converti en note de bas de page, avec une référence numérotée dans le corps et l'URL complète répertoriée séparément

Les tableaux perdent leur grille visuelle au moment où ils deviennent du texte brut.

Les lignes deviennent généralement des lignes et les colonnes d'une ligne sont séparées par des espaces ou des tabulations. Cela fonctionne pour les tables étroites et devient illisible rapidement pour les tables larges.

Si vous avez besoin des lignes extraites dans un fichier structuré par la suite, exécutez cette même table via un convertisseur table to CSV (EN) dédié. Il conserve les lignes et les colonnes intactes au lieu de les réduire en texte en vrac.

Les listes se portent mieux que les tableaux.

• Les éléments de liste non ordonnés conservent généralement un tiret ou un astérisque à la place de la puce
• Les éléments de liste ordonnés conservent leur numérotation
• Les listes imbriquées conservent le retrait relatif afin que la hiérarchie soit toujours visible

Choix d'une méthode de conversion : outil en ligne, bibliothèque ou script

Trois voies pratiques existent pour exécuter une conversion HTML en texte, et chacune correspond à un volume de travail différent.

L'adéquation de la méthode au travail est plus importante que de choisir la "meilleure" dans l'abstrait.

Un outil en ligne ne demande rien à la personne qui l’utilise, colle le balisage, récupère le texte, c’est fait.

Il s’effondre au moment où le travail implique plus qu’une poignée de documents.

Les bibliothèques de code s'insèrent directement dans le code backend (EN), ce qui signifie qu'une application peut traiter par lots des milliers de pages du jour au lendemain sans qu'une personne ne clique sur quoi que ce soit.

Certains services exposent également la conversion via une API (EN) appelable, ce qui convient aux équipes qui préfèrent envoyer une demande plutôt que de gérer une dépendance.

Les scripts en ligne de commande se situent entre les deux, suffisamment scriptables pour un travail cron, suffisamment simples pour être exécutés à la main si nécessaire.

Les meilleures bibliothèques HTML vers texte par langue

Chaque langage de programmation majeur a au moins une option mature pour cela, et le bon choix dépend généralement de ce dont le projet dépend déjà.

Bibliothèques de Python

• BeautifulSoup (EN), associé à un analyseur comme lxml ou html.parser, pour une extraction à usage général avec beaucoup de contrôle sur la sortie
• html.parser, intégré à la bibliothèque standard Python, pour les tâches légères qui ne doivent pas ajouter de dépendance
• html2text (EN), pour une sortie qui se lit comme du Markdown plutôt que du texte brut

from bs4 import BeautifulSoup

soup = BeautifulSoup(html, "html.parser")
for tag in soup(["script", "style"]):
    tag.decompose()
text = soup.get_text(separator="\n", strip=True)

BeautifulSoup4 a enregistré plus de 400 millions de téléchargements au cours des 30 derniers jours sur PyPI, selon pepy.tech (EN). Cela en dit long sur la fréquence à laquelle les développeurs Python l'utilisent par défaut.

html2text a tiré 14,1 millions de téléchargements en un seul mois à lui seul, selon PyPI Stats (EN). Un nombre plus faible, mais toujours la preuve d'une utilisation régulière et dédiée.

Les deux sont rarement en concurrence directe. BeautifulSoup est l'analyseur général, html2text est le spécialiste de la sortie Markdown.

Bibliothèques JavaScript et Node.js

Le paquet html-to-text (EN) de npm reçoit environ 11 millions de téléchargements par semaine selon le registre de npm, ce qui en fait le choix par défaut dans la plupart des projets Node.js qui en ont besoin.

Il fonctionne côté serveur, écrit pour les environnements JavaScript (EN) plutôt que pour le navigateur, et ne dépend pas d'une implémentation DOM pour fonctionner.

import { convert } from "html-to-text";

const text = convert(html, {
  wordwrap: false,
  selectors: [{ selector: "a", options: { ignoreHref: true } }],
});

• Gère les tables, listes et liens avec des règles de sortie configurables
• Fonctionne bien à l'intérieur des pipelines d'e-mail basés sur Node générant des recours en texte brut
• Livré avec des valeurs par défaut raisonnables, de sorte que la plupart des projets ont besoin de peu ou pas de configuration

Bibliothèques Java et Ruby

Java et Ruby s'appuient tous deux sur une seule bibliothèque dominante plutôt que de diviser l'attention entre plusieurs options.

jsoup (EN) (Java) :

• Avantages : Sélecteurs de style CSS familiers à tous ceux qui ont écrit du code front-end, maintenance active, tolérance au HTML malformé
• Inconvénients : une dépendance de plus pour les projets qui ne touchent pas déjà HTML ailleurs

Nokogiri (EN) (Ruby) :

• Avantages : rapide, construit sur libxml2, gère aussi bien les documents HTML que XML
• Inconvénients : s'appuie sur des extensions natives, ce qui complique parfois le déploiement sur des hôtes restrictifs

Aucune des deux bibliothèques n’est proche de sa langue. La plupart des projets Java et Ruby utilisent par défaut l'un de ces deux langages sans grand débat.

Où la conversion HTML en texte est utilisée

Le même processus sous-jacent apparaît dans quatre coins très différents du logiciel : le courrier électronique, la recherche et le grattage, l'accessibilité et l'apprentissage automatique.

Chacun demande au convertisseur de résoudre un problème légèrement différent.

Où la conversion se déroule réellement :

• Systèmes de messagerie générant un texte brut à côté de la version HTML
• Pipelines d'extraction Web extrayant du contenu lisible des pages explorées
• Lecteurs d'écran et autres outils d'assistance consommant le texte dépouillé
• Étapes de prétraitement NLP qui alimentent un modèle avec du texte propre

La Common Crawl Foundation (EN), une organisation à but non lucratif qui archive le Web public, extrait du texte brut de chaque page qu'elle explore dans des fichiers WET distincts conçus spécifiquement pour l'apprentissage automatique. Le HTML brut vit à part, dans ses fichiers WARC.

Un seul instantané mensuel de ce projet couvre plus de 2 milliards de pages. Cela donne une idée de la fréquence à laquelle cette conversion s'exécute en coulisse plutôt qu'en face d'un utilisateur.

Sur le plan de l'accessibilité, NVDA est maintenant le lecteur d'écran le plus utilisé dans l'ensemble, utilisé régulièrement par 65,6% des répondants à WebAIM Screen Reader User Survey #10 (EN).

Chacun de ces utilisateurs dépend d'un logiciel qui lit le contenu dans un ordre linéaire basé sur le texte. C'est exactement ce qu'un convertisseur HTML en texte produit une fois que les balises et la mise en page sont supprimées.

Des conseils plus approfondis sur la structuration des pages pour ce public se trouvent dans la plupart des ressources d'accessibilité web (EN). L'ordre du texte et le balisage sémantique affectent tous deux la capacité d'un lecteur d'écran à suivre une page.

L'email ajoute sa propre touche. Apple Mail et Gmail représentent ensemble près de 90% de toutes les ouvertures d'e-mails suivies par Litmus (EN). Un texte brut de secours doit généralement être rendu correctement dans seulement deux environnements plutôt que des dizaines.

Lorsque la conversion HTML en texte ne s'applique pas

La conversion échoue ou n'a tout simplement pas de sens dans une poignée de situations spécifiques.

Les connaître à l'avance permet d'économiser du temps en déboguant des sorties qui n'allaient jamais fonctionner.

Où il se décompose :

• Contenu qui n'existe qu'après l'exécution de JavaScript, puisque la source HTML brute ne le contient jamais
• Mises en page où la position et l’alignement ont un sens, les états financiers et les formulaires en étant l’exemple le plus clair
• Workflows qui nécessitent la préservation du balisage d'origine pour un retraitement ultérieur
• Documents si mal formés qu'un analyseur ne peut pas du tout construire une arborescence utilisable

Le premier point de cette liste est le plus important dans la pratique.

JavaScript fonctionne maintenant sur 98,9% de tous les sites web, selon W3Techs (EN). Une part croissante de ces sites rendent leur contenu réel côté client plutôt que de l'envoyer dans la réponse HTML initiale.

Les applications monopage construites avec des frameworks comme React ou Vue ne fournissent souvent que peu plus qu’un shell vide et une balise de script dans leur source brute. Un convertisseur pointé vers cette source ne récupère presque rien d'utile.

Récupérer la page à travers un navigateur sans tête d'abord, de sorte que JavaScript a une chance d'exécuter, est la solution habituelle. À ce stade, la tâche est passée d'une simple conversion à un rendu de page complète.

La mise en page visuelle est le deuxième point de défaillance récurrent.

Un convertisseur aplatit une facture à deux colonnes en un seul flux de lignes. La relation entre un élément de ligne et son prix peut se perdre au moment où les colonnes se réduisent.

Comment convertir HTML en texte étape par étape

Le processus est le même quelle que soit la méthode que vous choisissez, seul l'outillage change.

1. Confirmez que la source est valide HTML (EN) et vérifiez son encodage de caractères déclaré avant de toucher le contenu
2. Choisissez une méthode adaptée au volume : un outil en ligne pour un fichier, une bibliothèque pour un script, une tâche planifiée pour des lots récurrents
3. Exécutez la conversion et surveillez la façon dont elle gère les entités, car c'est là que la sortie corrompue apparaît en premier
4. Vérifiez le résultat de la suppression des balises par rapport à l'original, confirmant que les liens, les tableaux et les listes ont été résolus comme prévu.
5. Valider le texte final par rapport au document source, en recherchant spécifiquement le contenu qui a disparu silencieusement

La troisième étape mérite une attention particulière.

Un moyen rapide de détecter rapidement les problèmes d’entité consiste à rechercher dans le résultat une esperluette littérale suivie de lettres. Ce modèle signifie généralement que quelque chose n’a pas pu être décodé.

Les équipes exécutant cette conversion selon un calendrier la branchent souvent à l’automatisation existante. Les actions GitHub sont un endroit courant pour déclencher un travail par lots du jour au lendemain plutôt que de l'exécuter manuellement.

Omettre la cinquième étape est le raccourci qui provoque le plus souvent des problèmes par la suite.

Erreurs courantes lors de la conversion HTML en texte

La plupart des problèmes de conversion sont dus à une petite poignée d'erreurs récurrentes.

Aucun d’entre eux n’est exotique. Ils sont simplement manqués parce que le résultat semble correct en un coup d'œil.

Un HTML mal formé provoque un autre type de problème, puisqu'un analyseur peut ignorer silencieusement du contenu au lieu de générer une erreur.

L'exécution de balises suspectes à travers un embellissement HTML (EN) fait souvent apparaître des balises cassées ou non fermées qui passeraient autrement inaperçues.

Le double-décodage mérite une mention supplémentaire à part entière, séparée du tableau ci-dessus.

Cela se produit le plus souvent dans les pipelines avec plus d'une étape de traitement. Une étape antérieure a déjà décodé les entités, et une étape ultérieure les décode à nouveau sans vérification.

La solution est procédurale, pas technique : enregistrez chaque point du pipeline où le décodage a lieu, et il ne devrait jamais y en avoir qu'un seul.

Questions fréquentes : Convertisseur de HTML en texte

La conversion de HTML en texte est-elle réversible vers le balisage original ?

Non, une fois que les balises, les attributs et le style sont supprimés, cette information structurelle disparaît pour de bon.

Un fichier texte brut ne contient que des mots, donc recréer le balisage signifie reconstruire les balises et le formatage à partir de zéro, sans inverser un processus sans perte.

Quelle est la différence entre la conversion HTML en texte et l'extraction de texte basée sur OCR

L'OCR lit les pixels d'une image ou d'une photo numérisée et devinera les caractères qu'il voit, de sorte que la précision dépend de la qualité de l'image.

La conversion HTML en texte lit le balisage qui contient déjà des caractères réels, produisant une sortie déterministe exacte à chaque fois.

La conversion HTML en texte peut-elle préserver les emoji et les caractères Unicode spéciaux ?

Oui, tant que le document source et le convertisseur utilisent tous deux un encodage Unicode.

Les émoticônes, les lettres accentuées et les scripts non latins passent intacts lorsque les entités décodent correctement. Les problèmes ne surviennent que lorsqu'un convertisseur assume un encodage plus ancien et plus étroit par erreur.

La conversion de HTML en texte affecte-t-elle le référencement ou crée-t-elle des problèmes de contenu en double ?

Pas directement. Les moteurs de recherche indexent la page active, pas une copie en texte brut générée par la suite.

Le risque de contenu en double n’apparaît que si le texte extrait est republié ailleurs sur le web ouvert sans modifications ni attribution.

Les convertisseurs HTML vers texte gèrent-ils les pages rendues en JavaScript par défaut ?

La plupart ne le font pas. Un convertisseur standard lit la source brute, de sorte que le contenu injecté ultérieurement par JavaScript n'apparaît jamais.

Coupler le convertisseur avec un outil headless browser comme Puppeteer, Selenium ou Playwright rend d'abord la page, puis l'extraction fonctionne normalement.

Quelle est la taille d'un fichier qu'un convertisseur typique peut traiter avant une baisse des performances

La plupart des bibliothèques gèrent confortablement des documents jusqu'à quelques mégaoctets sans problème.

Les performances baissent fortement sur les balises profondément imbriquées ou malformées. Les outils basés sur des analyseurs construisent une arborescence complète de documents avant d'extraire quoi que ce soit, ce qui consomme plus de mémoire sur les fichiers plus volumineux.

Où se décompose un convertisseur HTML en texte ?

Un convertisseur HTML vers texte se décompose en trois points prévisibles : un encodage de caractères non résolu, un contenu qui n'existe qu'après l'exécution de JavaScript, et un balisage si mal formé qu'aucun analyseur ne peut construire une arborescence de documents utilisable.

La réparation d'une conversion cassée suit un ordre spécifique, et sauter à l'avance perd plus de temps qu'il ne le gagne.

• Vérifier d'abord l'encodage source
• Vérifiez les étiquettes malformées ou non fermées deuxième
• Test de contenu dépendant de JavaScript third

Les problèmes d'encodage corrompt chaque caractère en aval, donc les isoler avant que les problèmes structurels ne reçoivent l'attention permet d'économiser une réécriture ultérieure.

Le routage d'une page via un navigateur sans tête avant la conversion comble l'écart JavaScript. Cet échange accepte un pipeline de rendu plus lent avec sa propre mémoire et coût d'hébergement en échange du texte complet.

Les lecteurs qui gèrent le flux de travail inverse, transformant un document formaté en balisage publiable, se déplacent généralement à côté d'un convertisseur Word en HTML dédié.