Incolla due documenti YAML e ottieni un diff preciso affiancato. Pensato per manifest Kubernetes, workflow di GitHub Actions, values di Helm e file docker-compose.
Uno strumento gratuito nel browser per confrontare due documenti YAML. Incolla la versione vecchia a sinistra, quella nuova a destra, e le differenze vengono evidenziate carattere per carattere. Il testo non lascia il tuo browser, una cosa che conta quando stai diffando manifest che contengono riferimenti a secret o hostname interni.
Il diff lavora a livello di carattere, lo stesso motore che usa il nostro strumento di diff testuale. La modalità YAML dell'editor gestisce l'evidenziazione di sintassi secondo la specifica YAML 1.2.2, così block scalars, anchors e flow collections appaiono con i colori giusti.
Se hai mai fissato un diff di 400 righe di un values.yaml di Helm in una pull request cercando l'errore di indentazione che ha rotto il chart, questo è lo strumento che lo trova in pochi secondi. È utile anche quando il copia-incolla tra Slack e l'editor trasforma gli spazi in tab, cosa che YAML rifiuta categoricamente.
Il diff lavora a livello di carattere, poi una passata di pulizia semantica raggruppa le evidenziazioni in blocchi sensati invece che in caratteri singoli sparsi. Le inserzioni appaiono in verde nel pannello di destra, le rimozioni in rosso a sinistra, e i conteggi nelle intestazioni dicono quante modifiche distinte ha trovato il diff.
YAML ha regole di parsing che mordono chi lo tratta come un formato indulgente. L'indentazione è strutturale secondo la spec YAML 1.2.2, quindi un singolo spazio fuori posto cambia l'albero del documento. I tab sono vietati come indentazione, e il parser li rifiuta senza appello. Il typing implicito trasforma il token senza virgolette NO nel booleano false in YAML 1.1, il famoso Norway problem: le liste di codici nazione perdono la Norvegia in silenzio. YAML 1.2 ha stretto le regole, così solo true, false, null e le forme numeriche si convertono senza virgolette, ma molti tool continuano a parsare in 1.1.
Se hai già convertito il tuo YAML in JSON per un consumer a valle, il nostro strumento di diff JSON si occupa delle questioni strutturali come ordine delle chiavi e canonicalizzazione. JSON è un sottoinsieme stretto di YAML 1.2, quindi ogni documento JSON valido è anche YAML valido: questa compatibilità è documentata nella spec ed è il motivo per cui js-yaml e libyaml riescono a fare round-trip di JSON senza sorprese.
Due pannelli di testo, un diff. Niente registrazione, niente upload, niente roundtrip al server.
Incolla il vecchio YAML a sinistra, il nuovo a destra. Oppure clicca Carica da uno dei due lati per aprire direttamente un file .yaml o .yml. Il pulsante Esempio riempie entrambi i pannelli con un piccolo Deployment Kubernetes per vedere lo strumento in azione prima.
YAML usa solo spazi per l'indentazione, mai tab. Se hai incollato da un client di chat o da un terminale che ha convertito gli spazi in tab, il parser rifiuta il file. L'editor evidenzia tab e spazi a fine riga per individuarli prima che facciano fallire un deploy.
Le rimozioni appaiono in rosso a sinistra, le inserzioni in verde a destra. I due pannelli scorrono insieme così segui manifest lunghi senza perdere il segno. I conteggi delle modifiche nelle intestazioni riassumono quante edit distinte ha trovato il diff.
Esegui kubectl get deployment web -o yaml in entrambi i cluster e fai il diff dell'output. Spesso la prod ha ancora replicas: 2 e una image tag vecchia perché un rollout di fine sprint non è mai arrivato, e un diff testuale è il modo più rapido per confermarlo prima di rilanciare kubectl apply. Il modello a oggetti di Kubernetes è YAML dall'inizio alla fine, quindi questo è il caso di tutti i giorni.
Quando un workflow non si attiva più dopo aver rinominato un branch o un job impiega all'improvviso 8 minuti in più, fai il diff di .github/workflows/ci.yml rispetto all'ultimo commit verde. Il colpevole è di solito un filtro on: cambiato, una chiave cache: rimossa in actions/setup-node, o una entry della matrix passata in silenzio da node-version: "18" (string) a node-version: 18 (numero) e che ha fatto inciampare il type checker.
Fai il diff di docker-compose.yml rispetto alla versione in main per verificare quali entry environment: hai davvero cambiato. Si incolla una lista di nuove env var e si dimentica che una era già impostata sotto un altro service, così l'override fa cambiare in silenzio una flag altrove. Il diff lo rende ovvio.
Quando aggiorni un chart da 1.8.0 a 2.0.0, fai il diff del tuo values.yaml rispetto ai nuovi default pubblicati dal maintainer. Helm fa merge dei valori chiave per chiave, quindi una chiave di primo livello rinominata (image.tag spostata sotto image.repository) ricade silenziosamente sul default del chart. Il diff fa emergere il rename prima che helm upgrade rilasci una regressione.
Un diff di un openapi.yaml da 3.000 righe è illeggibile quando un code generator riordina alfabeticamente i paths. Confronta le versioni affiancate e la modifica vera salta fuori: un campo required aggiunto a uno schema di richiesta, o una response il cui tipo è passato silenziosamente da string a integer. Più facile che scavare in un SDK generato per capire perché si è rotta la build.
Quando un playbook funziona in dev e fallisce in prod, fai il diff dell'inventory o del defaults/main.yml della role tra i due. Causa comune: una hostvar mai copiata, oppure un become: yes messo sulla role in dev ma su una singola task in prod. Il diff lo trova in pochi secondi.
Un breve memo per i casi limite di parsing che questo strumento fa emergere più spesso. Tutto basato sulla specifica YAML e sul comportamento reale dei parser.
| Topic | What this tool does |
|---|---|
| Indentazione | Solo spazi, e il conteggio è strutturale. Due e quattro spazi sono entrambi comuni; scegline uno per file e tienitelo. La pagina YAML su Wikipedia ha un buon riassunto se vuoi la storia. |
| Tab | Vietati come indentazione dalla spec. Permessi dentro valori scalari. Se il tuo editor inserisce un tab a Invio, configuralo per usare gli spazi sui file .yaml e .yml. |
| Anchors e aliases | &name definisce un anchor; *name lo referenzia. Utile per ripetere blocchi grandi come le env var di un container o la config di default di un service senza copia-incolla. |
| Merge keys | <<: *base fa merge del mapping referenziato in quello corrente. Funzionalità di YAML 1.1. La maggior parte dei parser, inclusa libyaml, la accetta ancora; la spec YAML 1.2 l'ha tolta. |
| File multi-document | Tre trattini (---) separano i documenti in un singolo stream. Utile per passare più oggetti Kubernetes attraverso un solo kubectl apply -f. ... termina un documento. |
| Block scalars | | conserva i ritorni a capo (literal); > li piega in spazi. I modificatori - e + controllano i ritorni a capo finali. Usa | per gli script shell, > per la prosa lunga. |
| Norway problem | Senza virgolette, NO, YES, ON, OFF diventano booleani in YAML 1.1. Mettili tra virgolette o usa un parser 1.2. Vedi le definizioni dei tipi YAML per quali stringhe vengono convertite. |
| Codifica | La spec YAML 1.2 richiede UTF-8. UTF-16 è permesso con BOM. In pratica i tool si aspettano UTF-8 senza BOM, quindi salva i file così per evitare sorprese. |
YAML è whitespace-sensitive, quindi un diff di testo normale è già utile: ogni cambio di indentazione è un cambio strutturale, e il diff lo prende. La differenza è nella presentazione. La modalità YAML colora anchors, tags, block scalars e flow collections con i colori della sintassi, così a colpo d'occhio capisci se la modifica è su una chiave, su un valore stringa o su un elemento di lista. L'algoritmo di diff sotto è lo stesso del nostro strumento di diff testuale.
Perché l'indentazione è l'unica cosa che dice al parser quali chiavi appartengono a quale mapping. La spec YAML 1.2.2 definisce il livello di indentazione di un nodo dal numero di spazi iniziali e vieta i tab come indentazione. Un singolo spazio in più promuove una chiave in un sub-mapping. Quel rigore è il prezzo di un formato che non ha bisogno di parentesi graffe e virgole, ed è il motivo per cui i bug di indentazione si vedono più spesso in YAML che in JSON.
Il typing implicito di YAML 1.1 trasforma il token senza virgolette NO nel booleano false. Quindi una lista di codici nazione che include NO per la Norvegia diventa silenziosamente una lista con una entry sostituita da false. Lo stesso vale per YES, ON, OFF e simili. StrictYAML lo documenta in dettaglio. La soluzione è mettere il valore tra virgolette ("NO") o usare un parser che segue YAML 1.2, che converte implicitamente solo true, false e null.
Un anchor (&name) marca un nodo per poterlo poi referenziare con un alias (*name), evitando ripetizioni in file lunghi. La merge key (<<: *name) era un'estensione di YAML 1.1 che copia tutte le chiavi del mapping referenziato in quello corrente, utile per condividere configurazione comune tra service. Le merge key non fanno parte di YAML 1.2, ma la maggior parte dei parser, incluso js-yaml, le accetta ancora per compatibilità. Il diff tratta anchors e aliases come testo semplice, quindi un anchor rinominato si vede pulito.
Sì. JSON è un sottoinsieme stretto di YAML 1.2, quindi ogni documento JSON valido è anche un documento YAML valido. Puoi mescolarli se vuoi, mettendo una flow collection in stile JSON dentro un file in stile blocco. Per il lavoro su JSON puro, il nostro strumento di diff JSON ha pulsanti formatta e valida specifici per JSON, inclusi pretty-print e ordina chiavi.
Perché la spec YAML vieta i tab come indentazione. Citando la spec 1.2.2: "To maintain portability, tab characters must not be used in indentation." I tab sono permessi dentro valori scalari (una stringa può contenere un tab), solo non a inizio riga, dove l'indentazione viene misurata. La soluzione è un trova-e-sostituisci rapido da tab a due o quattro spazi, secondo la convenzione che il tuo file usa già.
Il tuo YAML non lascia il browser. Editor, evidenziatore di sintassi e diff girano tutti sulla tua macchina, in locale. Niente analytics sul tuo input, niente log, niente roundtrip in cloud. Il formato che seguiamo è la specifica YAML 1.2.2. Per verificare che non venga caricato nulla, apri le DevTools e tieni d'occhio la scheda Network mentre confronti.