Incolla, formatta e confronta due documenti HTML fianco a fianco. Evidenziazione della sintassi consapevole dei tag e controlli di well-formedness in tempo reale integrati.
Uno strumento gratuito nel browser per confrontare due documenti HTML. Incolla la vecchia versione di una landing page a sinistra, la nuova a destra, e i cambiamenti si illuminano tag per tag e attributo per attributo. Niente viene caricato.
Il diff stesso lavora a livello di carattere. Il pulsante Format su ogni pannello riformatta il tuo HTML con indentazione coerente, come farebbero Prettier o HTML Tidy. L'evidenziazione della sintassi segue il WHATWG HTML Living Standard, così elementi void, attributi booleani e riferimenti a entità vengono tutti renderizzati correttamente mentre leggi il diff.
Se hai mai messo in produzione una correzione di copy su una pagina di marketing e hai perso un'ora a capire perché anche un nome di classe sulla sezione hero era cambiato, questo è lo strumento che lo fa emergere in pochi secondi. Per prosa semplice, il nostro diff di testo è la scelta giusta. Il cugino rigoroso di HTML, XML, ha un diff XML dedicato. E poiché Markdown spesso compila in HTML nei build di siti statici, il diff Markdown è un vicino utile.
Questo è un diff a livello di testo con evidenziazione della sintassi consapevole di HTML, non un diff del DOM. Il confronto gira a livello di carattere, poi un passaggio di post-elaborazione semantica sposta le evidenziazioni perché atterrino su nomi di tag, valori di attributo e testo visibile invece che su punteggiatura casuale. Le inserzioni appaiono in verde nel pannello destro, le eliminazioni in rosso a sinistra.
HTML ha più stranezze di parsing di quante la gente ricordi, e la maggior parte conta solo quando confronti due file come testo. Per l'algoritmo di parsing, l'ordine degli attributi non è significativo, le virgolette degli attributi possono essere singole, doppie o assenti per alcuni valori, e i nomi di tag e attributo sono case-insensitive. Un diff di testo segnala comunque ogni riordino e cambio di maiuscole. Il workaround pratico è formattare entrambi i lati con lo stesso strumento (Prettier con parser: "html" funziona bene) così i pannelli sono normalizzati prima che tu legga il diff.
Questo strumento non parsifica il documento in un albero DOM e confronta nodi. Significa che due file che renderizzano in modo identico in un browser, ad esempio uno con <img src="a.png"> e uno con <img src='a.png' />, appariranno comunque diversi qui. Se ti serve un confronto veramente strutturale, parsifica entrambi i lati con DOMParser e percorri gli alberi tu stesso, oppure passali entrambi prima per Tidy. Per il 95% dei casi di code review (una correzione di copy, uno scambio di attributo, l'aggiunta di un aria-label), il diff di testo è più rapido e più chiaro.
Due pannelli di testo, un diff. Senza registrazione, senza upload, senza giro al server.
Incolla il vecchio HTML a sinistra, il nuovo HTML a destra. Oppure clicca su Carica su uno dei lati per caricare direttamente un file .html, .htm o .eml. Il pulsante Esempio riempie entrambi i pannelli con un piccolo frammento di landing page se vuoi vedere prima lo strumento in azione.
Clicca Format su ogni pannello per pretty-print con indentazione coerente. Questo normalizza spazi e ritorni a capo così il diff si concentra su veri cambiamenti di contenuto, non su rumore di formattazione tra un file Windows con CRLF e uno Unix con LF. Il badge di validazione diventa verde quando il documento parsifica pulito.
Le eliminazioni appaiono con evidenziazione rossa a sinistra, le inserzioni con evidenziazione verde a destra. I conteggi delle modifiche in ogni intestazione ti dicono quante modifiche distinte il diff ha trovato tra nomi di tag, valori di attributo e testo visibile. Scorri uno dei pannelli e l'altro segue in sincronia.
Esce un cambio di template del CMS e un consumatore a valle segnala markup hero rotto. Curl l'HTML renderizzato prima e dopo il deploy, incolla entrambi nel diff, e il <div> wrapper colpevole o il cambio di classe è ovvio. Utile per upgrade di temi WordPress, modifiche di layout in Hugo e Jekyll, e qualsiasi output renderizzato lato server dove il template sorgente non è direttamente leggibile.
L'HTML delle email non perdona. Outlook usa ancora il motore di rendering di Word, quindi un annidamento di <table> scambiato o un attributo style inline rinominato può frantumare il layout. Diff la variante A contro la variante B prima di lanciare la campagna, poi passa entrambi attraverso Litmus o Email on Acid. Beccare un cellpadding="0" mancante nel diff costa meno che beccarlo in mille caselle di posta.
Una PR aggiunge attributi aria-label, role e aria-describedby su metà dei componenti. Il diff di testo rende banale confermare che ogni elemento interattivo ha guadagnato l'attributo giusto, che nessun role="presentation" è stato applicato a un vero pulsante, e che nessun elemento focalizzabile ha perso il suo nome accessibile. Abbinalo con axe DevTools o Lighthouse per l'audit vero.
Una copywriter rimanda la home con titoli rivisti e un nuovo CTA. Incolla l'HTML in produzione contro l'HTML proposto e il diff ti dice esattamente quali <h1>, <p> e testi di pulsante sono cambiati, più qualunque modifica di class o href intrufolatasi. Più rapido di un Word con revisioni e sopravvive intatto al viaggio di ritorno nel codebase.
Dopo un bump di versione di DOMPurify o sanitize-html, fai test di regressione del sanitizer con payload noti come cattivi e diff l'output contro una baseline buona precedente. Un sanitizer che improvvisamente preserva <svg onload="..."> o URL javascript: negli attributi href è esattamente il tipo di regressione che vuoi beccare in CI prima che vada in produzione. Il diff fa saltare all'occhio cambi di un singolo carattere (un escape mancante).
Un breve cheat sheet per i dettagli di parsing che questo strumento fa emergere più spesso. Tutto fondato nel WHATWG HTML Living Standard.
| Topic | What this tool does |
|---|---|
| Elementi void | <img>, <br>, <input>, <meta>, <link>, <hr> e compagnia non hanno tag di chiusura. Lo slash finale stile XHTML <br /> è permesso in HTML5 ma renderizza come no-op; il parser lo ignora. |
| Ordine degli attributi | Non significativo secondo la spec HTML. <a href="/x" class="btn"> e <a class="btn" href="/x"> sono identici per un parser. Un diff di testo segnala lo scambio; formatta entrambi i lati per mantenere l'ordine stabile. |
| Virgolette degli attributi | Doppi apici, singoli apici o nessuna virgoletta per valori senza spazi o caratteri speciali. id=hero, id='hero' e id="hero" sono equivalenti. La maggior parte delle guide di stile richiede doppi apici per coerenza. |
| Attributi booleani | Quel che conta è la presenza. <input disabled>, <input disabled=""> e <input disabled="disabled"> disabilitano l'input tutti. La spec raccomanda la forma nuda; XHTML richiedeva la forma verbosa. |
| Sensibilità maiuscole | I nomi di tag e attributo sono case-insensitive in HTML (<DIV> equivale a <div>). I valori degli attributi sono case-sensitive (id="Hero" differisce da id="hero"). La convenzione da HTML5 sono tag e attributi minuscoli. |
| Entità di carattere | Cinque predefinite: & < > " '. Più entità nominate come e riferimenti numerici come é per lettere accentate. Le sezioni CDATA sono valide solo in foreign content (SVG, MathML), non in HTML regolare. |
| DOCTYPE | HTML5 usa la forma corta <!DOCTYPE html>. I doctypes XHTML 1.0 più vecchi sono ancora parsificati ma innescano la modalità no-quirks allo stesso modo. Un DOCTYPE mancante o malformato fa cadere la pagina in modalità quirks, che cambia il comportamento del box model. |
| Spazio bianco | Sequenze di spazi, tab e ritorni a capo collassano in un singolo spazio quando renderizzate, eccetto dentro <pre>, <textarea> ed elementi con CSS white-space: pre. Il testo sorgente è preservato, quindi un diff di testo vede ogni byte. |
Sotto il cofano è lo stesso algoritmo a livello di carattere, ma l'editor usa l'evidenziazione modalità HTML così tag, attributi ed entità si renderizzano con la familiare colorazione di sintassi mentre leggi il diff. Il pulsante Format usa un pretty-printer consapevole di HTML, non una riformattazione di testo generica, il che mantiene l'annidamento degli elementi intatto. Per prosa senza markup il nostro diff di testo va bene; per qualsiasi file dove i confini dei tag contano, questa vista è più facile da scansionare.
Non per un browser. L'HTML Living Standard dice che l'ordine degli attributi su un tag di apertura non è significativo, quindi <a href="/x" class="btn"> e <a class="btn" href="/x"> renderizzano in modo identico. Un diff di testo segnalerà comunque lo scambio perché vede i caratteri grezzi. La soluzione è formattare entrambi i lati con lo stesso strumento (Prettier e html-validate ordinano sensatamente) così l'ordine degli attributi è stabile prima del confronto.
HTML collassa la maggior parte delle sequenze di spazi in un singolo spazio quando renderizza, quindi due file che sembrano identici in un browser possono avere testo sorgente molto diverso. Dentro <pre> e <textarea>, lo spazio è preservato. Il diff è a livello di testo, quindi ogni spazio, tab e ritorno a capo conta. Formatta prima entrambi i lati per normalizzare l'indentazione; rimarranno evidenziati solo i cambiamenti significativi.
Questo strumento fa un diff di testo, non un diff DOM, quindi il modo più affidabile di ignorare il rumore di formattazione è formattare entrambi i lati con lo stesso pretty-printer (Prettier, HTML Tidy o htmlhint --format) prima di incollare. Questo normalizza indentazione, virgolette degli attributi e spazio finale. Per un confronto vero a livello di albero, parsifica ogni lato con DOMParser e percorri i nodi; per code review e lavoro di copy-edit, il flusso formatta-poi-diff è più rapido e becca gli stessi bug.
Il contenuto di <script> e <style> viene confrontato come testo normale, carattere per carattere. Significa che un cambio CSS di una riga dentro un blocco <style> o una funzione rinominata dentro uno <script> inline apparirà esattamente dove te lo aspetti. Per blocchi di script più grandi considera di estrarli in file .js e confrontarli separatamente. La modalità HTML dell'editor evidenzia comunque i confini di script e style così il markup circostante resta leggibile.
I file vengono letti come UTF-8, che è il default per HTML5 e quello che il tag <meta charset="UTF-8"> dichiara. Entità nominate come &, <, > e vengono confrontate come il loro testo sorgente letterale, non la forma decodificata, quindi uno scambio da a un vero carattere spazio apparirà come un cambiamento. Se due file renderizzano identici nel browser ma il diff si accende all'inizio, sospetta un byte order mark UTF-8 su uno di loro.
Il tuo HTML non lascia mai il tuo browser. Il formattatore, il validatore e il diff girano tutti sulla tua macchina, in locale. Niente analytics sul tuo input, niente log, nessun giro "di cortesia" al cloud. L'evidenziazione della sintassi segue il WHATWG HTML Living Standard, e la più vecchia raccomandazione W3C HTML 5.2 è un riferimento incrociato utile. La documentazione di riferimento a livello di elemento è su MDN, e i pattern di accessibilità vengono dal ARIA Authoring Practices Guide. Lettura di sfondo sul formato stesso su Wikipedia.