Converter JSON para YAML Online
Converta JSON para YAML legível. Ideal para criar configs de Docker Compose, Kubernetes ou GitHub Actions.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Casos de uso
Do JSON da API para configuração YAML legível
Criar configs DevOps
Transforme respostas JSON de APIs do Kubernetes, Docker ou ferramentas cloud em arquivos de configuração YAML editáveis.
Fluxo de trabalho DevOps
Converta templates JSON do CloudFormation ou ARM do Azure para YAML equivalente para melhor legibilidade e manutenção.
100% privado
Seu JSON é processado no seu navegador. Nunca é enviado para nenhum servidor. Sem cadastro, sem limites de uso.
YAML limpo
Indentação de 2 espaços, tipos corretamente representados, pronto para colar no docker-compose.yml ou em um manifesto do Kubernetes.
Como funciona
Três passos, sem complicação
Cole seu JSON
Cole qualquer JSON válido: resposta de API, configuração, dados estruturados. Tanto JSON formatado quanto minificado são aceitos.
Conversão para YAML limpo
O JSON é convertido para YAML com indentação de 2 espaços, seguindo as convenções dos projetos DevOps mais populares.
Copie e use o YAML
Copie o YAML resultante para usar como base do seu docker-compose.yml, manifesto do Kubernetes ou qualquer config YAML.
Perguntas frequentes
Ficou com dúvidas?
O YAML supera o JSON em legibilidade para configurações longas e hierárquicas. As principais vantagens do YAML são: suporte a comentários (indispensável em arquivos de configuração documentados), sintaxe mais concisa (sem chaves nem aspas na maioria dos casos), melhor representação de strings multilinha (scripts, comandos, texto) e leitura mais natural de listas. O JSON é superior quando o destino é uma API ou um programa que o processa automaticamente: o parsing é mais rápido, a especificação é mais simples e estrita e há menos ambiguidade. A regra prática no DevOps é: YAML para arquivos que humanos editam diretamente, JSON para dados trocados entre sistemas.
O conversor gera YAML estruturalmente equivalente ao JSON de entrada, sem comentários (o JSON não tem comentários, então não há informações a transferir). No entanto, o YAML gerado é um excelente ponto de partida: abra-o em qualquer editor e adicione comentários manualmente com # antes ou depois de qualquer linha. Em ferramentas como docker-compose.yml e manifestos do Kubernetes, os comentários são fundamentais para documentar o propósito de cada valor de configuração.
O JSON é consideravelmente mais rápido de analisar que o YAML. O parsing do JSON é O(n) com constantes muito baixas: parsers como simdjson (usado no Node.js desde a versão 17) processam até 3 GB/s em hardware moderno. O YAML requer um parser mais complexo (que lida com âncoras, apelidos, tipos explícitos e vários estilos de string) e é tipicamente 10 a 50 vezes mais lento que o JSON para o mesmo volume de dados. Para arquivos de configuração pequenos (um docker-compose.yml de alguns KB), a diferença é imperceptível. Para APIs que trocam milhões de mensagens por segundo, o JSON é a escolha correta. O uso do YAML em ferramentas DevOps é uma decisão de ergonomia para os humanos que editam esses arquivos.
O conversor usa 2 espaços de indentação, que é a convenção adotada por praticamente todo o ecossistema DevOps: Kubernetes (o kubectl gera YAML com 2 espaços), Helm, GitHub Actions, GitLab CI, Ansible e Docker Compose. Alguns projetos usam 4 espaços (comum em projetos Python onde a convenção PEP 8 de 4 espaços influencia os desenvolvedores), mas 2 espaços é o padrão de fato na comunidade DevOps.
A conversão de tipos é direta: números JSON (inteiros e ponto flutuante) são representados como escalares YAML sem aspas; booleanos JSON (true/false) se tornam true/false no YAML; null do JSON se torna null ou til no YAML; strings são representadas sem aspas quando não há ambiguidade, ou entre aspas simples ou duplas quando o valor poderia ser interpretado como outro tipo (por exemplo, a string 42 precisa de aspas para não virar número, e true precisa de aspas para não virar booleano).
Converter JSON para YAML: de respostas de API para configurações DevOps legíveis
Converter JSON para YAML é uma operação rotineira nos fluxos de trabalho DevOps modernos. As APIs do Kubernetes (a API REST do Kubernetes retorna recursos em JSON por padrão), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager e a maioria das ferramentas de infraestrutura como código têm interfaces JSON nativas, mas seus usuários preferem trabalhar com arquivos de configuração YAML por sua maior legibilidade. O kubectl, a ferramenta de linha de comando do Kubernetes, converte automaticamente entre YAML e JSON: quando você executa kubectl get deployment meu-app -o yaml, o Kubernetes retorna o objeto JSON da API e o kubectl o converte para YAML para exibição. A conversão inversa (JSON para YAML) é útil quando você quer criar um manifesto YAML a partir de uma resposta de API, quando migra configurações entre ferramentas ou quando quer documentar uma configuração existente adicionando comentários YAML.
O YAML (especificação 1.2, publicada em yaml.org em julho de 2009) é um superconjunto do JSON, garantindo que a conversão de JSON para YAML seja sempre possível sem perda de informações. A conversão inversa (YAML para JSON) perde apenas os comentários, que o JSON não pode representar. As vantagens do YAML para configurações humanas são bem documentadas: a ausência de chaves e colchetes reduz o ruído visual em 30 a 40% para configurações típicas; os comentários permitem documentar o propósito de cada parâmetro diretamente no arquivo; as strings multilinha (especialmente com o bloco literal) permitem incluir scripts shell, consultas SQL ou conteúdo de arquivos diretamente na configuração sem escapar caracteres especiais.
No ecossistema do Kubernetes, a escolha entre YAML e JSON está bem estabelecida: os arquivos que os desenvolvedores criam e mantêm em repositórios git são YAML; os dados que o kubectl envia ao API server são JSON (o kubectl converte YAML para JSON internamente antes de fazer a chamada HTTP); as respostas do API server são JSON; e as ferramentas de automação (Helm, Kustomize, Argo CD, Flux) trabalham com YAML como entrada e JSON como protocolo interno. Essa separação entre o formato humano (YAML) e o formato de protocolo (JSON) é um padrão seguido também pelo GitHub Actions (os workflows são YAML, a API do GitHub é JSON), GitLab CI, Ansible (playbooks em YAML, dados de inventário dinâmico em JSON) e Terraform (o HCL é a alternativa da HashiCorp, mas ele também aceita JSON nativo em arquivos .tf.json).