Conversor YAML-JSON

Sobre o Conversor YAML-JSON

Conversor YAML-JSON é uma ferramenta online gratuita para converter entre formatos YAML (YAML Ain't Markup Language) e JSON (JavaScript Object Notation). Carregue arquivos ou cole dados, personalize opções de formatação e baixe arquivos convertidos — tudo processado localmente no seu navegador para completa privacidade.

Devo usar JSON ou YAML para meu projeto?

Use JSON para comunicação máquina-a-máquina e YAML para configuração editada por humanos. JSON é estrito, rápido de parsear e tem apenas uma grafia válida para qualquer documento, o que o torna ideal para APIs, arquivos de log e estado serializado. YAML é um superset estrito de JSON 1.2 (conforme a especificação YAML 1.2) que adiciona comentários, strings multi-linha sem escape, âncoras e aliases para evitar repetição, e uma sintaxe baseada em indentação muito mais concisa — tudo ótimo para manifestos Kubernetes, workflows GitHub Actions e playbooks Ansible onde um humano é o autor principal. Evite YAML onde segurança importe com entrada não confiável (os ataques históricos "Billion Laughs" e execução por tag vivem lá) e evite JSON onde queira comentários. O tipo de mídia oficial YAML registrado na RFC 9512 é application/yaml; JSON usa application/json da RFC 8259.

Por que meu valor YAML "1.23" vira número quando eu quero string?

Esta é a pegadinha YAML mais notória e morde todo operador Kubernetes pelo menos uma vez. YAML 1.1 auto-detecta tipos escalares a partir da sintaxe: 1.23 é float, 42 é int, true / yes / on são booleanos, null e ~ são nulls. Então um campo version: 1.10 silenciosamente perde o zero final e vira 1.1; um campo country com NO vira o booleano false; e um número de série 0123 vira o inteiro octal 83. Para forçar uma string, ou cite o valor (version: "1.10") ou use a tag de tipo explícita (version: !!str 1.10). YAML 1.2 estreita o conjunto implícito de booleanos para apenas true e false, mas a maioria dos parsers do mundo real (PyYAML, JS yaml sem opções, Kubernetes) ainda usa por padrão o comportamento 1.1. Sempre cite valores string que poderiam parecer numéricos, booleanos ou null.

Como funcionam âncoras e aliases em YAML — e JSON tem um equivalente?

Âncoras YAML (&nome) capturam um nó e aliases (*nome) o reutilizam, deixando você escrever um valor uma vez e referenciá-lo em outro lugar do mesmo documento. A chave de fusão << também permite mixar um mapping. JSON não tem equivalente — cada valor deve ser escrito por extenso — então quando este conversor vai de YAML para JSON ele tem que materializar (expandir) cada alias em uma cópia separada dos dados, o que pode explodir o tamanho de documentos que dependiam muito de aliasing. Indo no caminho contrário, de JSON para YAML, este conversor opcionalmente reintroduz âncoras para nós que aparecem identicamente várias vezes se você habilitar a opção "compactar subárvores idênticas". Âncoras também são o vetor do infame ataque YAML "Billion Laughs", então a maioria das bibliotecas YAML modernas limita profundidade de alias e tamanho de expansão por padrão.

Qual a diferença entre YAML 1.1, YAML 1.2 e YAML 1.2.2?

YAML 1.1 (2005) é a versão que a maioria dos parsers legados ainda implementa por padrão — incluindo PyYAML, snakeyaml e a stdlib do Ruby. Ela permite os booleanos yes/no/on/off/true/false em qualquer casing, aceita números octais via zero inicial (0123 = 83) e parseia notação científica agressivamente. YAML 1.2 (2009) realinhou a especificação para ser um superset estrito de JSON, estreitou booleanos para apenas true/false, removeu a regra de octal por zero inicial (use 0o123 como JSON5) e apertou muitos casos de borda. YAML 1.2.2 (2021) é uma revisão esclarecedora de 1.2 sem mudanças quebradoras — a maioria das bibliotecas YAML JavaScript é compatível com 1.2.2. Este conversor mira YAML 1.2 por padrão. Se você mantém playbooks Ansible, manifestos Kubernetes ou qualquer coisa gerada por uma ferramenta Python, espere peculiaridades 1.1 e cite escalares ambíguos defensivamente.

Posso incluir comentários ao converter YAML para JSON?

Estritamente não. A RFC 8259 proíbe comentários em JSON, e qualquer parser JSON que valha a pena os rejeitará como erro de sintaxe. Comentários YAML (# qualquer coisa) são removidos durante a conversão e desaparecem totalmente do JSON de saída. Se preservar comentários é crítico — por exemplo, você gera JSON a partir de uma config YAML editada à mão e quer que o JSON permaneça revisável — escreva os comentários em um arquivo separado, ou mude o formato de saída para JSON5 (que permite tanto // quanto /* */ comentários) ou JSONC (JSON com comentários, amplamente usado por arquivos de configuração do VS Code). Indo no caminho contrário (JSON para YAML), este conversor não tem comentários para adicionar porque a fonte não contém nenhum, mas você pode colar o YAML resultante no seu editor e adicionar comentários de documentação livremente.

Como funcionam strings multi-linha e qual estilo YAML devo escolher?

YAML oferece dois estilos de escalar de bloco para texto multi-linha. O bloco literal | preserva cada quebra de linha exatamente — escolha-o para trechos de código, arte ASCII ou qualquer coisa onde quebras de linha sejam semânticas. O bloco dobrado > colapsa cada quebra de linha individual em um espaço (tratando linhas sucessivas como um parágrafo) mas preserva separadores de linha em branco — escolha-o para prosa. Ambos os estilos suportam indicadores de chomping: |+ mantém todas as quebras finais, |- remove todas as quebras finais e | (sem indicador) mantém exatamente uma quebra final. JSON não tem sintaxe multi-linha — cada quebra de linha em um valor deve ser codificada como \n — então este conversor expande um bloco literal YAML de três linhas em uma única string JSON com dois caracteres \n. Cuide da indentação: a indentação do conteúdo do bloco é removida de cada linha, então linhas mal alinhadas produzem saída irregular.

Como faço streaming na conversão de um arquivo YAML multi-documento ou um JSON enorme?

Um arquivo YAML pode conter múltiplos documentos separados por marcadores --- (frequentemente usado em manifestos Kubernetes empacotando vários recursos). Este conversor os carrega todos e produz um array JSON de documentos na saída; o inverso converte um array JSON de volta em um stream YAML multi-documento. Para arquivos maiores do que o navegador pode segurar confortavelmente (acima de ~50 MB), use ferramentas de linha de comando: yq (jq para YAML) lida com ambas direções com yq -o=json input.yaml > out.json e yq -P input.json > out.yaml, enquanto documentos JSON grandes fazem streaming através de jq, ijson (Python) ou JSONStream (Node). O tipo de mídia oficial YAML conforme RFC 9512 é application/yaml e a sintaxe multi-documento é parte da especificação YAML 1.2, então a maioria dos parsers modernos lida com a forma streaming nativamente sem nenhuma flag especial.

O estilo flow do YAML ({key: value, list: [1, 2]}) e o estilo block são equivalentes?

Sim, semanticamente idênticos, mas estilisticamente muito diferentes. O estilo flow usa chaves e colchetes tipo JSON e cabe em uma linha — útil para objetos curtos dentro de documentos maiores. O estilo block usa apenas indentação e é a forma YAML canônica para tudo multi-linha. A maioria das ferramentas (Helm, Kustomize, Ansible, GitHub Actions) prefere estilo block para legibilidade e para manter diffs mínimos. Este conversor deixa você escolher: na saída JSON-para-YAML, escolha "preferir block" (o padrão) ou "preferir flow" ou "flow apenas para primitivos". Uma armadilha sutil: no estilo flow, strings que contêm vírgulas, dois-pontos, colchetes ou chaves devem ser citadas porque esses caracteres são estruturais; o estilo block é mais tolerante. Na dúvida, rode o YAML pelo yamllint para pegar escalares ambíguos não citados antes que mordam você em produção.