Collez, formatez et comparez deux documents HTML côte à côte. Coloration syntaxique consciente des balises et vérifications de bonne formation en direct intégrées.
Un outil gratuit dans le navigateur pour comparer deux documents HTML. Collez l'ancienne version d'une landing page à gauche, la nouvelle à droite, et les changements s'allument balise par balise et attribut par attribut. Rien n'est uploadé.
Le diff lui-même est au niveau du caractère. Le bouton Format de chaque panneau reformate votre HTML avec une indentation cohérente, comme le feraient Prettier ou HTML Tidy. La coloration syntaxique suit le WHATWG HTML Living Standard, donc les éléments void, les attributs booléens et les références d'entités s'affichent correctement pendant que vous lisez le diff.
Si vous avez déjà déployé une correction de copy sur une page marketing et perdu une heure à comprendre pourquoi un nom de classe sur la section hero avait aussi changé, voici l'outil qui le révèle en quelques secondes. Pour de la prose simple, notre diff de texte est le bon choix. Le cousin strict du HTML, XML, a un diff XML dédié. Et comme Markdown se compile souvent en HTML dans les builds de sites statiques, le diff Markdown est un voisin utile.
C'est un diff au niveau du texte avec coloration syntaxique consciente du HTML, pas un diff de DOM. La comparaison s'exécute au niveau du caractère, puis une passe de post-traitement sémantique décale les surlignages pour qu'ils tombent sur les noms de balise, les valeurs d'attribut et le texte visible plutôt que sur de la ponctuation aléatoire. Les insertions apparaissent en vert dans le panneau de droite, les suppressions en rouge à gauche.
HTML a plus de bizarreries de parsing que les gens ne s'en souviennent, et la plupart ne comptent que lorsque vous comparez deux fichiers en tant que texte. D'après l'algorithme de parsing, l'ordre des attributs n'est pas significatif, le quoting d'attributs peut être en simples, doubles ou absent pour certaines valeurs, et les noms de balises et d'attributs sont insensibles à la casse. Un diff de texte signalera quand même chaque réordonnancement et changement de casse. Le contournement pratique est de formater les deux côtés avec le même outil (Prettier avec parser: "html" fonctionne bien) pour que les panneaux soient normalisés avant que vous lisiez le diff.
Cet outil ne parse pas le document en arbre DOM pour comparer des nœuds. Cela signifie que deux fichiers qui s'affichent identiquement dans un navigateur, par exemple un avec <img src="a.png"> et un avec <img src='a.png' />, apparaîtront tout de même comme différents ici. Si vous avez besoin d'une vraie comparaison structurelle, parsez les deux côtés avec DOMParser et parcourez les arbres vous-même, ou passez les deux par Tidy d'abord. Pour 95% des cas de revue de code (une correction de copy, un swap d'attribut, l'ajout d'un aria-label), le diff de texte est plus rapide et plus clair.
Deux panneaux de texte, un diff. Pas d'inscription, pas d'upload, pas d'aller-retour serveur.
Collez l'ancien HTML à gauche, le nouveau HTML à droite. Ou cliquez sur Upload de chaque côté pour charger directement un fichier .html, .htm ou .eml. Le bouton Exemple remplit les deux panneaux avec un petit extrait de landing page si vous voulez d'abord voir l'outil en action.
Cliquez sur Format sur chaque panneau pour pretty-print avec une indentation cohérente. Cela normalise les espaces et les sauts de ligne pour que le diff se concentre sur de vrais changements de contenu, pas sur du bruit de formatage entre un fichier Windows CRLF et un fichier Unix LF. Le badge de validation passe au vert quand le document parse proprement.
Les suppressions apparaissent avec un surlignage rouge à gauche, les insertions avec un surlignage vert à droite. Les compteurs de changements dans chaque en-tête vous disent combien de modifications distinctes le diff a trouvées entre les noms de balise, les valeurs d'attribut et le texte visible. Faites défiler un panneau et l'autre suit en synchro.
Un changement de template du CMS sort et un consommateur en aval signale du markup hero cassé. Curl le HTML rendu avant et après le déploiement, collez les deux dans le diff, et le <div> wrapper fautif ou le swap de classe est évident. Utile pour les upgrades de thèmes WordPress, les éditions de layouts Hugo et Jekyll, et toute sortie rendue côté serveur où le template source n'est pas directement lisible.
Le HTML d'email ne pardonne pas. Outlook utilise toujours le moteur de rendu de Word, donc un nesting de <table> intervert ou un attribut style inline renommé peut briser la mise en page. Diffez la variante A contre la variante B avant de pousser la campagne, puis passez les deux par Litmus ou Email on Acid. Attraper un cellpadding="0" manquant dans le diff coûte moins cher que de l'attraper dans mille boîtes de réception.
Une PR ajoute des attributs aria-label, role et aria-describedby sur la moitié des composants. Le diff de texte rend trivial le fait de confirmer que chaque élément interactif a gagné le bon attribut, qu'aucun role="presentation" n'a été appliqué à un vrai bouton, et qu'aucun élément focusable n'a perdu son nom accessible. Couplez cela avec axe DevTools ou Lighthouse pour l'audit réel.
Une copywriter renvoie la home avec des titres révisés et un nouveau CTA. Collez le HTML en production contre le HTML proposé et le diff vous dit exactement quels <h1>, <p> et textes de boutons ont changé, plus toutes les éditions de class ou href qui se sont glissées avec. Plus rapide qu'un Word avec suivi des modifications et survit intact à l'aller-retour vers le codebase.
Après un bump de version de DOMPurify ou sanitize-html, faites des tests de régression du sanitizer avec des payloads connus comme mauvais et diffez la sortie contre une baseline saine précédente. Un sanitizer qui préserve soudainement <svg onload="..."> ou des URLs javascript: dans les attributs href est exactement le genre de régression que vous voulez attraper en CI avant qu'elle ne sorte. Le diff fait sauter aux yeux les changements d'un seul caractère (un échappement manquant).
Une courte antisèche pour les détails de parsing que cet outil fait remonter le plus souvent. Tout est ancré dans le WHATWG HTML Living Standard.
| Topic | What this tool does |
|---|---|
| Éléments void | <img>, <br>, <input>, <meta>, <link>, <hr> et compagnie n'ont pas de balise de fermeture. La barre oblique de fin style XHTML <br /> est autorisée en HTML5 mais s'affiche comme un no-op ; le parser l'ignore. |
| Ordre des attributs | Non significatif d'après la spec HTML. <a href="/x" class="btn"> et <a class="btn" href="/x"> sont identiques pour un parser. Un diff texte signale le swap ; formatez les deux côtés pour garder l'ordre stable. |
| Quoting d'attributs | Guillemets doubles, guillemets simples, ou pas de guillemets du tout pour les valeurs sans espaces ou caractères spéciaux. id=hero, id='hero' et id="hero" sont équivalents. La plupart des guides de style exigent des guillemets doubles pour la cohérence. |
| Attributs booléens | C'est la présence qui compte. <input disabled>, <input disabled=""> et <input disabled="disabled"> désactivent tous l'input. La spec recommande la forme nue ; XHTML exigeait la forme verbeuse. |
| Sensibilité à la casse | Les noms de balise et d'attribut sont insensibles à la casse en HTML (<DIV> égale <div>). Les valeurs d'attribut sont sensibles à la casse (id="Hero" diffère de id="hero"). La convention depuis HTML5 est balises et attributs en minuscules. |
| Entités de caractère | Cinq prédéfinies : & < > " '. Plus des entités nommées comme et des références numériques comme é pour les lettres accentuées. Les sections CDATA ne sont valides que dans le contenu étranger (SVG, MathML), pas en HTML standard. |
| DOCTYPE | HTML5 utilise la forme courte <!DOCTYPE html>. Les anciens doctypes XHTML 1.0 sont toujours parsés mais déclenchent le mode no-quirks de la même façon. Un DOCTYPE manquant ou malformé fait passer la page en mode quirks, ce qui change le comportement du modèle de boîte. |
| Espaces blancs | Les suites d'espaces, tabs et retours à la ligne se réduisent à un seul espace au rendu, sauf à l'intérieur de <pre>, <textarea> et des éléments avec CSS white-space: pre. Le texte source est conservé, donc un diff texte voit chaque octet. |
Sous le capot, c'est le même algorithme au niveau du caractère, mais l'éditeur utilise la coloration en mode HTML pour que les balises, les attributs et les entités s'affichent avec la coloration syntaxique familière pendant que vous lisez le diff. Le bouton Format utilise un pretty-printer conscient du HTML, pas un reformatage de texte générique, ce qui garde le nesting des éléments intact. Pour de la prose sans markup, notre diff texte fait l'affaire ; pour tout fichier où les frontières de balises comptent, cette vue est plus facile à scanner.
Pas pour un navigateur. Le HTML Living Standard dit que l'ordre des attributs sur une balise d'ouverture n'est pas significatif, donc <a href="/x" class="btn"> et <a class="btn" href="/x"> s'affichent identiques. Un diff texte signalera quand même le swap parce qu'il voit les caractères bruts. La solution est de formater les deux côtés avec le même outil (Prettier et html-validate trient raisonnablement) pour que l'ordre des attributs soit stable avant la comparaison.
HTML réduit la plupart des suites d'espaces à un seul espace au rendu, donc deux fichiers qui semblent identiques dans un navigateur peuvent avoir un texte source très différent. À l'intérieur de <pre> et <textarea>, les espaces sont conservés. Le diff est au niveau du texte, donc chaque espace, tab et retour à la ligne compte. Formatez les deux côtés d'abord pour normaliser l'indentation ; seuls les changements significatifs resteront surlignés.
Cet outil fait un diff texte, pas un diff DOM, donc le moyen le plus fiable d'ignorer le bruit de formatage est de formater les deux côtés avec le même pretty-printer (Prettier, HTML Tidy ou htmlhint --format) avant de coller. Cela normalise l'indentation, le quoting des attributs et les espaces en fin de ligne. Pour une vraie comparaison au niveau de l'arbre, parsez chaque côté avec DOMParser et parcourez les nœuds ; pour la revue de code et le travail de copy-edit, le workflow formater-puis-diff est plus rapide et attrape les mêmes bugs.
Le contenu de <script> et <style> est diffé comme du texte brut, caractère par caractère. Cela signifie qu'un changement CSS d'une ligne à l'intérieur d'un bloc <style> ou une fonction renommée à l'intérieur d'un <script> inline apparaîtra exactement où vous l'attendez. Pour des blocs de script plus larges, considérez les extraire dans des fichiers .js et les differ séparément. Le mode HTML de l'éditeur surligne quand même les frontières de script et style pour que le markup environnant reste lisible.
Les fichiers sont lus comme UTF-8, qui est le défaut pour HTML5 et ce que la balise <meta charset="UTF-8"> déclare. Les entités nommées comme &, <, > et sont diffées comme leur texte source littéral, pas leur forme décodée, donc un swap de vers un vrai caractère espace apparaîtra comme un changement. Si deux fichiers s'affichent identiques dans le navigateur mais que le diff s'allume au début, soupçonnez un byte order mark UTF-8 sur l'un d'eux.
Votre HTML ne quitte jamais votre navigateur. Le formateur, le validateur et le diff s'exécutent tous sur votre machine, en local. Pas d'analytics sur votre saisie, pas de logs, pas d'aller-retour cloud "utile". La coloration syntaxique suit le WHATWG HTML Living Standard, et la recommandation plus ancienne W3C HTML 5.2 est une référence croisée utile. La doc de référence au niveau des éléments est sur MDN, et les patterns d'accessibilité viennent du ARIA Authoring Practices Guide. Lecture de fond sur le format lui-même sur Wikipedia.