Convertisseur HTML → Markdown, gratuit

Convertissez du code HTML en Markdown propre.

Éléments HTML pris en charge

Titres : <h1> à <h6> → # à ######

Emphase : <strong>, <em>, <del> → **gras**, *italique*, ~~barré~~

Liens : <a href> → [texte](url)

Images : <img> → ![alt](src)

Code : <code>, <pre> → blocs de code en ligne et clôturés

Listes : <ul>, <ol> → - éléments, 1. éléments

Tableaux : <table> → syntaxe de table Markdown

Autres : <blockquote>, <hr>, <br>

Ce que fait réellement la conversion HTML vers Markdown

Un convertisseur HTML vers Markdown analyse un fragment HTML, parcourt l’arbre DOM résultant et émet la syntaxe Markdown pour chaque élément qu’il reconnaît. <h1> devient # ; <strong> devient **gras** ; <a href="..."> devient [texte](url) ; <ul><li> devient une liste à puces. L’outil tourne entièrement dans votre navigateur via JavaScript : collez du HTML à gauche, cliquez sur Convertir en Markdown, et la sortie formatée apparaît à droite. Pas de téléversement, pas d’aller-retour serveur, pas de télémétrie, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Convertir, ou mettez la page hors ligne (mode avion) après son chargement et le convertisseur fonctionne toujours. Cette implémentation utilise le DOMParser intégré du navigateur pour lire le HTML, puis un petit parcours récursif émet le Markdown pour chaque nœud. C’est un convertisseur d’environ 150 lignes écrit à la main plutôt qu’un wrapper autour de Turndown, ce qui veut dire qu’il couvre proprement le cas courant mais n’égale pas la configurabilité complète de Turndown.

Quand vous avez réellement besoin de cette conversion

Le sens inverse (Markdown vers HTML) est le plus connu, chaque générateur de site statique et chaque outil d’écriture le fait. Le sens direct (HTML vers Markdown) est moins évident mais de plus en plus courant parce que l’écosystème des outils d’écriture s’est polarisé : le HTML est le format ambiant du web (chaque CMS, plate-forme de newsletter, modèle de CRM, ancien site statique émet ou stocke du HTML) ; le Markdown est le format natif de tout flux moderne de documentation, de prise de notes et de contenu sous contrôle de version apparu depuis vers 2014. Quatre flux de travail réels génèrent ce besoin de conversion.

L’implémentation de référence : Turndown et sa famille

Turndown (Dom Christie) est la bibliothèque JavaScript HTML vers Markdown dominante, elle a démarré sous le nom to-markdown en 2012, a été renommée Turndown en 2017 pour la distinguer des forks, et est publiée sous le nom turndown sur npm sous licence MIT. Sa conception est fondée sur des règles : chaque règle a un filter (les nœuds DOM sur lesquels elle s’applique) et un replacement (une fonction qui produit le Markdown). Le constructeur accepte des options pour le style des titres (atx # vs setext ===), le marqueur de puce (-, + ou *), le style de bloc de code (indenté vs cloisonné), le délimiteur d’emphase (* vs _), le délimiteur de gras (** vs __), le style de lien (en ligne vs référencé), etc. Les tableaux, le barré, les items de liste à cocher et les autoliens vivent dans le paquet séparé turndown-plugin-gfm. markdownify (Matthew Tretter) est l’équivalent en Python, largement utilisé dans les pipelines de scraping, la conversion de notebooks Jupyter, les chargeurs de documents LangChain et la préparation de jeux de données pour LLM. html2text (à l’origine d’Aaron Swartz, qui a aussi collaboré avec John Gruber sur le design original de Markdown en 2004) est l’option Python plus ancienne, encore en service dans des pipelines e-mail historiques mais largement supplantée. html-to-markdown (Johannes Kaufmann) est un portage Go de Turndown populaire pour des binaires de scraping autonomes. Pandoc (John MacFarlane, qui préside le projet CommonMark) est le convertisseur de documents universel, il gère les tableaux à cellules fusionnées via les grid tables, les maths, les citations, les notes de bas de page, les listes de définitions, et convertit entre des dizaines de formats. Pandoc est l’outil HTML vers Markdown le plus complet disponible, mais c’est un binaire Haskell de plus de 60 Mo qui doit être installé ; il ne tourne pas dans un navigateur.

Le compromis fondamental : le HTML est plus riche que le Markdown

Toute conversion HTML vers Markdown est nécessairement avec perte parce que le format source exprime des choses que le format cible ne sait pas dire. Les styles en ligne (<span style="color:red">) n’ont pas de grammaire Markdown, le vocabulaire d’emphase de Markdown se limite strictement à gras/italique/barré/code, sans syntaxe pour une couleur, une police ou une taille arbitraires. Les classes CSS (<div class="alert">) ont du sens pour une feuille de style mais aucun pour le Markdown. Les attributs data personnalisés (data-track-event="...") font partie du contrat JavaScript de la page, pas du document. Les tableaux à cellules fusionnées (colspan, rowspan) ne peuvent pas être exprimés dans les pipe tables GFM. Les médias embarqués (<video>, <audio>, <iframe>) et les contrôles de formulaire n’ont pas d’équivalent Markdown. Les volets repliables <details><summary>, les <figure><figcaption>, les annotations <ruby> pour la prononciation des CJC, les microdonnées et microformats, rien de tout cela ne survit à la conversion. Pour chaque construction non prise en charge, l’auteur du convertisseur choisit l’une des trois stratégies : traduire vers une approximation Markdown qui perd de l’information, laisser passer en HTML brut intégré dans le Markdown (Markdown l’autorise par spécification ; les sections 4.6 et 6.6 de CommonMark le couvrent), ou laisser tomber entièrement. Cette implémentation choisit « traduire là où la correspondance est claire, sinon envelopper de manière transparente (rendre les enfants, supprimer la balise) », un défaut prévisible et facile à raisonner qui gère le cas courant au prix de la configurabilité avancée.

Les correspondances canoniques

Périmètre honnête : ce que cet outil fait et ne fait pas

Trois limitations honnêtes à connaître. (1) Les styles en ligne et les classes CSS sont supprimés. Un <span style="color:red"> devient du texte non stylé ; un <p class="lede"> perd sa classe. Il n’y a pas de grammaire Markdown pour un stylage en ligne arbitraire. (2) Les tableaux à cellules fusionnées s’aplatissent. Les pipe tables GFM n’ont pas de syntaxe pour colspan ou rowspan ; l’information de fusion est silencieusement perdue. Pour des tableaux complexes, gardez la source en HTML à l’intérieur du Markdown (CommonMark autorise le HTML embarqué) ou utilisez Pandoc avec une sortie en grid table. (3) Les blocs de code sortent sans indication de langage. Si votre HTML contient <pre><code class="language-js">, l’attribut de langage est actuellement supprimé, la sortie est un bloc cloisonné sans langage. Vous pouvez ajouter manuellement l’identifiant de langage après les accents graves d’ouverture si votre renderer cible prend en charge la coloration syntaxique. La mise en garde plus large : si vous collez le HTML complet d’une page web (depuis « Afficher la source »), les contenus <script> et <style> seront émis comme du texte brut, ce n’est presque certainement pas ce que vous voulez. La solution : ne coller que le contenu de l’article, ou copier depuis la vue rendue (qui élague automatiquement scripts et styles), ou nettoyer le HTML avec DOMPurify ou similaire avant la conversion.

L’état du Markdown en 2026

Markdown a fêté ses vingt-deux ans en 2026. John Gruber a publié le script Perl original en 2004, avec Aaron Swartz comme collaborateur de design. Les tableaux ont été délibérément omis de l’original de Gruber ; la syntaxe pipe-table que la plupart des lecteurs connaissent aujourd’hui vient de dialectes ultérieurs, surtout GitHub Flavored Markdown. CommonMark, l’effort rigoureux de spécification organisé par Jeff Atwood et John MacFarlane en 2014, en est aujourd’hui à la version 0.31.2 (28 janvier 2024) et est le dialecte ciblé par la plupart des parseurs modernes. GitHub Flavored Markdown (GFM, formalisé en version 0.29-gfm le 6 avril 2019) est le sur-ensemble de GFM qui ajoute les tableaux, les listes de tâches, le barré, les autoliens et les règles d’interdiction de HTML brut. GFM est le dialecte que la plupart des utilisateurs voient réellement sur le web à cause de l’échelle de GitHub. Markdown est désormais le format natif de pratiquement tout écosystème de documentation pour développeurs ; le HTML reste le format de sortie universel du web ; la conversion entre les deux est exactement aussi courante que l’inverse, et existe pour le moment où vous en avez besoin en urgence, dans un navigateur, sans installation et sans données quittant votre appareil.

Confidentialité : pourquoi le tout-navigateur compte ici

Le HTML collé dans un convertisseur contient souvent des traces de la source d’origine, balisage interne du CMS, contenu en brouillon non publié, données clients à l’intérieur de modèles d’e-mail, URL de liens qui révèlent la structure interne du site, références d’images qui pointent vers des serveurs d’assets privés. Les convertisseurs côté serveur téléversent tout cela vers un service tiers. Cet outil tourne entièrement dans votre navigateur via JavaScript : le HTML que vous collez ne traverse jamais le réseau, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Convertir, ou mettez la page hors ligne (mode avion) après son chargement et le convertisseur fonctionne toujours. Sûr pour des brouillons non publiés, des modèles d’e-mail clients, des extraits de documentation interne, ou tout HTML que vous ne voudriez pas voir copié sur le disque dur d’un inconnu.

Questions fréquentes

Cela fonctionne-t-il avec de gros fichiers ?

Oui, comme la conversion s’exécute dans votre navigateur, le plafond pratique est la mémoire disponible de votre appareil. Des dizaines de milliers de lignes se convertissent en bien moins d’une seconde sur un portable moderne. Des entrées très grandes (millions de nœuds) peuvent geler brièvement l’onglet pendant la récursion du parcours DOM. Pour la conversion par lots d’un export complet de CMS, un script utilisant Turndown sous Node ou markdownify sous Python est le meilleur outil.

Qu’advient-il des styles en ligne et des classes CSS ?

Ils sont entièrement supprimés. La grammaire d’emphase de Markdown couvre gras, italique, barré et code ; il n’y a pas de syntaxe pour une couleur, une police, une taille arbitraires ou un stylage piloté par classe. Si le stylage visuel compte dans votre sortie, gardez l’original en HTML ou utilisez un format cible plus riche comme AsciiDoc, reStructuredText ou MDX (Markdown plus composants JSX, utilisé par Docusaurus). Pour les cas d’archivage d’articles et de migration de CMS pour lesquels cet outil est construit, supprimer les styles est le bon comportement, l’intérêt même du Markdown est de retirer le bruit visuel et de ne conserver que la structure.

Cet outil fonctionne-t-il hors ligne ?

Oui, une fois la page chargée, la conversion tourne entièrement en JavaScript dans votre navigateur. Aucun appel réseau pendant la conversion. Vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Convertir, ou mettez l’appareil hors ligne (mode avion) après le chargement de la page et l’outil fonctionne toujours.

Est-ce que c’est Turndown ?

Non. Turndown (la bibliothèque de Dom Christie) est l’implémentation de référence en JavaScript et l’outil naturel à choisir dans un projet Node, mais c’est une dépendance substantielle avec une configurabilité complète pour le style des titres, les marqueurs de puce, le style des liens, le style des blocs de code, etc. Cet outil dans le navigateur est un parcours DOM écrit à la main plus petit (environ 150 lignes) qui cible le cas courant (titres, paragraphes, emphase, liens, images, listes, citations, code cloisonné, tableaux basiques) sans la surface de configuration. Pour les flux pour lesquels ce site est construit (conversions ponctuelles dans un navigateur, pas d’installation), l’implémentation plus petite est la bonne forme ; pour des pipelines de scraping en production qui nécessitent des règles configurables, Turndown reste le bon choix.

Comment les tableaux sont-ils traités ?

En pipe tables GFM : une ligne d’en-tête, une ligne de délimitation en tirets, et une ligne de corps par <tr>. Les pipe tables sont plates, elles ne peuvent représenter ni colspan, ni rowspan, ni du contenu de cellule sur plusieurs lignes, ni des listes dans des cellules, ni un alignement par cellule. Si votre tableau HTML utilise l’une de ces fonctionnalités, ce convertisseur produit un pipe table dégradé qui perd la structure supplémentaire. Pour des tableaux complexes, deux options pratiques : (a) garder le tableau en HTML brut à l’intérieur du Markdown (CommonMark autorise le HTML embarqué) et faire confiance au renderer cible pour le laisser passer ; (b) utiliser Pandoc avec une sortie en grid table, qui peut exprimer les cellules fusionnées.

Puis-je coller le HTML complet d’une page web ?

Vous pouvez, mais probablement vous ne devriez pas. La source complète d’une page web moderne contient des balises <script> avec du code JavaScript, des blocs <style> avec du CSS, des pixels de tracking, du balisage publicitaire et des commentaires de modèle CMS. Ce convertisseur n’élague pas explicitement les contenus de script et de style, donc tout cela finit en texte brut dans votre sortie Markdown. L’approche propre : sélectionnez seulement l’élément article dans les DevTools (clic droit sur l’article, « Inspecter », puis clic droit sur le nœud correspondant dans le panneau Éléments et « Copier outerHTML »), ou utilisez une étape d’extraction de contenu (la bibliothèque Readability de Mozilla, ou sa forme empaquetée dans le Mode Lecture de Firefox) avant de coller. Pour des flux à base d’extension de navigateur qui prennent en charge l’étape d’extraction automatiquement, voyez Obsidian Web Clipper ou MarkDownload.

Outils associés