Incolla la versione A a sinistra, la versione B a destra e vedi esattamente cosa è cambiato. Niente git clone, niente IDE, niente registrazione. Gira interamente nel browser.
Uno strumento gratuito nel browser per confrontare due versioni di codice senza aprire Git, GitHub o l'IDE. Incolla la vecchia versione a sinistra, la nuova a destra, e le differenze vengono evidenziate carattere per carattere. Il testo non lascia mai la tua macchina, cosa che conta quando lo snippet viene da un repo privato o da un branch non ancora mergeato.
È pensato per il momento in cui un collega lascia due versioni di una funzione su Slack e chiede "cosa è cambiato?". Tirare su un checkout locale per un diff di 12 righe è eccessivo. Aprire la PR view di GitHub se la PR ancora non c'è, anche. Due pannelli di testo, un diff, fatto in quindici secondi.
Non sostituisce git diff su un working tree reale. Non può mettere in stage gli hunk, applicare patch o lanciare blame. Quello che fa è la parte che serve più spesso: prendere due blocchi di testo arbitrari e mostrare le modifiche tra di essi. Sotto, il diff usa lo stesso motore del nostro strumento compare-text, vestito per la code review.
Il diff lavora carattere per carattere, poi un passaggio di pulizia semantica raggruppa le modifiche in blocchi leggibili, in modo che l'evidenziazione cada su un identificatore rinominato e non su ogni singola lettera al suo interno. Le inserzioni nel pannello di destra appaiono in verde; le rimozioni nel pannello di sinistra in rosso. I due pannelli scorrono in sincrono: se trovi una modifica alla riga 80 da un lato, l'altro lato salta con te.
Perché a livello di carattere e non di riga? Perché per snippet brevi la sola vista per riga è troppo grossolana. Rinominare una variabile da id a userId è un solo cambio di identificatore; un diff per riga ti farebbe vedere l'intera riga eliminata più una nuova riga inserita, tecnicamente vero ma rende la modifica reale più difficile da vedere. La modalità carattere con pulizia semantica evidenzia il token rinominato e lascia il resto della riga in pace. Per file lunghi il bilanciamento si ribalta, ed è per questo che il classico diff per riga è quello che Git usa di default. Entrambi hanno il loro posto. Questo strumento offre la vista adatta agli snippet.
Cosa lo strumento volutamente non fa: non conosce la sintassi. Non parsa JavaScript, Python o Java. Un blocco riformattato con la stessa semantica continuerà ad apparire come diff, perché per un comparatore di testo è testo diverso. Se vuoi un diff consapevole del formato per payload strutturati, la nostra pagina compare-json lo fa per JSON, compare-yaml per YAML e compare-xml per XML e file POM. Per codice sorgente puro, il diff testuale più i tuoi occhi è di solito più rapido che configurare uno strumento sintattico per una cosa una tantum.
Due pannelli di testo, un diff. Niente login, niente upload, nessun formato di patch da parsare.
Copia la vecchia versione della funzione, del file o dello snippet dal tuo editor, terminale o da dove si trova. Ctrl+C e poi incolla nel pannello di sinistra. Se stai estraendo da git show <commit>, copia il corpo del file e non l'header del patch, in modo che il diff evidenzi solo le vere modifiche al codice.
Stessa cosa con la nuova versione. Se un collega l'ha incollata su Slack, Teams o per email, copia direttamente da lì. Spazi e indentazione vengono preservati all'incollaggio, cosa che conta in linguaggi dove l'indentazione è significativa come Python e YAML. Tab vs spazi appariranno come differenza se i due snippet non concordano.
Le rimozioni appaiono come strikethrough rossi a sinistra; le inserzioni come verde a destra. I contatori di modifiche in ogni intestazione ti dicono quante modifiche distinte sono state rilevate. Leggi le evidenziazioni, concentrati prima sui cambi di logica (control flow, condizionali, gestione errori) e tratta rinomine pure o cambi di formato come priorità inferiore nella revisione.
Qualcuno lascia due blocchi di codice in chat e chiede quale sia giusto. Clonare il repo, cambiare branch e aprire l'IDE per uno snippet di 20 righe è fatica sprecata. Incolla entrambi nello strumento di diff e hai la risposta prima del messaggio successivo. È il motivo più comune per cui la gente ricorre a un diff online.
Pipeline di CI, Dockerfile, package.json e YAML dei workflow GitHub Actions derivano in continuazione. Un compagno di team modifica .github/workflows/ci.yml su un branch, la build si rompe, e vuoi vedere cosa è cambiato senza fare checkout del suo branch. Incolla la versione di main accanto alla versione del branch rotto e lo step colpevole emerge in pochi secondi. Per i file di workflow, la nostra pagina di diff YAML gestisce i casi di indentazione in modo più pulito.
Product manager, designer e account manager a volte devono sapere cosa fa una modifica al codice senza leggere un'interfaccia Git. La PR view di GitHub presuppone familiarità con sintassi diff, alberi di file e commenti di review. Incollare il prima e dopo in una vista pulita a due pannelli, e percorrere insieme le evidenziazioni, è molto più amichevole. Utile anche nei postmortem di incidenti quando il pubblico include persone fuori dall'engineering.
Hai l'output di git show abc123 e di git show def456 per un file su due commit, magari da un log di CI o da una sandbox remota dove non puoi lanciare facilmente comandi git. Togli gli header del patch, incolla i due contenuti del file e fai diff. Funziona bene quando stai debuggando su un server, leggendo un artefatto di build o revisionando un advisory di sicurezza che cita contenuti di file da due commit specifici.
Un fornitore manda un esempio di integrazione in PDF. Un regolatore invia per email uno snippet di codice di policy. Un consulente allega una versione patchata del tuo script. Niente di tutto questo arriva come repo clonabile. Copia il testo dal PDF o dall'email, incollalo accanto alla tua versione attuale e hai una superficie di review utilizzabile in meno di un minuto. Aspettati un po' di rumore di formattazione dal copy-paste da PDF; line break e virgolette sono i soliti colpevoli.
I casi in cui un diff di testo puro non concorda con quello che Git, il tuo IDE o lo strumento di code review mostrerebbero. Vale la pena dargli un'occhiata prima di incollare codice di produzione e preoccuparsi di un falso positivo.
| Topic | What this tool does |
|---|---|
| Fine riga (CRLF vs LF) | CRLF in stile Windows e LF in stile Unix sono byte diversi. Un file incollato da un editor Windows e uno da un container Linux appariranno come diff dell'intero file se le terminazioni di riga non concordano, anche con testo visibile identico. Git normalizza con core.autocrlf; questo strumento no. |
| Spazi a fine riga | Spazi o tab a fine riga appariranno come differenza. Il core.whitespace di Git può avvisare o autocorreggere al commit; qui, ciò che incolli è ciò che confronti. Se il pavimento di rumore della tua code review è pieno di modifiche di spazi a fine riga, toglili nell'editor prima di fare diff. |
| File binari | Questo strumento è solo testo. Incollare il contenuto di un file binario (un PNG, un JAR compilato, un DB sqlite) produrrà spazzatura o bloccherà la tab. Per il diff binario, Git mostra "Binary files differ" invece di un patch; serve tooling specifico del formato per il contenuto vero. |
| Marcatura text vs binary in .gitattributes | Il .gitattributes di un repo può sovrascrivere la rilevazione testo-vs-binario di Git per pattern di file. Quel setting non viaggia con un copia-incolla. Se sospetti che un file venga trattato in modo diverso tra due checkout, quel file è il punto da guardare; questo strumento farà diff come testo puro a prescindere. |
| Diff per carattere vs per riga | Questa pagina usa diff a livello di carattere con pulizia semantica. Git va per riga di default, con git diff --word-diff opzionale per livello parola. Carattere è meglio per snippet brevi dove un singolo token è cambiato; riga è meglio per file lunghi dove molte righe sono cambiate in blocco. |
| git diff --word-diff | La modalità --word-diff di Git evidenzia modifiche a livello di parola dentro una riga, più vicina a ciò che questo strumento fa per snippet. Il formato di output è diverso (markup adatto a terminale vs pannelli affiancati), ma l'intento si sovrappone. Se vivi nel terminale, --word-diff è l'equivalente locale. |
| Soglie per file grandi | I diff nel browser sono reattivi fino a qualche migliaio di righe per lato. Oltre, la pulizia semantica diventa lenta e il DOM renderizzato diventa pesante. Per file enormi, lancia git diff localmente e mandalo in un pager, o spezza il confronto in sezioni più piccole. |
| Encoding (solo UTF-8) | Il diff assume input UTF-8, che copre quasi tutto il codice sorgente nel 2026. File salvati come UTF-16, Windows-1252 o Shift-JIS possono apparire come mojibake all'incollaggio a seconda del browser. Se uno snippet sembra mescolato, risalva il file sorgente come UTF-8 prima di copiare. |
Il git diff locale confronta due ref (commit, branch, working tree) dentro un repository reale. Conosce il tuo index, il tuo worktree e la tua history. Questo strumento online non fa nulla di tutto ciò. Confronta due blocchi di testo arbitrari che incolli. Usa git diff per il lavoro di review reale su un repo con checkout. Usa questo quando hai due snippet e nessun modo comodo di metterli in un working tree, o quando vuoi una vista affiancata senza cambiare contesto.
Non esattamente. GitHub e GitLab usano un unified diff per riga con contesto di file, header di hunk e riepiloghi per file. Questo strumento usa diff a livello di carattere con pulizia semantica, meglio per snippet brevi e peggio per file interi con molte modifiche. Per una review reale di pull request vai sulla PR view di GitHub. Per un confronto rapido di snippet fuori dalla PR, questo è più veloce e non richiede di navigare al repo giusto.
No. È un diff di testo puro. Non parsa il linguaggio, quindi non può sapere che una variabile rinominata è lo stesso identificatore in 12 posti, e non può ignorare riformattazioni di spazi come farebbe un diff sintattico. Per la maggior parte delle review di snippet va bene così, perché leggi le evidenziazioni con la tua testa. Se ti serve un diff semantico vero per il codice, il tuo IDE (VS Code, IntelliJ) o un diff basato su tree-sitter è lo strumento giusto. Questa pagina ottimizza la velocità, non il parsing profondo.
Il classico comando Unix diff -u produce un patch in formato unificato (lo stesso formato che Git usa internamente). È per riga e progettato per essere leggibile da macchina, così puoi applicare il patch altrove. Questo strumento è leggibile dall'umano. Mostra due pannelli affiancati con evidenziazione inline invece di una sola colonna di righe più e meno. Non produce un file di patch applicabile con git apply o patch -p1. Se devi generare un patch, usa la riga di comando. Se devi leggere un diff, questo è più amichevole.
Sì, ma a modo suo. Le terminazioni CRLF (Windows) e LF (Unix) appariranno come differenza se i due snippet incollati non concordano, perché tecnicamente sono byte diversi. Spazi a fine riga idem. È coerente con come Git tratta i file quando core.autocrlf è disattivato. Se ti interessano solo le modifiche di logica e non gli spazi, fai trim a ogni pannello prima di incollare. Al momento non offriamo un toggle "ignora spazi", ma è in roadmap; git diff -w è l'equivalente locale.
In pratica sì. Il diff gira nel tuo browser, quindi input molto grandi (un'intera libreria vendorizzata o un file generato da 50.000 righe) rallenteranno la pagina o bloccheranno la tab a seconda della memoria del browser. Per il lavoro di code review tipico (funzioni, file, script di build, config fino a qualche migliaio di righe per lato) il diff finisce praticamente all'istante. Se devi confrontare repository interi, uno strumento Git reale o un comparatore di cartelle è la risposta giusta; questa pagina è fatta per snippet e file singoli.
Il tuo codice non lascia mai il browser. Diff, evidenziazione e rendering girano tutti sulla tua macchina. Non carichiamo il testo, non lo logghiamo e non lo passiamo a nessun servizio terzo. Conta in particolare per la review di codice proprietario: incollare una feature non rilasciata, una patch di sicurezza o uno snippet da un repo privato in un servizio cloud può di per sé violare la policy di trattamento dei dati del tuo datore di lavoro. Verificare la cosa è semplice. Apri i DevTools del browser, vai sulla tab Network, incolla entrambe le versioni e guarda. Non ci sono richieste in uscita quando confronti. Lo stesso modello di privacy vale negli altri nostri strumenti, tra cui compare-text, compare-json e compare-yaml. La revisione del codice funziona meglio quando la superficie di review è affidabile.