Convertisseur Markdown → HTML, gratuit

Comment utiliser ce convertisseur

1. Collez votre Markdown. L'outil accepte CommonMark plus les extensions GFM les plus courantes, tableaux, code clôturé avec indications de langue, barré, autoliens et éléments de liste de tâches.
2. Regardez la conversion en direct. Le panneau de droite montre la sortie HTML brute à mesure que vous tapez ; le panneau d'aperçu en dessous la rend visuellement.
3. Copiez le HTML. Utilisez le bouton Copier HTML pour récupérer la sortie prête à coller dans votre CMS, client de messagerie, modèle de générateur de site statique ou n'importe où ailleurs qui accepte HTML.

Une brève histoire de Markdown

Markdown a été créé par John Gruber, l'auteur du blog Daring Fireball, avec des retours de conception substantiels d'Aaron Swartz. La première version publique, la 1.0, a été annoncée sur le site de Gruber le 9 mars 2004 ; la version 1.0.1, la version de référence canonique, a suivi le 17 décembre 2004 et est toujours la version liée depuis daringfireball.net/projects/markdown. Markdown était deux choses à la fois dès le début : une syntaxe de formatage en texte brut et le script Perl original qui le convertissait en HTML. L'objectif déclaré de Gruber était que le texte source devrait être lisible tel quel, un document Markdown ouvert dans un éditeur de texte brut devrait ressembler à un e-mail réfléchi et formaté, pas à de la soupe de balises. Cette contrainte de lisibilité est la ligne philosophique qui sépare Markdown des formats basés sur XML et des balisages plus lourds comme LaTeX, et c'est la raison pour laquelle chaque extension ultérieure a dû se défendre en termes de la mesure dans laquelle elle perturbe la source. Aaron Swartz avait précédemment écrit un balisage léger apparenté appelé atx (2002), qui a contribué au style de titre # et ## aujourd'hui familier, parfois encore appelé « titres de style atx » dans les spécifications de parser.

CommonMark, corriger la sous-spécification

La description originale de la syntaxe de Gruber de 2004 était notoirement informelle, un document en prose avec exemples, pas une grammaire. Elle laissait des dizaines de cas limites non spécifiés, et Gruber n'a jamais publié de parser de référence autre que son script Perl, dont le comportement était idiosyncratique de manière que les autres implémenteurs devaient soit copier, soit remplacer. Le résultat au début des années 2010 était que GitHub, Reddit, Stack Overflow, Pandoc et le parser Discount C rendaient la même source Markdown légèrement différemment. En 2012, le cofondateur de Stack Overflow Jeff Atwood et l'auteur de Pandoc John MacFarlane ont commencé un effort pour écrire une véritable spécification testable. Le projet a été lancé publiquement en septembre 2014 sous le nom de « Standard Markdown » ; en quelques jours, Gruber s'est opposé au nom dans un e-mail privé, Atwood a écrit un post public expliquant le changement, et le projet a été renommé « CommonMark ». La première version numérotée est arrivée le 25 octobre 2014. La version publiée actuelle est CommonMark 0.31.2, publiée le 28 janvier 2024. La spec CommonMark est inhabituelle en ce qu'elle est elle-même un document CommonMark, avec plus de 600 cas de test exécutables en ligne ; un parser revendique la conformité en passant ces tests. GitHub Flavored Markdown (GFM), la spec formelle à la version 0.29-gfm datée du 6 avril 2019, définit cinq extensions au-dessus de CommonMark : tableaux, éléments de liste de tâches, barré, autoliens pour les URL brutes, et HTML brut interdit (une restriction de sécurité qui supprime les balises dangereuses du HTML fourni par l'auteur).

Les principaux parsers

marked.js a été créé par Christopher Jeffrey en 2011 et est maintenu par l'organisation GitHub markedjs depuis 2018, une conception lexer-puis-parser à passage unique qui privilégie la vitesse brute ; ~36k étoiles et le projet Markdown le plus étoilé sur GitHub. C'est le parser que cet outil utilise pour la conversion. markdown-it a été lancé en 2014 par Vitaly Puzrin et Alex Kocharin, annonçant une conformité CommonMark à 100% avec des bascules GFM optionnelles plus un écosystème de plugins agressif (markdown-it-footnote, markdown-it-emoji, markdown-it-attrs, markdown-it-anchor et plusieurs centaines d'autres). C'est le parser utilisé par l'aperçu Markdown intégré de VS Code, l'interface web de GitLab et Eleventy. remark / unified.js n'est pas un parser unique mais un framework de transformation d'arbre, le collectif unified définit une spec d'arbre syntaxique abstrait appelée mdast (Markdown AST) ; remark parse le Markdown en mdast, les plugins manipulent l'arbre, et remark-rehype convertit mdast en hast (HTML AST) pour l'émission. Plus lent que marked mais vastement plus composable ; les utilisateurs notables incluent Prettier, Gatsby, MDN et le linter de langage inclusif alex. Pandoc, publié par John MacFarlane le 10 août 2006, est le convertisseur universel de documents, écrit en Haskell, parse environ 30 formats d'entrée, rend dans environ 40 formats de sortie ; omniprésent dans l'édition académique et technique.

Le pipeline MD-vers-HTML, mécaniquement

Un parser Markdown fonctionne typiquement en deux passes. L'analyse au niveau bloc divise l'entrée en structures de bloc, paragraphes, titres, listes, clôtures de code, citations en bloc, règles horizontales, tableaux. Les limites de bloc sont déterminées par les lignes vides et l'indentation ; les obtenir correctement est la majeure partie de ce qui rend un parser CommonMark correct. L'analyse inline parcourt ensuite le contenu de chaque bloc et fait correspondre la syntaxe inline : emphase (*italique*, **gras**), liens ([texte](url)), portées de code inline (`code`), images (![alt](url)), barré (~~texte~~ en GFM), et autoliens explicites (<https://example.com>). L'analyse d'emphase inline est la partie la plus délicate de toute spec Markdown, CommonMark consacre plusieurs pages de la spec et des dizaines de cas de test à spécifier quand *foo*bar* devrait produire <em>foo</em>bar* versus *foo<em>bar</em>. Le parser rend ensuite chaque jeton comme l'élément HTML correspondant et concatène les résultats. La mise en forme jolie, l'indentation et la coloration syntaxique des blocs de code sont superposées par les options de rendu.

Pourquoi convertir MD en HTML en premier lieu ?

• Imports CMS. De nombreux CMS headless (Contentful, Sanity, Wagtail, Ghost) acceptent HTML mais pas Markdown. Rédiger en Markdown et convertir une fois au moment de la publication garde l'expérience d'édition agréable.
• Composition d'e-mails. Les clients de messagerie rendent HTML ; la plupart ne rendent pas Markdown. Les plateformes de newsletter (Mailchimp, ConvertKit, Substack) acceptent typiquement le HTML collé dans leur éditeur. Convertissez votre brouillon, collez, envoyez.
• Brouillons d'articles de blog. Certaines anciennes installations WordPress sans le plugin Markdown exigent du HTML dans le corps du post ; certaines pages boutique Shopify et Webflow prennent HTML dans leurs champs de texte enrichi.
• Snippets de générateur de site statique. Quand vous avez besoin d'un morceau HTML inline pour un shortcode Hugo, un modèle Eleventy ou un fichier MDX Next.js, convertir le Markdown en un seul fragment HTML est plus rapide que de combattre le pipeline de conversion propre du SSG.
• Partage de notes rendues. Coller du Markdown « rendu » dans Slack, Notion, Linear, ClickUp ou d'autres destinations de texte enrichi veut parfois HTML dans le presse-papiers plutôt que Markdown brut.
• Archivage de la documentation. Stocker le HTML rendu aux côtés de la source Markdown signifie que votre archive est lisible par les humains dans un navigateur sans parser, utile pour la préservation à long terme.

Options de sortie qu'il vaut la peine de connaître

Différentes utilisations en aval veulent des choses différentes du HTML converti. Document complet vs fragment. Un document HTML complet inclut <!DOCTYPE html>, <html>, <head> avec métadonnées, et un wrapper <body>, approprié lorsque vous enregistrerez le fichier en .html et l'ouvrirez dans un navigateur. Un fragment est juste le contenu du corps, sans wrapper, approprié lorsque vous collerez dans un champ CMS qui fournit déjà la structure du document. Cet outil émet des fragments par défaut ; enveloppez avec votre propre boilerplate si vous avez besoin d'un document complet. Assainissement. Par défaut, les parsers Markdown laissent passer le HTML brut inchangé, donc si votre source contient <script>alert(1)</script>, cette balise script apparaîtra dans la sortie. Pour les documents allant dans un système multi-utilisateurs, faites passer la sortie par DOMPurify (Cure53, démarré février 2014) avant d'injecter dans le DOM. Pour un usage personnel ponctuel, la sortie brute convient. IDs d'en-tête. Générer des attributs id sur les titres (slugifiés à partir du texte du titre) vous permet de construire une table des matières avec des liens d'ancrage. L'algorithme de slug exact diffère entre les plateformes, GitHub utilise une règle, MkDocs une autre, marked.js une troisième, donc les liens d'ancrage peuvent se casser lorsque le contenu se déplace entre les systèmes. Sauts de ligne durs. CommonMark exige soit deux espaces de fin à la fin d'une ligne soit une barre oblique inverse pour forcer un <br> ; certaines plateformes (Discord, issues GitHub) traitent les sauts de ligne uniques comme des sauts. Le choix dépend du style attendu de votre source.

Pièges courants

• Conversion de guillemets intelligents. Certains parsers (ou couches de post-traitement comme le SmartyPants propre de Gruber) remplacent les guillemets droits par des guillemets typographiques courbes par défaut. Si vous avez besoin que les guillemets droits soient préservés (parce que votre sortie est analysée comme du code), vérifiez que cette transformation est désactivée.
• Sensibilité aux espaces blancs des marqueurs de liste. Mélanger - et * et + dans la même liste, indenter les paragraphes de continuation de liste de moins que le marqueur ne l'exige, ou mettre une ligne vide entre les éléments de liste peut transformer une liste serrée en liste lâche (chaque élément enveloppé dans des balises <p>). La différence visuelle dans la sortie est dramatique.
• Excès de zèle de l'autolien. L'autoliage style GFM transforme toute URL brute en lien, ce qui est généralement ce que vous voulez, mais peut mutiler les URLs contenant des parenthèses (les URLs Wikipedia surtout) ou de la ponctuation de fin.
• Tableaux qui nécessitent un échappement. Les caractères pipe à l'intérieur des cellules de tableau doivent être échappés en \|, sinon ils sont lus comme des séparateurs de colonnes. Attrape quiconque essaie de mettre un exemple de code d'une ligne à l'intérieur d'une cellule.
• Mélange Markdown et HTML. Markdown a été conçu pour laisser passer du HTML arbitraire, donc déposer un <div class="callout"> dans un fichier Markdown fonctionne. Mais dès que vous mettez de la syntaxe Markdown à l'intérieur d'un bloc HTML, les parsers divergent : CommonMark traite la plupart des blocs HTML comme opaques ; Markdown Extra a introduit markdown="1" pour opter au parsing imbriqué.
• IDs de titre entre plateformes. Différents algorithmes de slug produisent différents fragments d'ancrage pour le même titre ; les liens intra-document peuvent se casser lorsque le contenu se déplace entre les systèmes.

Cet outil vs l'aperçu Markdown

Absolutool livre deux outils connexes qui se chevauchent sur le même parser. L'aperçu Markdown est pour l'édition en direct, écrivez du Markdown à gauche, voyez la sortie visuelle rendue à droite, sans concept de « la sortie HTML ». Ce convertisseur Markdown-vers-HTML est pour la conversion ponctuelle, collez du Markdown, copiez le HTML brut, collez dans votre CMS ou client de messagerie. Utilisez l'aperçu lorsque vous rédigez et avez besoin de retour visuel ; utilisez ce convertisseur lorsque vous avez du Markdown fini et avez besoin de HTML que vous pouvez transporter ailleurs. Les deux outils utilisent marked.js sous le capot et acceptent le même dialecte CommonMark + GFM, donc le comportement de conversion est identique entre eux.

Confidentialité : pourquoi le tout-navigateur compte ici

Les brouillons d'écriture non publiée, articles de blog en cours, documentation interne, livrables clients sous NDA, chapitres de manuscrits, articles académiques, sont exactement le genre de texte que vous ne voulez pas téléverser à un service tiers. Les convertisseurs Markdown côté serveur exigent d'envoyer le document entier à un endpoint distant, ce qui signifie qu'il reste dans les logs du serveur, peut-être dans un cache CDN, peut-être dans un pipeline d'analytique, peut-être dans une sauvegarde. Pour le texte publié, la question est sans intérêt. Pour le travail de brouillon, l'architecture compte. Cet outil exécute tout le pipeline dans votre navigateur via JavaScript et marked.js. Le Markdown ne traverse jamais le réseau, vérifiez dans l'onglet Réseau de DevTools pendant que vous tapez, ou mettez la page hors ligne (mode avion) après son chargement et confirmez que le convertisseur fonctionne toujours. Sûr pour les brouillons confidentiels, les livrables clients, les chapitres de manuscrit sous NDA, les notes internes ou tout autre chose que vous ne voudriez pas voir copié sur le disque dur d'un étranger.

Questions fréquentes

Quel dialecte Markdown ce convertisseur prend-il en charge ?

CommonMark avec les extensions GFM les plus courantes activées, tableaux (délimités par pipes avec alignement : optionnel), blocs de code clôturés avec indications de langue, barré via ~~texte~~, autoliens pour les URL brutes, et éléments de liste de tâches via [ ] et [x]. Titres, gras, italique, liens, images, listes, citations en bloc, règles horizontales et code inline fonctionnent tous comme vous l'attendriez sur GitHub. Le moteur de rendu est marked.js, le même parser que l'aperçu Markdown utilise.

Cela prend-il en charge GitHub Flavored Markdown (GFM) ?

Oui, les tableaux avec pipes, les blocs de code clôturés avec indications de langue, les listes de tâches, les autoliens et le barré fonctionnent tous. Si une extension GFM ne se rend pas, vérifiez que l'entrée suit les règles de syntaxe CommonMark/GFM : lignes vides autour des éléments de bloc, comptages de backticks correspondants sur les blocs de code clôturés, exactement deux espaces de fin (ou une barre oblique inverse) pour les sauts de ligne durs. La cause la plus courante de « GFM ne fonctionne pas » est un éditeur qui supprime les espaces de fin lors de la sauvegarde, ce qui tue la syntaxe des sauts durs.

La sortie aura-t-elle la même apparence sur GitHub ?

Le HTML structurel, paragraphes, listes, tableaux, titres, correspondra pour toute entrée qui est un CommonMark + GFM valide. Deux couches différeront. GitHub applique son propre thème CSS et coloration syntaxique, donc les couleurs, polices et espacement auront l'air différents. GitHub superpose également un post-traitement au-dessus de la spec, raccourcis d'emoji (:smile:), mentions @user, auto-liage de #issue, chemins d'image relatifs au dépôt, qu'aucun convertisseur conforme à la spec ne reproduit. Le HTML que cet outil émet est portable structurellement ; l'apparence visuelle dépend du CSS dans la destination.

Dois-je assainir la sortie avant de publier ?

Si la source pourrait inclure du contenu fourni par l'utilisateur, oui. Les parsers Markdown laissent passer le HTML brut inchangé, donc une source contenant <img src=x onerror="alert(1)"> produira cette balise dans la sortie. Pour les systèmes multi-utilisateurs, faites passer la sortie par DOMPurify (Cure53, février 2014, l'assainisseur JavaScript de facto) avant d'injecter dans le DOM. Pour un usage personnel ponctuel où la source est votre propre écriture, ce n'est pas un problème, le pire que vous puissiez faire à votre propre page est y coller votre propre HTML.

Puis-je obtenir un document HTML complet avec head et body ?

Actuellement cet outil émet uniquement le fragment de corps, le Markdown converti enveloppé dans des balises HTML sémantiques mais pas dans un document <html>/<head>/<body> complet. Pour sauvegarder en tant que fichier .html autonome, enveloppez la sortie vous-même : <!DOCTYPE html><html><head><meta charset="utf-8"><title>...</title></head><body>[fragment]</body></html>. Ou utilisez Pandoc avec le drapeau --standalone pour une sortie entièrement autonome avec CSS piloté par modèle.

Mon Markdown est-il envoyé quelque part ?

Non. La conversion s'exécute entièrement dans votre navigateur via marked.js. Le Markdown que vous collez ne traverse jamais le réseau, vérifiez dans l'onglet Réseau de DevTools pendant que vous tapez, ou mettez la page hors ligne (mode avion) après son chargement et confirmez que le convertisseur fonctionne toujours. Sûr pour les brouillons confidentiels, les livrables clients sous NDA, les chapitres de manuscrit ou tout texte que vous ne voudriez pas voir copié sur le disque dur d'un étranger.

Outils associés