JSON para YAML

Como funciona

1. Cole JSON : insira qualquer JSON válido, de pares chave-valor planos a objetos e arrays profundamente aninhados.
2. Conversão instantânea : a ferramenta transforma o JSON em YAML com a indentação correta, remove as aspas das chaves de string e traduz os tipos null, booleano e numérico.
3. Configure a saída : defina a largura da indentação (2 ou 4 espaços) e escolha entre o estilo bloco ou fluxo para as coleções.
4. Copie o YAML : o resultado está pronto para colar em arquivos de configuração, pipelines CI/CD ou manifestos Kubernetes.

Por que converter JSON em YAML ?

O YAML é o formato de configuração preferido para ferramentas de infraestrutura como Kubernetes, Docker Compose, GitHub Actions, Ansible e charts Helm, mais legível que o JSON, suporta comentários e não exige aspas ao redor de cada string. Converter respostas de API, seções de package.json ou estruturas de dados de JSON para YAML é uma tarefa frequente em DevOps e desenvolvimento back-end. A estrutura baseada em indentação do YAML é mais legível para humanos, enquanto o JSON é preferido para APIs e geração programática, este conversor faz a ponte entre os dois.

Correspondência dos tipos

• Strings → sem aspas se possível, entre aspas se contêm caracteres especiais
• Números → escalares numéricos YAML como estão
• Booleanos → true / false em YAML
• null → null ou ~ em YAML
• Arrays → sequências em bloco YAML com prefixo -
• Objetos → mapeamentos YAML com pares chave : valor

O que é conversão JSON para YAML?

A conversão JSON para YAML traduz uma árvore de pares chave-valor de um formato de serialização para outro enquanto preserva os dados subjacentes. Ambos formatos descrevem a mesma forma de dados (strings, números, booleanos, null, arrays, objetos), mas JSON usa chaves e colchetes enquanto YAML usa recuo e travessões. A mesma configuração 'name: app, version: 1, ports: 80, 443' pode ser expressa em qualquer um, e os conversores se movem entre eles sem perder significado.

JSON, inventado por Douglas Crockford por volta de 2001 e padronizado como RFC 4627 em 2006 e ECMA-404 em 2013, é a língua franca das APIs web. YAML 1.0 (2001), 1.1 (2005) e 1.2 (2009) por Clark Evans, Ingy doet Net e Oren Ben-Kiki foi projetado como um superconjunto de JSON otimizado para legibilidade humana, com suporte para comentários, strings multilinha, âncoras e aliases. Ferramentas DevOps modernas (Kubernetes, Docker Compose, GitHub Actions, Ansible, Helm) adotaram YAML por padrão porque configs são escritas e revisadas por humanos.

Este conversor emparelha ambos os formatos lado a lado. Cole JSON à esquerda, clique em JSON para YAML, e o painel direito atualiza com YAML válido na profundidade de recuo escolhida (2 ou 4 espaços). O botão reverso executa o mesmo processo ao contrário. A conversão usa a biblioteca js-yaml (Vitaly Puzrin, 2011) carregada do jsDelivr, que implementa a especificação YAML 1.2 com precisão suficiente para fazer ida e volta de manifestos Kubernetes, charts Helm e especificações OpenAPI.

O que há dentro do conversor

A interface usa um layout de grade de dois painéis: JSON à esquerda, YAML à direita. Em telas mais estreitas que 768 pixels, o layout empilha verticalmente. Acima dos painéis, um seletor de recuo permite escolher 2 ou 4 espaços por nível. A escolha ativa é destacada, e o recuo se aplica a ambas as direções de conversão.

Cada painel tem seus próprios botões de ação. O painel JSON oferece JSON para YAML (converter) e Limpar. O painel YAML oferece YAML para JSON (reverso), Copiar (área de transferência) e Baixar .yaml (salvar como arquivo com extensão .yaml e codificação UTF-8). O banner de erro abaixo do conversor exibe erros de análise com o número da linha e uma mensagem curta, para que você possa corrigir entrada inválida sem sair da ferramenta.

Sob o capô, a conversão JSON para YAML usa JSON.parse mais a função dump do js-yaml. A direção YAML para JSON usa a função load do js-yaml mais JSON.stringify com recuo de 2 espaços. Ambas as direções são funções puras da entrada, nenhum estado é mantido entre conversões, e atualizar a página reinicia tudo.

História e contexto

Douglas Crockford especifica JSON (2001)

Douglas Crockford documentou a sintaxe JSON em abril de 2001 enquanto estava na State Software, depois de perceber que a sintaxe literal de objeto do JavaScript poderia servir como um formato de dados independente de linguagem. A especificação era deliberadamente mínima: seis tipos, duas coleções, sem comentários, sem schema. RFC 4627 seguiu em 2006 e ECMA-404 em 2013. O minimalismo é exatamente o que tornou JSON onipresente na web.

YAML 1.0 publicado (2001)

Clark Evans, Ingy doet Net e Oren Ben-Kiki lançaram YAML 1.0 em maio de 2001, no mesmo ano que o JSON. O acrônimo era originalmente Yet Another Markup Language mas foi retconado para YAML Ain't Markup Language para esclarecer que YAML mira dados de configuração, não marcação de documento. A especificação 1.0 era ambiciosa, suportando âncoras, aliases, streams multi-documento, tags personalizadas e comentários.

YAML 1.1 e o problema da Noruega (2005)

YAML 1.1 (janeiro de 2005) apertou a especificação mas manteve o famoso comportamento de coerção booleana onde as strings yes, no, on, off, y, n, true, false, mais suas variantes em maiúsculas, todas se tornam booleanos. Este é o Problema da Noruega: o código de país ISO sem aspas NO se torna o booleano false. O bug afetou os primeiros usuários do Kubernetes até que o YAML 1.2 (2009) removeu as ortografias booleanas alternativas.

YAML 1.2 declara JSON como subconjunto (2009)

YAML 1.2 (outubro de 2009) explicitamente fez do JSON um subconjunto estrito de YAML, então qualquer documento JSON válido também é um documento YAML válido. Esta foi uma grande vitória de design: ferramentas que lidavam com YAML 1.2 podiam analisar JSON de graça, simplificando a implementação de conversores e validadores. A versão ainda em uso na maioria das ferramentas hoje é 1.2 ou um perfil compatível com 1.1.

Kubernetes lança manifestos YAML (2015)

Kubernetes 1.0, lançado pela Google em julho de 2015, definiu recursos de cluster (Pods, Deployments, Services) usando manifestos YAML. A escolha foi impulsionada pela legibilidade para equipes de operações acostumadas a editores de texto e controle de versão. Helm (2016) adicionou templating em cima, GitHub Actions (2018) adotou YAML para workflows, e playbooks Ansible (2012 a 2018) cimentaram YAML como a linguagem de configuração DevOps dominante.

js-yaml se torna a biblioteca JavaScript de facto (a partir de 2011)

Vitaly Puzrin publicou js-yaml em 2011 como uma porta JavaScript pura do PyYAML. Versões subsequentes (2.0 em 2014, 3.0 em 2015, 4.0 em 2021) rastrearam a especificação YAML 1.2, adicionaram schemas para optar por não usar recursos perigosos, e alcançaram mais de 50 milhões de downloads npm semanais. A biblioteca é empacotada por webpack, parcel e esbuild para qualquer trabalho YAML do lado do navegador, e é o que este conversor usa por baixo.

Fluxos de trabalho práticos

Autorando manifestos Kubernetes

Quando você gera um Pod ou Deployment via kubectl run --dry-run=client -o json, você recebe JSON. Cole-o aqui, clique em JSON para YAML, e você tem um manifesto pronto para commitar no git. A conversão preserva specs aninhadas, variáveis de ambiente e limites de recursos exatamente como o Kubernetes irá lê-los.

Definições de serviço Docker Compose

Um colega de equipe lhe envia um snippet JSON para um novo serviço. Cole, converta e jogue o YAML em seu docker-compose.yml. O recuo de 2 espaços é o padrão do Compose, então deixe a opção de recuo em 2.

Workflows GitHub Actions

Quando você esboça um workflow a partir de um gerador de template baseado em JSON ou copia uma etapa de uma resposta de API JSON, cole-o aqui e converta. A saída cai diretamente em .github/workflows/*.yml. Atente que o GitHub Actions também aceita JSON em alguns campos, mas YAML é a forma canônica.

Playbooks Ansible

Inventários Ansible frequentemente começam a vida como JSON exportado de um CMDB ou banco de dados de ativos. Cole, converta para YAML, e você tem um arquivo hosts ou cabeçalho de playbook que se encaixa no estilo esperado pelo Ansible. Use recuo de 2 espaços para combinar com o guia de estilo da comunidade Ansible.

Valores de chart Helm

Um fornecedor envia configurações de amostra JSON para seu chart Helm. Converta para YAML e jogue em values.yaml. A conversão respeita chaves aninhadas (image.repository, image.tag, resources.limits.memory) exatamente como o Helm as espera.

Especificações OpenAPI 3

Swagger Editor exporta especificações OpenAPI tanto em JSON quanto em YAML. Quando uma ferramenta emite JSON mas sua equipe usa YAML no controle de versão (ou vice-versa), este conversor é a forma mais rápida de trocar formatos sem disparar Node, Python ou yq.

Armadilhas comuns

O problema da Noruega (yes, no, on, off como booleanos)

Em YAML 1.1, as strings yes, no, on, off, y, n, true, false (e suas variantes em maiúsculas) são todas booleanos. Então o código de país ISO sem aspas NO se torna o booleano false. js-yaml 4.x usa por padrão YAML 1.2 que apenas trata true e false como booleanos, mas analisadores YAML mais antigos ainda podem tropeçar. Cite explicitamente strings ambíguas se você misturar versões de ferramentas.

Tabs não são recuo YAML válido

YAML usa espaços, não tabs, para recuo. Se seu editor insere tabs por padrão, o YAML convertido falhará no parse no Kubernetes, Helm ou qualquer carregador YAML rigoroso. Configure seu editor para usar 2 ou 4 espaços para arquivos .yaml e .yml, ou execute um linter (yamllint) antes de commitar.

Âncoras e aliases não sobrevivem à conversão JSON

YAML suporta âncoras (&name) e aliases (*name) para reutilizar valores. Quando você converte YAML para JSON, as âncoras são expandidas inline porque JSON não tem recurso equivalente. A conversão reversa JSON para YAML não reintroduzirá âncoras automaticamente. Se precisar de âncoras, escreva-as à mão após a conversão.

Strings multilinha precisam de indicadores explícitos

Uma string JSON com newlines embutidos (Hello\nWorld) converte para YAML usando o escalar de bloco literal (|) ou o escalar de bloco dobrado (>). js-yaml escolhe a forma certa, mas se você editar o resultado à mão, lembre-se que | preserva newlines e > os dobra em espaços.

Números grandes perdem precisão

Números JavaScript são floats IEEE 754 de 64 bits, então inteiros além de 2 à 53 (cerca de 9 quadrilhões) perdem precisão quando analisados por JSON.parse. A conversão para YAML preserva o valor com perda, não o original. Se seus dados têm identificadores estilo BigInt, codifique-os como strings em JSON antes de converter.

Comentários são perdidos em YAML para JSON

YAML suporta comentários #, JSON não. Quando você converte YAML com comentários de volta para JSON, os comentários são removidos porque JSON não tem sintaxe para eles. Se você faz ida e volta de YAML através de JSON para processamento, espere perder cada linha #. Ferramentas como yq ou ruamel.yaml podem preservar comentários, mas o js-yaml em conformidade com a especificação os descarta.

Privacidade e tratamento de dados

Toda conversão roda em seu navegador via biblioteca js-yaml empacotada na página. Não enviamos seu JSON ou YAML para um servidor, não logamos entradas, e não executamos análises sobre o conteúdo de suas conversões. O botão Copiar usa a Clipboard API que requer um gesto do usuário, e o botão Baixar .yaml usa uma URL de blob em memória, então o arquivo nunca faz ida e volta por nenhuma rede.

Uma vez carregada a página (incluindo o arquivo CDN js-yaml), a ferramenta funciona offline. Você pode desconectar da rede e converter configuração sensível (chaves de API, URLs de banco de dados, nomes de serviços internos) sem que nada saia do seu dispositivo. O arquivo js-yaml é servido pelo jsDelivr com um hash Subresource Integrity, então o pacote não pode ser silenciosamente trocado.

Quando não usar este conversor

Streaming de megabytes de dados

O conversor carrega toda a entrada na memória, analisa-a e emite o resultado de uma só vez. Para arquivos JSON ou YAML de múltiplos megabytes, use yq ou jq em um pipeline shell, ou um parser de streaming na sua linguagem favorita. O navegador não é a ferramenta certa acima de 5 a 10 megabytes.

Dados binários em JSON

Se seu JSON tem blobs binários codificados em Base64 que precisam ser inspecionados ou modificados, converter para YAML não os desempacotará. YAML suporta binário tagueado (!!binary) que js-yaml lida, mas os bytes permanecem em Base64. Use um editor binário dedicado para trabalho real em nível de byte.

Validação de schema

Este conversor verifica se a entrada é JSON ou YAML válido, mas não valida contra um schema (JSON Schema, OpenAPI, CRD Kubernetes, valores Helm). Se você precisa saber se um manifesto Kubernetes está estruturalmente correto para um cluster 1.28, execute kubectl --dry-run=server ou uma ferramenta como kubeval, kubeconform.

Refatoração consciente de schema

Se você precisa renomear um campo em centenas de arquivos YAML, ou atualizar uma versão de API (apps/v1beta1 para apps/v1), use sed, ast-grep, ou yq com consultas de caminho explícitas. O conversor apenas transforma entre formatos, ele não edita conteúdo semântico.

Mais perguntas

JSON é mais seguro que YAML?

Para segurança, sim. yaml.load do PyYAML (antes do 5.1) e parsers permissivos similares poderiam executar código arbitrário a partir de entradas YAML não confiáveis via objetos Python tagueados. JSON não tem tal recurso, todo parser JSON é seguro por design. Parsers YAML modernos (PyYAML 5.1+, js-yaml desde 4.0) usam por padrão safe-load, então a brecha diminuiu, mas JSON ainda é o padrão mais seguro para entrada não confiável.

Por que YAML escolheu recuo em vez de chaves?

Os autores do YAML queriam que configs fossem lidas como esboços, então usaram a mesma convenção que o espaço em branco significativo do Python. Chaves e colchetes são YAML válido (estilo de fluxo), mas o estilo de bloco com recuo é o padrão porque escaneia mais naturalmente para humanos editando em texto puro. O trade-off é que o espaço em branco se torna significativo, o que pega editores que aparam automaticamente espaços no final.

YAML é sempre um superconjunto estrito de JSON?

Desde YAML 1.2 (2009), sim. Qualquer documento JSON válido também é um documento YAML 1.2 válido. YAML 1.1 tinha alguns casos limite (números sexagesimais, o problema da Noruega) onde a relação era mais frouxa. O js-yaml moderno usa 1.2 por padrão, então a propriedade de superconjunto se mantém para esta ferramenta.

Por que o YAML do Kubernetes é tão verboso?

Manifestos Kubernetes têm uma forma de nível superior fixa (apiVersion, kind, metadata, spec) e o spec contém objetos aninhados espelhando os structs Go internos da API. A verbosidade é um efeito colateral de mapear uma API orientada a objetos para um formato de texto puro. Ferramentas como Kustomize, Helm e Pulumi reduzem a verbosidade, mas o YAML subjacente é o que o kubectl realmente envia para o cluster.

Posso fazer ida e volta de JSON através de YAML sem perda de dados?

Para a maioria do JSON, sim. Strings, números, booleanos, null, arrays, objetos todos sobrevivem. Casos limite incluem inteiros muito grandes (perda de precisão), pares substitutos Unicode (depende do parser) e ordem de chaves (YAML pode reordenar). Se suas chaves JSON devem manter sua ordem original, use uma ferramenta que respeite a ordem de inserção (OrderedDict do Python, json-stable-stringify em JavaScript).

E quanto a TOML e HCL?

TOML (Tom's Obvious Minimal Language, 2013 por Tom Preston-Werner) é usado pelo Cargo (Rust), pyproject.toml (Python) e outros. HCL (HashiCorp Configuration Language, 2014) é usado pelo Terraform. Ambos miram o caso de uso de configuração mas usam sintaxe diferente. Este conversor lida apenas com JSON e YAML. Para TOML ou HCL, use conversores dedicados ou yq com o plugin certo.