Zwei HTML-Dokumente einfügen, formatieren und nebeneinander vergleichen. Tag-bewusstes Syntax-Highlighting und Live-Wohlgeformtheitsprüfung integriert.
Ein kostenloses Tool im Browser zum Vergleichen zweier HTML-Dokumente. Füge die alte Version einer Landingpage links ein, die neue rechts, und die Änderungen leuchten Tag für Tag und Attribut für Attribut auf. Nichts wird hochgeladen.
Der Diff selbst arbeitet auf Zeichenebene. Der Format-Button in jedem Pane formatiert dein HTML mit konsistenter Einrückung neu, so wie es Prettier oder HTML Tidy täten. Das Syntax-Highlighting folgt dem WHATWG HTML Living Standard, sodass void-Elemente, boolesche Attribute und Entitätsreferenzen während des Lesens des Diffs alle korrekt dargestellt werden.
Wenn du je eine Textänderung an einer Marketingseite ausgespielt und eine Stunde damit verbracht hast herauszufinden, warum sich auch ein Klassenname am Hero-Bereich geändert hat, ist dies das Tool, das es in Sekunden sichtbar macht. Für reinen Fließtext ist unser Text-Diff die richtige Wahl. HTMLs strikter Cousin XML hat einen eigenen XML-Diff. Und weil Markdown in Static-Site-Builds oft zu HTML kompiliert wird, ist der Markdown-Diff ein nützlicher Nachbar.
Dies ist ein Diff auf Textebene mit HTML-bewusstem Syntax-Highlighting, kein DOM-Diff. Der Vergleich läuft auf Zeichenebene, danach verschiebt ein semantischer Nachverarbeitungsschritt die Hervorhebungen, sodass sie auf Tag-Namen, Attributwerten und sichtbarem Text landen statt auf zufälligen Satzzeichen. Einfügungen erscheinen grün im rechten Pane, Löschungen rot im linken.
HTML hat mehr Parsing-Eigenheiten, als die Leute sich erinnern, und die meisten zählen erst, wenn man zwei Dateien als Text vergleicht. Laut Parsing-Algorithmus ist die Attributreihenfolge nicht signifikant, das Quoting kann je nach Wert einfach, doppelt oder ganz abwesend sein, und Tag- und Attributnamen sind case-insensitiv. Ein Text-Diff markiert dennoch jede Umstellung und jeden Case-Wechsel. Der praktische Workaround ist, beide Seiten mit demselben Tool zu formatieren (Prettier mit parser: "html" funktioniert gut), damit die Panes vor dem Lesen des Diffs normalisiert sind.
Dieses Tool parst das Dokument nicht in einen DOM-Baum und vergleicht keine Knoten. Das heißt, zwei Dateien, die im Browser identisch dargestellt werden, etwa eine mit <img src="a.png"> und eine mit <img src='a.png' />, erscheinen hier trotzdem unterschiedlich. Wenn du einen echten Strukturvergleich brauchst, parse beide Seiten mit DOMParser und gehe die Bäume selbst durch oder lass beide vorher durch Tidy laufen. Für 95% der Code-Review-Fälle (eine Textänderung, ein Attribut-Swap, ein hinzugefügtes aria-label) ist der Text-Diff schneller und klarer.
Zwei Text-Panes, ein Diff. Keine Anmeldung, kein Upload, kein Server-Roundtrip.
Füge das alte HTML links ein, das neue HTML rechts. Oder klicke auf einer der Seiten Hochladen, um eine .html-, .htm- oder .eml-Datei direkt zu laden. Der Beispiel-Button füllt beide Panes mit einem kleinen Landingpage-Snippet, falls du das Tool erst in Aktion sehen möchtest.
Klicke Format in jedem Pane, um mit konsistenter Einrückung pretty-printzuformatieren. Das normalisiert Whitespace und Zeilenumbrüche, damit sich der Diff auf echte Inhaltsänderungen konzentriert und nicht auf Formatierungsrauschen einer Windows-CRLF- gegenüber einer Unix-LF-Datei. Das Validierungs-Badge wird grün, wenn das Dokument sauber parst.
Löschungen erscheinen mit roter Hervorhebung links, Einfügungen mit grüner Hervorhebung rechts. Die Änderungszahlen in jedem Header sagen dir, wie viele unterschiedliche Edits der Diff über Tag-Namen, Attributwerte und sichtbaren Text hinweg gefunden hat. Scrolle in einem Pane, und der andere folgt im Gleichschritt.
Eine CMS-Template-Änderung geht raus und ein nachgelagerter Konsument meldet kaputtes Hero-Markup. Curle das gerenderte HTML vor und nach dem Deploy, füge beides in den Diff ein, und der schuldige Wrapper-<div> oder Klassen-Tausch ist offensichtlich. Nützlich bei WordPress-Theme-Upgrades, Hugo- und Jekyll-Layout-Edits und jeder serverseitig gerenderten Ausgabe, bei der das Quell-Template nicht direkt lesbar ist.
E-Mail-HTML verzeiht nichts. Outlook nutzt immer noch die Word-Rendering-Engine, sodass eine vertauschte <table>-Verschachtelung oder ein umbenanntes inline-style-Attribut das Layout zertrümmern kann. Diff Variante A gegen Variante B, bevor du die Kampagne ausspielst, dann beides durch Litmus oder Email on Acid jagen. Ein fehlendes cellpadding="0" im Diff zu erwischen ist günstiger, als es in tausend Postfächern zu erwischen.
Eine PR ergänzt aria-label-, role- und aria-describedby-Attribute über die halbe Komponentenbasis. Der Text-Diff macht es trivial zu bestätigen, dass jedes interaktive Element das richtige Attribut bekam, dass kein role="presentation" auf einen echten Button gesetzt wurde und dass kein fokussierbares Element seinen accessible name verloren hat. Kombiniere das mit axe DevTools oder Lighthouse für das eigentliche Audit.
Eine Texterin schickt die Startseite mit überarbeiteten Headlines und einem neuen CTA zurück. Füge das Live-HTML gegen das vorgeschlagene HTML ein, und der Diff sagt dir genau, welche <h1>-, <p>- und Button-Texte sich geändert haben, plus jegliche Klassen- oder href-Edits, die sich miteingeschlichen haben. Schneller als ein Word-Dokument mit Änderungsverfolgung und es übersteht den Round-Trip in die Codebase intakt.
Nach einem DOMPurify- oder sanitize-html-Versionssprung führst du Regressionstests des Sanitizers mit bekannt schlechten Payloads durch und diffst die Ausgabe gegen eine vorherige gute Baseline. Ein Sanitizer, der plötzlich <svg onload="..."> oder javascript:-URLs in href-Attributen erhält, ist genau die Art Regression, die du in CI fangen willst, bevor sie ausgespielt wird. Der Diff lässt Ein-Zeichen-Änderungen (ein fehlendes Escape) ins Auge springen.
Ein kurzer Spickzettel zu den Parsing-Details, die dieses Tool am häufigsten zutage fördert. Alles fundiert im WHATWG HTML Living Standard.
| Topic | What this tool does |
|---|---|
| Void-Elemente | <img>, <br>, <input>, <meta>, <link>, <hr> und Konsorten haben kein Schluss-Tag. Der XHTML-artige End-Slash <br /> ist in HTML5 erlaubt, wird aber als No-op gerendert; der Parser ignoriert ihn. |
| Attributreihenfolge | Laut HTML-Spec nicht signifikant. <a href="/x" class="btn"> und <a class="btn" href="/x"> sind für einen Parser identisch. Ein Text-Diff markiert den Tausch; formatiere beide Seiten, um die Reihenfolge stabil zu halten. |
| Attribut-Quoting | Doppelte Anführungszeichen, einfache oder gar keine für Werte ohne Leerzeichen oder Sonderzeichen. id=hero, id='hero' und id="hero" sind äquivalent. Die meisten Style-Guides verlangen aus Konsistenz doppelte Anführungszeichen. |
| Boolesche Attribute | Es zählt die Anwesenheit. <input disabled>, <input disabled=""> und <input disabled="disabled"> deaktivieren das Input alle. Die Spec empfiehlt die nackte Form; XHTML verlangte die ausführliche Form. |
| Groß-/Kleinschreibung | Tag- und Attributnamen sind in HTML case-insensitiv (<DIV> entspricht <div>). Attributwerte sind case-sensitiv (id="Hero" unterscheidet sich von id="hero"). Konvention seit HTML5 sind kleingeschriebene Tags und Attribute. |
| Zeichenentitäten | Fünf eingebaute: & < > " '. Plus benannte Entitäten wie und numerische Referenzen wie é für akzentuierte Buchstaben. CDATA-Sektionen sind nur in foreign content (SVG, MathML) gültig, nicht in regulärem HTML. |
| DOCTYPE | HTML5 nutzt die Kurzform <!DOCTYPE html>. Ältere XHTML-1.0-DOCTYPES werden weiterhin geparst, lösen aber denselben No-Quirks-Modus aus. Ein fehlender oder fehlerhafter DOCTYPE wirft die Seite in den Quirks-Modus, was das Box-Modell-Verhalten ändert. |
| Whitespace | Folgen von Leerzeichen, Tabs und Zeilenumbrüchen kollabieren beim Rendern zu einem einzigen Leerzeichen, außer innerhalb von <pre>, <textarea> und Elementen mit CSS white-space: pre. Der Quelltext wird beibehalten, sodass ein Text-Diff jedes Byte sieht. |
Unter der Haube ist es derselbe Algorithmus auf Zeichenebene, aber der Editor nutzt das HTML-Modus-Highlighting, damit Tags, Attribute und Entitäten während des Diff-Lesens mit der vertrauten Syntaxfärbung dargestellt werden. Der Format-Button verwendet einen HTML-bewussten Pretty-Printer, keine generische Textumformung, was die Element-Verschachtelung intakt lässt. Für Prosa ohne Markup reicht unser Text-Diff; für jede Datei, in der Tag-Grenzen wichtig sind, ist diese Ansicht leichter zu überfliegen.
Für einen Browser nicht. Der HTML Living Standard sagt, dass die Attributreihenfolge an einem Start-Tag nicht signifikant ist, sodass <a href="/x" class="btn"> und <a class="btn" href="/x"> identisch dargestellt werden. Ein Text-Diff markiert den Tausch trotzdem, weil er die rohen Zeichen sieht. Die Lösung ist, beide Seiten mit demselben Tool zu formatieren (Prettier und html-validate sortieren sinnvoll), damit die Attributreihenfolge vor dem Vergleich stabil ist.
HTML kollabiert beim Rendering die meisten Whitespace-Folgen zu einem einzelnen Leerzeichen, sodass zwei Dateien, die im Browser identisch aussehen, völlig unterschiedlichen Quelltext haben können. Innerhalb von <pre> und <textarea> bleibt Whitespace erhalten. Der Diff arbeitet auf Textebene, also zählt jedes Leerzeichen, jeder Tab und jeder Zeilenumbruch. Formatiere zuerst beide Seiten, um die Einrückung zu normalisieren; nur die bedeutsamen Änderungen bleiben hervorgehoben.
Dieses Tool macht einen Text-Diff, keinen DOM-Diff, deshalb ist der zuverlässigste Weg, Formatierungs-Rauschen zu ignorieren, beide Seiten vor dem Einfügen mit demselben Pretty-Printer zu formatieren (Prettier, HTML Tidy oder htmlhint --format). Das normalisiert Einrückung, Attribut-Quoting und nachgestellten Whitespace. Für einen echten Vergleich auf Baum-Ebene parse jede Seite mit DOMParser und gehe die Knoten durch; für Code-Review und Copy-Edit-Arbeit ist der Format-dann-Diff-Workflow schneller und fängt dieselben Bugs.
Der Inhalt von <script> und <style> wird als reiner Text Zeichen für Zeichen gediffd. Das heißt, eine einzeilige CSS-Änderung in einem <style>-Block oder eine umbenannte Funktion in einem inline-<script> erscheint genau dort, wo du sie erwartest. Bei größeren Skript-Blöcken erwäge, sie in .js-Dateien auszulagern und separat zu diffen. Der HTML-Modus im Editor hebt Skript- und Style-Grenzen weiterhin hervor, sodass das umliegende Markup lesbar bleibt.
Dateien werden als UTF-8 gelesen, was der Standard für HTML5 ist und was das <meta charset="UTF-8">-Tag deklariert. Benannte Entitäten wie &, <, > und werden als ihr literaler Quelltext gediffd, nicht in dekodierter Form, sodass ein Wechsel von zu einem echten Leerzeichen als Änderung erscheint. Wenn zwei Dateien im Browser identisch dargestellt werden, der Diff aber am Anfang aufleuchtet, vermute eine UTF-8 Byte Order Mark in einer von ihnen.
Dein HTML verlässt deinen Browser nicht. Formatter, Validator und Diff laufen alle lokal auf deiner Maschine. Keine Analytics auf deinem Input, keine Logs, kein "hilfreicher" Cloud-Roundtrip. Das Syntax-Highlighting folgt dem WHATWG HTML Living Standard, und die ältere W3C HTML 5.2-Empfehlung ist eine nützliche Querreferenz. Element-Referenzdokumentation steht auf MDN, und Accessibility-Patterns kommen aus dem ARIA Authoring Practices Guide. Hintergrundlektüre zum Format selbst auf Wikipedia.