YAML in JSON

Sì, completamente. Nessuna registrazione, nessun account, nessun limite d’uso e nessun paywall. Ogni funzione di questa pagina è disponibile a tutti, sempre.

No. La conversione gira nel tuo browser con JavaScript. Il tuo YAML non viene mai trasmesso da nessuna parte — non c’è alcun endpoint di conversione lato server, nessun log e nessuna analisi del contenuto che incolli. Puoi verificarlo aprendo la scheda Rete mentre converti, o scollegandoti da internet: la pagina continua a funzionare.

No. È un convertitore da YAML a JSON online: gira nella scheda del browser che hai già aperta, senza download, senza strumenti da riga di comando e senza estensioni. Ogni convertitore online deve decidere dove avviene davvero la conversione — la maggior parte invia il tuo documento al proprio server, questo lo tiene sul tuo computer. Se preferisci uno script, la guida «Convertire YAML in JSON nel codice» copre riga di comando, Python, Node.js e Go.

Nessun tetto artificiale. La conversione avviene sul tuo computer, quindi il limite pratico è la memoria del dispositivo. File di pochi megabyte si convertono senza problemi; documenti molto grandi possono bloccare brevemente la pagina durante il parsing.

Sì. Usa il pulsante di inversione tra i due pannelli per cambiare direzione senza lasciare la pagina, oppure vai al convertitore dedicato da JSON a YAML. L’inversione riporta l’output corrente come nuovo input, così puoi fare andata e ritorno con un documento.

Vengono eliminati, perché JSON non ha una sintassi per i commenti. Il convertitore ti dice quanti ne sono stati rimossi invece di scartarli in silenzio. Se devi conservarli, usa il formatter YAML, che riformatta lo YAML sul posto e li mantiene.

I file che separano i documenti con --- sono pienamente supportati. Puoi ottenerli come array JSON contenente ogni documento, oppure come JSON Lines (NDJSON) con un oggetto JSON compatto per riga, che è il formato atteso da kubectl e dalla maggior parte delle pipeline di log. I manifest Kubernetes e l’output di Helm sono tipicamente multi-documento.

Sì. Gli anchor (&nome) e gli alias (*nome) vengono espansi nei loro valori completi, dato che JSON non può esprimere un riferimento. Le merge key (<<) vengono risolte di default, che è ciò su cui contano i file di Docker Compose, GitLab CI e Ansible. Puoi disattivare la risoluzione se preferisci vedere la chiave << grezza.

YAML 1.2 tratta i valori senza virgolette come no, yes, on e off come semplici stringhe. YAML 1.1 li tratta come booleani — quindi country: no diventa false. YAML 1.1 legge anche 022 come l’ottale 18 e 12:30 come il numero 750 in base 60. Questo convertitore usa YAML 1.2 di default e ti avvisa ogni volta che un valore del tuo documento verrebbe letto diversamente in 1.1.

Le due cause più comuni sono un carattere di tabulazione usato per l’indentazione, che YAML vieta del tutto, e un valore senza virgolette contenente due punti, come title: foo: bar. Anche parentesi e virgolette non chiuse compaiono come errori di indentazione nella maggior parte dei parser; questo convertitore le rileva in modo specifico e indica il delimitatore mai chiuso.

Sì. Se il documento non può essere analizzato ottieni una descrizione chiara del problema, riga e colonna esatte, una correzione suggerita e un marcatore sulla riga incriminata nell’editor. La pagina dedicata Validatore YAML è lo stesso motore con il pannello di output concentrato sulla diagnostica.

Una volta caricata, sì. Tutto il necessario per convertire è già nel tuo browser, quindi lo strumento continua a funzionare se perdi la connessione.

Incolla il tuo YAML nel pannello di sinistra del convertitore in cima a questa pagina — converte YAML in JSON online, nel browser, mentre scrivi, quindi non c’è alcun pulsante da premere e niente viene caricato. Imposta l’indentazione a 2 spazi, 4 spazi, tab o minificato, ordina le chiavi se vuoi, poi copia il JSON o scaricalo come file .json. Se il documento non viene analizzato ottieni riga e colonna esatte, una spiegazione chiara e una correzione suggerita anziché un pannello vuoto. Per una conversione da ripetere, yq -o=json input.yaml fa lo stesso lavoro da terminale.

Premi Carica per scegliere un file .yaml o .yml, oppure trascinalo ovunque su questa pagina, poi premi Scarica per salvare il risultato come file .json. Il file viene letto dal tuo browser e non viene mai inviato da nessuna parte, il che conta per configurazioni con nomi host, registry o credenziali. Da una shell, usa yq -o=json input.yaml > output.json, oppure converti un’intera directory con: for f in *.yaml; do yq -o=json "$f" > "${f%.yaml}.json"; done

Sì, in quasi tutti i casi. YAML 1.2 è definito come superinsieme di JSON, e qualsiasi documento YAML costruito con mapping, sequenze, stringhe, numeri, booleani e null ordinari ha un equivalente JSON esatto. Quattro cose non sopravvivono al viaggio: i commenti, perché JSON non ha una sintassi per essi; anchor e alias, che vengono espansi nei loro valori completi dato che JSON non può esprimere un riferimento; le chiavi di mapping che non sono stringhe, come date o strutture annidate, che JSON non consente; e i tag personalizzati come !Ref o !GetAtt, che non hanno significato fuori dal proprio strumento. Questo convertitore segnala ciascuno di questi casi invece di scartarli in silenzio.

È il contrario: JSON è YAML valido, ma YAML in generale non è JSON valido. La specifica YAML 1.2 definisce il linguaggio come superinsieme di JSON, quindi qualsiasi documento JSON può essere passato inalterato a un parser YAML 1.2 — puoi incollare JSON nel pannello YAML qui sopra e verrà analizzato. Un documento YAML è JSON valido solo per caso, se è scritto nello stile flow di JSON con ogni chiave e stringa tra virgolette e senza commenti; lo YAML ordinario basato sull’indentazione viene rifiutato da ogni parser JSON. La garanzia vale per YAML 1.2 — YAML 1.1, implementato da PyYAML e dagli strumenti più vecchi, non è un superinsieme stretto di JSON.

JSON è un formato di scambio rigido per le macchine; YAML è un formato di configurazione per le persone che può esprimere gli stessi dati. In concreto: YAML ricava la struttura dall’indentazione mentre JSON usa graffe e parentesi quadre; YAML supporta i commenti con # e JSON non ne ha affatto; YAML può riutilizzare blocchi tramite anchor, alias e merge key mentre JSON ripete ogni valore per intero; YAML può contenere più documenti in un file separati da ---, dove JSON contiene esattamente un valore; e YAML di solito ti permette di lasciare le stringhe senza virgolette, comodo finché country: NO non viene letto come false. Poiché YAML 1.2 è un superinsieme di JSON, tutto ciò che JSON può esprimere lo può anche YAML.

Usa YAML quando una persona scrive e mantiene il file, e JSON quando lo scrive o lo legge una macchina. YAML ripaga nella configurazione letta in code review — manifest Kubernetes, Docker Compose, workflow GitHub Actions, playbook Ansible, specifiche OpenAPI — perché i commenti spiegano i valori e gli anchor riducono le ripetizioni. JSON ripaga nei corpi di richiesta e risposta delle API, nelle righe di log, nei fixture di test e in tutto ciò che viene generato o archiviato in volume: si analizza più velocemente, ogni linguaggio ha un parser, non ci sono spazi significativi da sbagliare né ambiguità di versione su cui discutere. Quando valgono entrambi gli argomenti, la risposta consueta è scrivere in YAML e convertire in JSON in fase di build — ed è a questo che serve il convertitore in cima a questa pagina.

YAML è più facile da leggere e più difficile da scrivere correttamente; JSON è più rumoroso e molto più prevedibile. Sulla leggibilità YAML vince nettamente per la configurazione annidata: nessuna parentesi di chiusura, nessuna virgoletta attorno a ogni chiave, nessuna virgola da sbagliare, e commenti per spiegare i valori non ovvi — lo stesso manifest Kubernetes è circa il 40% più corto in YAML che in JSON. Sull’usabilità il rapporto si inverte. L’indentazione è significativa, quindi un tab vagante o una chiave sorella disallineata rompe il documento; i valori senza virgolette possono cambiare tipo in silenzio (yes, no, on, off, 022, 12:30); le chiavi duplicate e la divisione tra YAML 1.1 e 1.2 producono file che si analizzano senza errori e si comportano comunque male; e gli errori dei parser YAML sono notoriamente vaghi su dove sia il problema reale. JSON non ha nessuna di queste modalità di guasto, ed è per questo che la posizione pratica è scrivere YAML e validarlo o convertirlo prima di andare in produzione.