Convertitore da JSON a YAML

Incolla un JSON valido — un oggetto, un array, uno scalare, una risposta API o un manifesto Kubernetes completo — e il convertitore emetterà l'equivalente YAML in tempo reale.

La conversione viene eseguita interamente nel tuo browser utilizzando il comando nativo JSON.parse per la validazione dell'input (secondo ECMA-404 / RFC 8259), per poi attraversare l'albero analizzato emettendo la sintassi YAML 1.2.2.

Il rientro a 2 spazi è l'impostazione predefinita — lo standard di fatto in Kubernetes, Ansible, GitHub Actions e Docker Compose. Passa al rientro a 4 spazi se la tua base di codice lo richiede.

L'output è pronto per essere incollato in un file `.yaml` o inviato tramite pipe a `kubectl apply -f -`. Il riquadro di destra mostra il conteggio in tempo reale di byte e righe per consentirti di verificare le dimensioni prima del commit.

Converti in tre passaggi:

• Passaggio 1: Incolla il tuo JSON nell'editor. Il convertitore convalida mentre digiti — un JSON non valido mostra l'errore esatto del parser con riga e colonna.
• Passaggio 2: L'output YAML appare in tempo reale nel riquadro di destra. Non è necessario alcun clic su un pulsante; ogni pressione di tasto viene rielaborata.
• Passaggio 3: Fai clic su Copia (appunti) o Scarica (file `.yaml`).

Per flussi di lavoro programmatici, la stessa logica è esposta tramite l'endpoint `/api/calculate` — invia un POST con JSON e ricevi lo YAML nel corpo della risposta.

Sicurezza di andata e ritorno (round-trip): riconverti lo YAML in JSON con il convertitore gemello da YAML a JSON; il modello dati viene preservato esattamente (commenti e ancore sono esclusivi dello YAML e non sopravvivono alla conversione).

JSON e YAML rappresentano lo stesso modello di dati — mappe (oggetti), sequenze (array) e scalari (stringa/numero/booleano/null) — ma con una sintassi superficiale molto diversa.

Il JSON fa largo uso di parentesi graffe e virgolette: ogni chiave ha `"`, ogni mappa ha `{}`, ogni array ha `[]` e ogni separatore è esplicito (`:` e `,`). Lo YAML è basato sul rientro: l'annidamento è implicito dal rientro di 2 spazi, le sequenze usano il prefisso `- ` e la maggior parte delle stringhe non richiede virgolette.

Il JSON viene analizzato da 5 a 10 volte più velocemente in tutti i principali runtime di linguaggio, non presenta alcuna ambiguità ed è la scelta giusta per API, code di messaggi, flussi di log e formati di archiviazione.

Lo YAML supporta i commenti (`#`), ancore e alias per il riutilizzo (`&name` / `*name`), flussi multi-documento (`---`) ed etichette di tipo esplicite (`!!str`, `!!int`) — punti di forza che lo rendono la scelta ideale per configurazioni controllate da sorgente, pipeline CI/CD, infrastruttura come codice e manifesti Kubernetes.

Scegli JSON per le macchine, YAML per gli esseri umani ed effettua la conversione tra di essi al confine.

L'annidamento profondo è il motivo principale per cui la conversione da JSON a YAML si rivela utile: tracciare manualmente parentesi graffe e rientri a partire da 5 o più livelli è soggetto a errori.

Il convertitore attraversa l'albero JSON analizzato in modo ricorsivo:

• Per ciascuna mappa (oggetto), le chiavi vengono emesse nell'ordine di origine con la sintassi `chiave: valore`; i valori annidati sono rientrati di altri 2 spazi.
• Per ciascuna sequenza (array), gli elementi utilizzano il prefisso `- `; gli oggetti annidati sotto un `-` iniziano sulla stessa linea del trattino ereditando il livello di rientro successivo.

Strutture miste — array di oggetti, oggetti contenenti array di oggetti, in modo ricorsivo — vengono tutte renderizzate correttamente. La profondità massima è limitata solo dallo stack di chiamate del tuo browser (~10.000+ frame nei browser moderni, ben oltre qualsiasi configurazione realistica).

Fai un test con i tuoi dati di prova: analizza l'output YAML riconvertendolo in JSON e verifica l'uguaglianza strutturale con l'input.

I manifesti Kubernetes sono il caso d'uso più comune per questo convertitore. Molti strumenti (kubectl, Lens, k9s, Helm) emettono JSON tramite i flag `-o json`; il formato canonico di riferimento sottoposto a Git è lo YAML.

incolla l'output JSON di `kubectl get deployment -o json` e il convertitore produrrà un manifesto pulito pronto per il commit. Le gerarchie apiVersion, kind, metadata e spec preservano l'ordinamento esatto dei campi.

Per i valori dei chart Helm, incolla i tuoi valori JSON e inserisci lo YAML in `values.yaml` — i template di Helm li recepiranno senza modifiche. Per le sovrapposizioni Kustomize, converti il tuo oggetto patch e aggiungilo all'elenco `patchesStrategicMerge`.

Valida l'output con `kubectl apply --dry-run=client -f file.yaml` prima di effettuare il commit: individuerà problemi a livello di schema che la sola validazione della sintassi YAML non riuscirebbe a cogliere.

I file Docker Compose sono codice YAML puro conforme alle specifiche Compose (compose-spec.io). Quando disponi di un output JSON programmatico — proveniente da un generatore di configurazioni, da una precedente esportazione Compose v2 o da uno script di creazione di modelli — convertilo qui e incollalo in `docker-compose.yaml`.

Le chiavi di primo livello (`services`, `networks`, `volumes`, `configs`, `secrets`) e le relative specifiche annidate (image, ports, environment, depends_on, healthcheck) si convertono tutte correttamente.

Fai attenzione alle porte: le stringhe abbreviate come `"8080:80"` devono rimanere racchiuse tra virgolette in YAML per evitare l'interpretazione come numero sessagesimale; il convertitore gestisce questa operazione automaticamente.

Esegui la convalida con `docker compose config` prima di `docker compose up`; il comando analizza, unisce più file e stampa la configurazione risolta esattamente come verrà eseguita dal motore.

Le regole di indentazione di YAML sono rigorose: 2 spazi per livello (sono validi anche 4, ma rari), le tabulazioni sono vietate e le chiavi allo stesso livello devono allinearsi perfettamente. Le sequenze (`- item`) e le mappe (`key: value`) possono annidarsi liberamente.

Le stringhe multilinea sono di due tipi: i blocchi letterali (`|`) mantengono ogni interruzione di linea; i blocchi a capo (`>`) uniscono le linee con spazi (stile paragrafo).

Le ancore (`&name`) e gli alias (`*name`) consentono di definire un nodo YAML una sola volta e di riutilizzarlo altrove, una pratica comune nei file Compose per i modelli di servizio condivisi.

I tag di tipo esplicito (`!!str`, `!!int`, `!!bool`, `!!null`) sovrascrivono la tipizzazione automatica di YAML quando ti serve una stringa che sembra un numero, o viceversa.

Il convertitore racchiude automaticamente tra virgolette le stringhe ambigue: `"yes"`, `"no"`, `"null"`, `"~"`, valori dall'aspetto numerico come `"01234"` e qualsiasi stringa contenente caratteri speciali YAML (`:`, `#`, `-`, `&`, `*`, `!`, `|`, `>`, `'`, `"`, `%`, `@`).

Sei errori sono responsabili del 95% dei file YAML danneggiati in circolazione.

• (1) Presenza di tabulazioni — anche un solo carattere di tabulazione interrompe l'analisi. Configura il tuo editor affinché inserisca spazi.
• (2) Indentazione incoerente — una chiave di pari livello fuori di una colonna genera un errore di analisi.
• (3) Spazio mancante dopo `:` — `key:value` non è valido; `key: value` è corretto.
• (4) Stringhe senza virgolette che sembrano booleani (`yes`, `no`, `on`, `off`) — vengono convertite in true/false in YAML 1.1 (parser meno recenti). YAML 1.2 ha limitato i booleani ai soli `true`/`false`, ma è comunque saggio usare le virgolette per sicurezza.
• (5) Stringhe numeriche senza virgolette — `01234` diventa il numero intero 1234, perdendo lo zero iniziale.
• (6) Spazio mancante dopo `-` — `-item` è una stringa che inizia con un trattino; `- item` è un elemento di una sequenza.

Effettua la convalida con `yamllint`, l'estensione YAML in VS Code o validator specifici per dominio (`kubectl --dry-run`, `docker compose config`, `ansible-playbook --syntax-check`).

I flussi di lavoro delle API traggono vantaggio dalla conversione da JSON a YAML in due punti.

Innanzitutto, le specifiche OpenAPI 3.x vengono solitamente scritte in YAML (più leggibili per gli alberi di percorsi e parametri) ma esportate come JSON per gli strumenti di sviluppo; converti nell'una o nell'altra direzione a seconda delle esigenze di modifica. Il convertitore preserva i campi obbligatori, le definizioni degli schemi, i puntatori $ref e i corpi di esempio.

In secondo luogo, quando documenti un'API, incolla un JSON di esempio e presenta la versione YAML nella tua documentazione: risulterà più facile per i lettori esaminare corpi di risposta profondamente annidati.

Per l'integrazione con Swagger UI, sono accettati sia `swagger.yaml` che `swagger.json`; molti team mantengono il file YAML nel controllo di versione ed emettono il JSON in fase di compilazione. La sicurezza del ciclo di andata e ritorno è garantita per le specifiche OpenAPI poiché non utilizzano commenti o ancore nella forma canonica.

Quasi tutte le piattaforme CI/CD moderne utilizzano YAML per definire le pipeline:

• GitHub Actions (`.github/workflows/*.yaml`)
• GitLab CI (`.gitlab-ci.yml`)
• CircleCI (`.circleci/config.yml`)
• Travis (`.travis.yml`)
• Drone
• Concourse
• Argo Workflows
• Tekton

Quando disponi di una configurazione JSON — proveniente da un generatore, da una precedente esportazione del controllo di versione o da un generatore programmatico — incollala qui ed emetti il formato YAML.

I playbook di Ansible in particolare si affidano pesantemente alla struttura a elenco di attività di YAML con ancore per blocchi riutilizzati; il convertitore restituisce le sequenze in modo pulito così puoi incollarle sotto `tasks:` senza ulteriori modifiche.

Per le GitHub Actions, la parte più complessa riguarda le condizioni `if:` e le strategie di matrice: mantieni il codice YAML convertito, quindi aggiungi commenti che ne spieghino l'intento (una funzionalità disponibile solo in YAML che andrebbe persa tornando a JSON).

Cinque casi limite mandano in crisi i convertitori naif.

• (1) Commenti: JSON non ne ha alcuno, YAML supporta `#`. Il ciclo andata e ritorno JSON → YAML → JSON non prevede perdite, ma YAML → JSON → YAML elimina ogni commento. Mantieni YAML come tua fonte di verità quando i commenti sono importanti.
• (2) Coercizione booleana: i parser legacy di YAML 1.1 trattano `yes`/`no`/`on`/`off` come booleani. I parser moderni (1.2.2) trattano in questo modo solo `true`/`false`, ma l'uso difensivo delle virgolette previene sorprese.
• (3) Null: il valore `null` di JSON viene associato a `null`, `~` o a un valore vuoto in YAML. Il convertitore emette `null` per maggiore chiarezza; alcuni strumenti preferiscono il formato vuoto (`key:`) ma questo può generare ambiguità con le stringhe vuote.
• (4) Stringhe numeriche: `"01234"` (un codice postale statunitense) perde lo zero iniziale se non racchiuso tra virgolette in YAML; il convertitore provvede a inserire le virgolette.
• (5) Numeri decimali con zeri finali: `1.50` convertito e riconvertito diventa `1.5` perché sia JSON che YAML utilizzano una rappresentazione numerica canonica. Se gli zeri finali sono importanti (valute, stringhe di versione), effettua la serializzazione come stringhe.

Mappatura dei tipi in sintesi:

• Oggetto JSON → Mappa YAML (stile a blocchi)
• Array JSON → Sequenza YAML (elementi con `-`)
• Stringa JSON → Stringa YAML (con virgolette automatiche se ambigua)
• Numero JSON → Scalare YAML con lo stesso valore numerico
• True/false JSON → True/false YAML
• Null JSON → Null YAML

Scelte di stile:

• preferisci lo stile a blocchi (multilinea, indentato) per la leggibilità rispetto allo stile in linea (`{key: value, ...}` compatto simile a JSON)
• usa sempre un'indentazione di 2 spazi
• emetti le chiavi nell'ordine di origine (rispecchia il comportamento di JSON)

Consigli per il ciclo completo:

• (1) JSON → YAML → JSON non comporta perdite di dati.
• (2) YAML → JSON rimuove commenti, ancore (espanse), tag espliciti e flussi a documenti multipli.
• (3) Racchiudi sempre tra virgolette le stringhe che sembrano booleani, valori nulli o numeri.
• (4) Testa l'output con lo strumento effettivo che lo utilizzerà (kubectl, docker compose, ansible-playbook); questi presentano convalide più rigorose rispetto ai parser YAML generici.
• (5) Mantieni entrambe le versioni nel controllo di versione se il tuo team utilizza entrambi i formati; considerane uno come canonico (solitamente YAML per le configurazioni, JSON per le API) e rigenera l'altro durante la compilazione.