Converter YAML para JSON Online
Converta YAML para JSON no seu navegador. Perfeito para validar configs de Docker, Kubernetes ou GitHub Actions.
{
"name": "John Doe",
"age": 30,
"active": true,
"tags": [
"developer",
"javascript"
],
"address": {
"city": "Madrid",
"zip": "28001"
}
}Para que serve
YAML para JSON: valide configs DevOps instantaneamente
Docker e Kubernetes
Converta docker-compose.yml ou manifestos do Kubernetes para JSON para validar estruturas ou usar com ferramentas que exigem JSON.
Depuração de CI/CD
Valide workflows do GitHub Actions, pipelines do GitLab CI ou playbooks do Ansible convertendo para JSON para ver a estrutura analisada.
100% privado
Sua configuração YAML é processada no seu navegador. Nunca sai do seu dispositivo. Ideal para configs com segredos.
Detecção de erros
Erros de sintaxe YAML (indentação, tabulações, tipos inválidos) são exibidos claramente antes da conversão.
Como funciona
Três passos, sem complicação
Cole seu YAML
Cole seu arquivo YAML: docker-compose.yml, deployment do Kubernetes, workflow do GitHub Actions ou qualquer configuração YAML.
Conversão e validação
O conversor analisa o YAML conforme a especificação YAML 1.2 e gera JSON válido instantaneamente, exibindo erros de sintaxe caso existam.
Copie o JSON resultante
Copie o JSON formatado para usar na sua API, ferramenta de configuração ou para validar a estrutura do seu YAML.
Perguntas frequentes
Ficou com dúvidas?
YAML (YAML Ain't Markup Language, um acrônimo recursivo) é uma linguagem de serialização de dados projetada para ser legível por humanos. A especificação YAML 1.2 foi publicada em julho de 2009 em yaml.org e é um superconjunto do JSON: todo JSON válido também é YAML válido. O YAML é amplamente usado em configurações de ferramentas DevOps (Docker Compose, Kubernetes, Ansible, Terraform, GitHub Actions, GitLab CI) porque sua sintaxe baseada em indentação é mais legível que o JSON para configurações longas e hierárquicas. Ao contrário do JSON, o YAML suporta comentários (linhas que começam com #), strings multilinha, âncoras e apelidos para reutilizar dados e tipos de dados adicionais como datas ISO 8601.
O YAML oferece dois estilos de string multilinha. O estilo literal (marcado com |) preserva as quebras de linha exatamente como estão escritas, útil para scripts shell, conteúdo de arquivos ou texto formatado. O estilo dobrado (marcado com >) converte as quebras de linha em espaços e só preserva as quebras de parágrafo (linhas em branco), útil para descrições longas. No JSON, ambos se tornam strings com barra-n para quebras de linha literais ou sem quebras para o estilo dobrado. O modificador de chomping (|- para strip e |+ para keep) controla se a quebra de linha final é preservada.
Sim. As âncoras (&nome) e apelidos (*nome) do YAML são uma forma de reutilizar nós no documento. No docker-compose.yml, é comum definir variáveis de ambiente compartilhadas como âncora e referenciá-las em múltiplos serviços com a chave de mesclagem. Nosso conversor expande todas as âncoras e apelidos antes de gerar o JSON, produzindo a estrutura completa sem referências. Esse é o comportamento correto, pois o JSON não tem um conceito equivalente às âncoras do YAML.
Não. O JSON (RFC 7159/RFC 8259) não suporta comentários. Os comentários do YAML (texto após # até o final da linha) são descartados durante o parsing. Essa é uma limitação fundamental do formato JSON, não do conversor. Se você precisar preservar documentação associada a campos de configuração, considere usar JSON Schema (que permite campos description) ou manter o YAML original como fonte de verdade e gerar o JSON sob demanda.
O YAML usa espaços (nunca tabulações) para indentação a fim de indicar hierarquia. A especificação YAML 1.2 não fixa um número específico de espaços, mas a convenção mais comum são 2 espaços. A consistência dentro do mesmo nível hierárquico é fundamental. Misturar tabulações e espaços é um erro de sintaxe no YAML (ao contrário do Python, que aceita tabulações). O erro mais comum é misturar acidentalmente tabulações com espaços, especialmente ao editar YAML em editores que expandem tabulações de forma diferente.
Sim. Manifestos do Kubernetes (Deployments, Services, ConfigMaps, Ingress) e arquivos docker-compose.yml são YAML padrão e convertem corretamente para JSON. Isso é útil para validar a estrutura do manifesto, passá-lo para ferramentas que só aceitam JSON (como alguns clientes da API do Kubernetes) ou depurar comportamentos inesperados causados por erros sutis de YAML. A API do Kubernetes aceita tanto YAML quanto JSON; internamente, o kubectl converte YAML para JSON antes de enviar a requisição ao API server.
Converter YAML para JSON: validação de configurações DevOps e Kubernetes no navegador
O YAML (YAML Ain't Markup Language) se tornou o formato de configuração dominante no ecossistema DevOps moderno. Docker Compose (introduzido em 2014, agora parte do Docker Engine desde a versão 20.10), Kubernetes (cuja API aceita manifestos em YAML ou JSON desde seu lançamento pelo Google em 2014), GitHub Actions (lançado em novembro de 2019), GitLab CI/CD, Ansible (Red Hat, 2012), Terraform (HashiCorp, 2014) e Helm charts usam o YAML como formato principal de configuração. A especificação YAML 1.2, publicada em yaml.org em julho de 2009, estabelece que o YAML é um superconjunto estrito do JSON, o que significa que qualquer documento JSON também é um documento YAML válido. Essa relação torna a conversão entre os dois formatos semanticamente perfeita: não há perda de informações estruturais, apenas diferenças de representação.
Converter YAML para JSON é especialmente útil em vários cenários de trabalho DevOps: depuração de pipelines CI/CD onde um erro de indentação produz comportamentos inesperados (a representação JSON torna a estrutura explícita e sem ambiguidade); uso de ferramentas que só aceitam JSON como entrada (alguns clientes da API REST do Kubernetes, ferramentas de validação de JSON Schema ou processadores como jq que trabalham nativamente com JSON); migração de configurações entre ferramentas que usam formatos diferentes; e validação de que o YAML é analisado como esperado, especialmente quando se usam recursos avançados como âncoras, apelidos, chaves de mesclagem, tipos explícitos ou strings multilinha com os blocos literal e dobrado.
O parsing do YAML apresenta alguns desafios conhecidos que levaram ao chamado Problema da Noruega: no YAML 1.1 (versão usada pelo PyYAML antes da 6.0 e pelo libyaml antes da 0.2.5), o valor NO era interpretado como booleano false, fazendo com que o código de país da Noruega (NO) fosse analisado incorretamente. O YAML 1.2 (a especificação de julho de 2009) corrigiu isso: apenas true e false (sem distinção de maiúsculas e minúsculas) são booleanos, e valores como yes, no, on e off que o YAML 1.1 tratava como booleanos agora são strings. Nosso conversor usa uma biblioteca que implementa o YAML 1.2, garantindo comportamento correto e moderno. Para projetos que usam PyYAML, é importante atualizar para a versão 6.0 ou superior (lançada em março de 2022), que adicionou suporte ao carregador seguro compatível com YAML 1.2 via yaml.safe_load().