Convertitore da YAML a JSON

Incolla un YAML valido — un manifesto di Kubernetes, file Compose, playbook di Ansible, specifica OpenAPI o qualsiasi documento YAML 1.2 — e il convertitore restituirà l'equivalente JSON in tempo reale.

La conversione viene eseguita interamente nel tuo browser utilizzando un parser YAML 1.2, dopodiché percorre l'albero analizzato emettendo JSON tramite JSON.stringify (secondo ECMA-404 / RFC 8259).

Scegli il tuo stile di output:

• 2 spazi (predefinito, leggibile dall'utente)
• 4 spazi (alcune codebase aziendali)
• minimizzato (API, payload di rete)

L'output è pronto per essere incollato in un file `.json` o passato tramite pipe a `kubectl apply -f -` (che accetta JSON tramite stdin). Il riquadro a destra mostra il conteggio in tempo reale di byte e righe, consentendoti di verificare le dimensioni prima di procedere.

Convertire YAML in JSON richiede tre passaggi:

• Passaggio 1: Incolla il tuo YAML nell'editor. Il parser convalida mentre digiti: lo YAML non valido mostra l'esatto errore di analisi con riga e colonna.
• Passaggio 2: L'output JSON viene visualizzato in tempo reale nel riquadro di destra. Non è necessario alcun clic sui pulsanti; ogni pressione di tasto analizza nuovamente.
• Passaggio 3: Fai clic su Copia (appunti) o Scarica (file `.json`).

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

Sicurezza del round-trip: converti il JSON nuovamente in YAML con il Convertitore da JSON a YAML associato; il modello di dati viene preservato esattamente (commenti e anchor sono specifici dello YAML e non sopravvivono al round-trip).

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

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

Lo YAML supporta commenti (`#`), anchor e alias per il riutilizzo (`&name` / `*name`), flussi multi-documento (`---`) e tag di tipo espliciti (`!!str`, `!!int`) — punti di forza che lo rendono la scelta giusta per le configurazioni sottoposte a controllo versione. Il JSON viene analizzato 5-10 volte più velocemente, non presenta alcuna ambiguità ed è la scelta giusta per API e archiviazione.

Converti al confine: YAML per gli umani, JSON per le macchine.

L'annidamento profondo è il contesto in cui la conversione da YAML a JSON dà il meglio di sé: tracciare manualmente l'indentazione a 5 o più livelli è soggetto a errori. Il convertitore percorre l'albero YAML analizzato in modo ricorsivo.

• Per ogni mappa a blocchi, le chiavi vengono emesse nell'ordine di origine con la sintassi JSON `"chiave": valore`; i valori annidati ottengono le parentesi `{...}`.
• Per ogni sequenza a blocchi, gli elementi vengono emessi come array JSON `[...]`; gli oggetti annidati sotto un `-` diventano elementi di array `{...}`.

Strutture miste — sequenze di mappe, mappe contenenti sequenze di mappe, in modo ricorsivo — vengono tutte convertite 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 una prova con i tuoi dati di esempio: analizza nuovamente l'output JSON convertendolo in YAML e verifica l'uguaglianza strutturale con l'input.

La lassa inferenza dei tipi in YAML è la fonte di molti bug nelle configurazioni del mondo reale. YAML 1.2 (lo standard moderno, obiettivo di questo convertitore) ha ristretto le regole per renderlo più sicuro.

• Booleani: SOLO `true` e `false` (senza distinzione tra maiuscole e minuscole). YAML 1.1 trattava anche `yes`/`no`/`on`/`off` come booleani, il che notoriamente rompeva le configurazioni contenenti il codice paese della Norvegia `NO` (convertito silenziosamente in `false`) — il cosiddetto 'problema della Norvegia'. La maggior parte dei parser moderni (js-yaml, PyYAML 6+, Snakeyaml) adotta per impostazione predefinita il comportamento della versione 1.2.
• Null: `null`, `~` o un valore vuoto diventano tutti null in JSON.
• Numeri: i pattern di cifre che corrispondono alla sintassi di interi/float del JSON diventano numeri JSON; tutto il resto rimane una stringa.
• Stringhe: i valori tra virgolette rimangono sempre stringhe; le stringhe numeriche come i codici postali (`"01234"`) e le date del calendario richiedono le virgolette in YAML per sopravvivere alla conversione: quando una configurazione contiene una data che hai calcolato in precedenza con una calcolatrice matematica o una calcolatrice online, racchiudila tra virgolette in modo che il parser la mantenga invariata anziché convertirla forzatamente.

Il convertitore rispetta rigorosamente queste regole.

Kubernetes accetta sia YAML che JSON tramite il suo API server, kubectl e le librerie client. La maggior parte dei team mantiene il codice YAML nel controllo di versione (le PR sono più facili da revisionare) ma fornisce JSON agli strumenti programmatici — controller personalizzati, pipeline GitOps, post-renderer di Helm o webhook.

Incolla il tuo manifesto (Pod, Deployment, Service, ConfigMap, ecc.) e copia l'output JSON. Il convertitore preserva apiVersion, kind, metadata e le gerarchie di spec nell'ordine dei campi — Kubernetes si aspetta chiavi in camelCase ovunque, quindi se stai eseguendo la portabilità di campi da una sorgente in snake_case, un convertitore di maiuscole/minuscole corregge la denominazione prima di incollare.

Valida con `kubectl apply --dry-run=client -f -` (che accetta JSON su stdin) prima del commit. Per manifesti multi-risorsa separati da `---`, suddividi prima in singoli documenti — il JSON non ha una sintassi multi-documento.

Tre casi d'uso ad alto volume oltre Kubernetes:

• Docker Compose: incolla un `docker-compose.yaml` e copia il JSON per strumenti come Kompose (migra Compose a K8s), orchestratori personalizzati o trasformazioni di configurazione programmatiche.
• Ansible: converti i playbook in JSON per strumenti di documentazione, integrazioni CI personalizzate o API REST/GraphQL che memorizzano le definizioni dei playbook.
• Pipeline CI/CD: GitHub Actions (`.github/workflows/*.yml`), GitLab CI (`.gitlab-ci.yml`), CircleCI, Travis — converti uno di questi in JSON per analisi, modifiche programmatiche o archiviazione di audit log. I loro trigger `cron` schedulati sono bloccati su UTC, quindi un convertitore di fuso orario ti evita di fraintendere quando una pipeline viene effettivamente eseguita nel tuo orario locale.

Nota: le espressioni Jinja2 (`{{ var }}`), la sintassi dei template di Helm (`{{ .Values.x }}`) e il templating simile rimangono come stringhe semplici in JSON — non vengono valutati dal convertitore.

Le specifiche OpenAPI 3.x vengono comunemente scritte in YAML (più leggibili per gli alberi di percorsi/parametri) ma consumate come JSON da strumenti più vecchi — vecchie build di Swagger UI, determinati gateway API aziendali e alcuni generatori di codice.

Incolla il tuo `openapi.yaml` (o `swagger.yaml`) e scarica `openapi.json`. Il convertitore preserva esattamente i puntatori `$ref` (nessuna risoluzione), le definizioni degli schemi, gli esempi di risposta e gli schemi di sicurezza.

Dopo la conversione, valida con il validatore ufficiale OpenAPI (Spectral CLI, openapi-cli, swagger-cli) per confermare la conformità dello schema. Molti team mantengono YAML nel controllo di versione ed emettono JSON al momento della build — sia `swagger.yaml` che `swagger.json` sono perfettamente equivalenti per i consumatori di API.

Sei errori rappresentano il 95% dei problemi di analisi YAML:

• Tabulazioni ovunque nell'indentazione — YAML vieta completamente le tabulazioni, anche un solo carattere di tabulazione interrompe l'analisi.
• Indentazione incoerente — le chiavi sorelle devono allinearsi esattamente sulla stessa colonna.
• Spazio mancante dopo `:` nelle mappe — `chiave:valore` non è valido; `chiave: valore` è corretto.
• Spazio mancante dopo `-` nelle sequenze — `-elemento` è una stringa che inizia con un trattino; `- elemento` è una voce di sequenza.
• Caratteri speciali non racchiusi tra virgolette all'inizio di un valore — `@`, `` ` ``, `%`, `*`, `&` richiedono le virgolette.
• Funzionalità non supportate nel convertitore: anchor (`&name`), alias (`*name`) e flussi multi-documento (`---`) — per questi, usa una libreria YAML completa come js-yaml, PyYAML o `yq`.

Il messaggio di errore mostra la riga e la colonna in cui l'analisi è fallita.

Tre funzionalità YAML non hanno un equivalente JSON diretto e richiedono una gestione speciale:

• Anchor (`&name`) e alias (`*name`) consentono a YAML di fare riferimento a un nodo e riutilizzarlo altrove — comune nei file Compose per template di servizi condivisi e CloudFormation per parametri condivisi. Il JSON non ha alcuna sintassi di riferimento, quindi il convertitore espande gli alias in linea (ogni alias diventa una copia completa). I dati vengono preservati ma il JSON è più grande e la struttura di riferimento condiviso viene persa.
• Flussi multi-documento (separatore `---`) rappresentano più valori di primo livello in un file — comune per raggruppare risorse Kubernetes. Il JSON ha solo valori radice singoli per documento. Suddividi prima lo YAML in file separati o racchiudi i documenti in un array JSON `[doc1, doc2, doc3]`.
• I commenti (`#`) sono solo YAML — vengono completamente rimossi durante la conversione. Mantieni YAML come fonte di verità se i commenti sono importanti.

Cinque considerazioni sul ciclo di andata e ritorno che ogni sviluppatore dovrebbe conoscere:

• Modello di dati: YAML → JSON → YAML preserva esattamente chiavi, valori, tipi e annidamento. I dati sono identici in entrata e in uscita.
• Commenti: persi per sempre — il JSON non ha alcuna sintassi per i commenti. Mantieni YAML come fonte di verità se hai documentazione in linea.
• Anchor/alias: espansi sulla strada verso il JSON, mai ricreati al ritorno. Lo YAML di output ha contenuti duplicati dove la sorgente aveva riferimenti condivisi.
• Ordine delle chiavi: YAML preserva l'ordine di origine; il convertitore lo preserva fino al JSON; il ritorno a YAML mantiene lo stesso ordine.
• Tag di tipo (`!!str`, `!!int`) — emessi solo quando necessario per disambiguazione. Una stringa `"01234"` sopravvive al ciclo di andata e ritorno perché il JSON la mantiene tra virgolette; uno YAML non racchiuso tra virgolette `01234` viene analizzato come un numero intero e torna indietro come il numero 1234, perdendo lo zero iniziale.

Racchiudi i valori ambigui tra virgolette per sicurezza.

Mappatura dei tipi in sintesi:

• Mappa YAML → Oggetto JSON
• Sequenza YAML → Array JSON
• Scalare YAML (tramite inferenza del tipo) → Stringa/numero/booleano/null JSON
• Tag YAML !!str → Stringa JSON (forzata)
• YAML null/~/vuoto → Null JSON
• YAML true/false → Booleano JSON
• Pattern intero YAML → Intero JSON
• Pattern float YAML → Numero JSON

Confronto degli strumenti:

• questo convertitore (browser, istantaneo, nessuna installazione, 95% del YAML reale)
• `yq -o json` (CLI, file di grandi dimensioni, query JSONPath)
• `js-yaml`/`PyYAML` (libreria completa, anchor e multi-doc supportati, uso programmatico)

Best practice:

• Racchiudi sempre i valori ambigui (yes/no/on/off/null/ID numerici) tra virgolette nella sorgente YAML.
• Usa un'indentazione di 2 spazi (lo standard di fatto).
• Valida l'output JSON rispetto allo schema del tuo consumatore downstream (JSON Schema, OpenAPI, K8s OpenAPI) — gli errori di tipo emergono qui.
• Mantieni YAML come fonte canonica e rigenera il JSON al momento della build quando possibile.