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, âncoras não são reintroduzidas — subárvores repetidas são escritas por extenso, já que o JSON não tinha aliases para começar. Â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 converto um arquivo YAML multidocumento (manifestos Kubernetes empacotados)?

Um arquivo YAML pode conter múltiplos documentos separados por marcadores --- (a forma padrão de manifestos Kubernetes, saída do Helm e Ansible que empacotam vários recursos em um arquivo). Este conversor detecta automaticamente os separadores --- e, ao ir de YAML para JSON, produz um array JSON de documentos (um elemento por recurso). No caminho contrário, habilite a caixa Multidocumento (---) e passe um array JSON; cada elemento vira seu próprio documento YAML unido por --- para que o stream reimporte de forma limpa com kubectl apply -f. Marque a caixa explicitamente para forçar a saída em array mesmo com um único 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. O tipo de mídia oficial YAML conforme RFC 9512 é application/yaml e a sintaxe multidocumento é parte da especificação YAML 1.2, então a maioria dos parsers modernos lida com a forma streaming nativamente.

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 usa estilo block por padrão na saída JSON-para-YAML; marque a opção "Formato inline" para forçar o documento inteiro ao estilo flow compacto. 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.