YAML para JSON

Sim, completamente. Não há registo, nem conta, nem limite de utilização, nem paywall. Todas as funcionalidades desta página estão disponíveis para toda a gente, sempre.

Não. A conversão corre no seu navegador com JavaScript. O seu YAML nunca é transmitido para lado nenhum — não há endpoint de conversão no servidor, nem registos, nem análise do conteúdo que cola. Pode confirmar abrindo o separador Rede enquanto converte, ou desligando-se da internet: a página continua a funcionar.

Não. Este é um conversor de YAML para JSON online: corre no separador que já tem aberto, sem download, sem ferramenta de linha de comandos e sem extensão. Todos os conversores online têm de decidir onde a conversão acontece — a maioria envia o seu documento para o servidor deles; este mantém-no na sua máquina. Se preferir um script, o guia «Converter YAML em JSON em código» cobre a linha de comandos, Python, Node.js e Go.

Não há nenhum teto artificial. A conversão acontece na sua própria máquina, por isso o limite prático é a memória do dispositivo. Ficheiros de alguns megabytes convertem sem problemas; documentos muito grandes podem pausar brevemente a página durante o parsing.

Sim. Use o botão de troca entre os dois painéis para inverter a direção sem sair da página, ou vá ao conversor dedicado de JSON para YAML. A troca leva a saída atual como nova entrada, por isso pode fazer a viagem de ida e volta com um documento.

São removidos, porque o JSON não tem sintaxe para comentários. O conversor diz-lhe quantos foram removidos em vez de os descartar em silêncio. Se precisar de os manter, use o formatador de YAML, que reformata o YAML no lugar e os preserva.

Ficheiros que separam documentos com --- são totalmente suportados. Pode obtê-los como um array JSON com todos os documentos, ou como JSON Lines (NDJSON) com um objeto JSON compacto por linha, que é o formato esperado pelo kubectl e pela maioria dos pipelines de logs. Manifestos do Kubernetes e saída do Helm são tipicamente multi-documento.

Sim. Os anchors (&nome) e os aliases (*nome) são expandidos nos seus valores completos, já que o JSON não consegue exprimir uma referência. As merge keys (<<) são resolvidas por defeito, que é aquilo de que os ficheiros do Docker Compose, GitLab CI e Ansible dependem. Pode desativar a resolução se preferir ver a chave << em bruto.

O YAML 1.2 trata valores sem aspas como no, yes, on e off como strings simples. O YAML 1.1 trata-os como booleanos — por isso country: no torna-se false. O YAML 1.1 também lê 022 como o octal 18 e 12:30 como o número 750 em base 60. Este conversor usa YAML 1.2 por defeito e avisa-o sempre que um valor do seu documento seria lido de forma diferente em 1.1.

As duas causas mais comuns são um carácter de tabulação usado para indentar, que o YAML proíbe por completo, e um valor sem aspas que contém dois pontos, como title: foo: bar. Parênteses e aspas por fechar também surgem como erros de indentação na maioria dos parsers; este conversor deteta-os especificamente e aponta para o delimitador que nunca foi fechado.

Sim. Se o documento não puder ser analisado, recebe uma descrição clara do problema, a linha e coluna exatas, uma correção sugerida e um marcador na linha em causa no editor. A página dedicada Validador de YAML é o mesmo motor com o painel de saída focado no diagnóstico.

Depois de carregada, sim. Tudo o que é preciso para converter já está no seu navegador, por isso a ferramenta continua a funcionar se perder a ligação.

Cole o seu YAML no painel da esquerda do conversor no topo desta página — converte YAML em JSON online, no seu navegador, enquanto escreve, por isso não há botão para carregar e nada é enviado. Defina a indentação para 2 espaços, 4 espaços, tabulações ou minificado, ordene as chaves se quiser, depois copie o JSON ou descarregue-o como ficheiro .json. Se o documento não for analisado, recebe a linha e coluna exatas, uma explicação clara e uma correção sugerida em vez de um painel vazio. Para uma conversão que precise de repetir, yq -o=json input.yaml faz o mesmo trabalho num terminal.

Carregue em Enviar para escolher um ficheiro .yaml ou .yml, ou arraste-o para qualquer ponto desta página, e depois carregue em Baixar para guardar o resultado como ficheiro .json. O ficheiro é lido pelo seu navegador e nunca é enviado para lado nenhum, o que importa em configurações com nomes de host, registries ou credenciais. Numa shell, use yq -o=json input.yaml > output.json, ou converta um diretório inteiro com: for f in *.yaml; do yq -o=json "$f" > "${f%.yaml}.json"; done

Sim, em quase todos os casos. O YAML 1.2 é definido como um superconjunto de JSON, e qualquer documento YAML construído com mapas, sequências, strings, números, booleanos e nulos comuns tem um equivalente JSON exato. Quatro coisas não sobrevivem à viagem: os comentários, porque o JSON não tem sintaxe para eles; anchors e aliases, que são expandidos nos seus valores completos porque o JSON não consegue exprimir referências; chaves de mapa que não são strings, como datas ou estruturas aninhadas, que o JSON não permite; e tags personalizadas como !Ref ou !GetAtt, que não têm significado fora da sua ferramenta. Este conversor reporta cada um destes casos em vez de os descartar em silêncio.

É ao contrário: o JSON é YAML válido, mas o YAML em geral não é JSON válido. A especificação YAML 1.2 define a linguagem como um superconjunto de JSON, por isso qualquer documento JSON pode ser passado sem alterações a um parser YAML 1.2 — pode colar JSON no painel YAML acima e será analisado. Um documento YAML só é JSON válido por acaso, se estiver escrito no estilo de fluxo do JSON com todas as chaves e strings entre aspas e sem comentários; o YAML comum baseado em indentação é rejeitado por qualquer parser JSON. A garantia aplica-se ao YAML 1.2 — o YAML 1.1, que o PyYAML e ferramentas mais antigas implementam, não é um superconjunto estrito de JSON.

O JSON é um formato de intercâmbio estrito para máquinas; o YAML é um formato de configuração para pessoas que consegue exprimir os mesmos dados. Em concreto: o YAML tira a estrutura da indentação enquanto o JSON usa chavetas e parênteses retos; o YAML suporta comentários com # e o JSON não tem nenhum; o YAML pode reutilizar blocos através de anchors, aliases e merge keys enquanto o JSON repete cada valor por inteiro; o YAML pode conter vários documentos num ficheiro separados por ---, onde o JSON contém exatamente um valor; e o YAML normalmente deixa as strings sem aspas, o que é conveniente até country: NO ser lido como false. Como o YAML 1.2 é um superconjunto de JSON, tudo o que o JSON exprime o YAML também exprime.

Use YAML quando uma pessoa escreve e mantém o ficheiro, e JSON quando uma máquina o escreve ou lê. O YAML compensa em configuração lida em revisão de código — manifestos do Kubernetes, Docker Compose, workflows do GitHub Actions, playbooks do Ansible, especificações OpenAPI — porque os comentários explicam os valores e os anchors reduzem a repetição. O JSON compensa em corpos de pedidos e respostas de API, linhas de log, fixtures de testes e tudo o que é gerado ou armazenado em volume: analisa-se mais depressa, todas as linguagens trazem um parser, não há espaços significativos para errar nem ambiguidade de versão para discutir. Quando ambos os argumentos se aplicam, a resposta habitual é escrever em YAML e converter para JSON em tempo de build, que é para isso que serve o conversor no topo desta página.

O YAML é mais fácil de ler e mais difícil de acertar; o JSON é mais ruidoso e muito mais previsível. Em legibilidade o YAML ganha claramente em configuração aninhada: sem parênteses de fecho, sem aspas em cada chave, sem vírgulas para pôr no sítio errado, e com comentários para explicar os valores que não são óbvios — o mesmo manifesto do Kubernetes é cerca de 40% mais curto em YAML do que em JSON. Em usabilidade a balança inverte-se. A indentação é significativa, por isso uma tabulação perdida ou uma chave irmã desalinhada parte o documento; valores sem aspas podem mudar de tipo em silêncio (yes, no, on, off, 022, 12:30); chaves duplicadas e a divisão entre YAML 1.1 e 1.2 produzem ficheiros que passam no parsing e mesmo assim se comportam mal; e os erros dos parsers YAML são notoriamente vagos sobre onde está o problema real. O JSON não tem nenhum destes modos de falha, e é por isso que a posição prática é escrever YAML e validá-lo ou convertê-lo antes de o pôr em produção.