Validador e linter de YAML — encontre erros e armadilhas escondidas
Valide YAML com a linha e a coluna exatas de cada erro e pegue os erros que os parsers aceitam sem avisar: booleanos yes/no, tabulações, chaves duplicadas.
services:
web:
image: nginx:1.27
ports:
- '8080:80'
- '22:22'
environment:
COUNTRY: 'NO'
DEBUG: 'yes'
APP_VERSION: 1.1
db:
image: postgres:16
restart: unless-stopped
Chaves duplicadas: exibidas com o último valor prevalecendo, que é o que muitos parsers fazem silenciosamente. A visualização formatada é reconstruída a partir dos dados interpretados, então comentários e âncoras não são mantidos. Corrija os problemas no seu arquivo original.
Roda inteiramente no seu navegador. Seu YAML nunca é enviado, então os segredos dos arquivos de configuração ficam na sua máquina. Ver todas as ferramentas grátis.
Encontrou um problema ou algo que poderia ser melhor? Lemos todas as mensagens e corrigimos rápido.
Este validador de YAML grátis verifica um arquivo YAML em busca de erros de sintaxe e mostra a linha e a coluna exatas, com as linhas ao redor e um sinal ^ sob o problema. Cole um manifesto do Kubernetes, um docker-compose.yml, um workflow do GitHub Actions ou uma especificação OpenAPI e saiba em um segundo se ele é interpretado corretamente e, se não, onde quebra.
Um parser aceitar o seu arquivo não é o mesmo que o arquivo significar o que você pensa. O linter também sinaliza valores que parsers de YAML 1.1 (PyYAML, SnakeYAML, Go yaml.v2) leem de forma diferente do YAML 1.2: NO vira false, 0755 vira 493, 22:22 vira 1342 e 1.10 vira 1.1. Ele lista todas as chaves duplicadas com os dois números de linha, tabulações na indentação e "chave:valor" escrito sem espaço. Ele verifica a sintaxe e essas armadilhas; não valida contra um esquema, como a API do Kubernetes.
Como usar
- Cole o seu YAML no editor. Um exemplo de docker-compose com alguns erros propositais já vem carregado para mostrar o que é sinalizado.
- Leia a barra de status: verde significa válido; vermelho mostra o erro com a linha e a coluna e as linhas ao redor.
- Clique em qualquer item da lista do linter para ir até aquela linha no editor e corrigi-la.
- Alterne entre as visualizações formatadas em YAML e JSON para conferir como o arquivo foi realmente interpretado: é aí que as surpresas com yes/no ou 0755 ficam óbvias.
- Copie ou baixe a saída formatada se precisar, e continue corrigindo o arquivo original para preservar os comentários.
Perguntas frequentes
O que é o problema da Noruega no YAML?
No YAML 1.1, as palavras sem aspas y, yes, n, no, on e off (em qualquer combinação comum de maiúsculas e minúsculas) são booleanos. Então uma lista de códigos de países que contém NO, de Noruega, gera false em vez da string "NO". O YAML 1.2 (2009) corrigiu isso: só true e false são booleanos. Muitos parsers muito usados ainda seguem o 1.1, incluindo PyYAML, o Psych do Ruby, o SnakeYAML do Java e o yaml.v2 do Go, então a correção segura é colocar esses valores entre aspas: "NO", "yes", "on".
Por que tabulações não são permitidas no YAML?
A especificação do YAML proíbe tabulações na indentação porque a largura delas não é definida, e a indentação é como o YAML expressa a estrutura. Tabulações são permitidas dentro de valores e comentários, só não no espaço em branco no início de uma linha. Configure o seu editor para inserir espaços em arquivos .yml e .yaml; dois espaços por nível é a convenção mais comum.
Chaves duplicadas são permitidas no YAML?
Não. A especificação do YAML exige que as chaves de um mapeamento sejam únicas, mas os parsers discordam sobre o que fazer: alguns lançam um erro (como este validador), enquanto outros mantêm o último valor sem avisar. Isso torna as duplicatas perigosas: em um manifesto longo, você pode editar a primeira ocorrência e não ver efeito nenhum. Esta ferramenta lista cada duplicata com a linha em que a chave foi definida pela primeira vez.
Por que o meu YAML diz "bad indentation of a mapping entry"?
Ou a linha está indentada de forma diferente das outras chaves do mesmo nível, ou um valor contém dois-pontos seguidos de espaço e precisa de aspas. Por exemplo, title: Note: read this falha porque o parser vê uma segunda chave. Escreva title: "Note: read this". Confira a linha indicada e a de cima; o erro muitas vezes começa na linha anterior.
O YAML é um superconjunto do JSON?
O YAML 1.2 foi projetado para que todo JSON válido também seja YAML válido, e na prática qualquer documento JSON é interpretado aqui. O contrário não é verdade: o YAML acrescenta comentários, âncoras e aliases, strings de várias linhas e vários documentos por arquivo. Use a visualização em JSON para ver como um arquivo YAML se traduz em dados JSON simples.
Ele valida esquemas do Kubernetes ou do GitHub Actions?
Não. Ele verifica a sintaxe YAML e as armadilhas acima, que causam a maioria das falhas reais, mas não sabe quais chaves um Deployment do Kubernetes ou um workflow do GitHub permitem. Para validar o esquema, use kubectl apply --dry-run=server, o kubeconform ou a extensão YAML do VS Code com o JSON Schema correspondente.
YAML 1.1 e YAML 1.2: valores que mudam de significado
Este validador interpreta com as regras do YAML 1.2 (js-yaml). Se o seu arquivo for lido por um parser de YAML 1.1, estes valores sem aspas significam outra coisa, e o linter avisa sobre cada um:
• yes, no, on, off, y, n → booleanos no 1.1, strings no 1.2. Os workflows do GitHub Actions começam com on:, que um parser 1.1 lê como a chave true.
• 0755 → octal 493 no 1.1, decimal 755 no 1.2. Permissões de arquivo e códigos postais com zero à esquerda sofrem com isso.
• 22:22 → 1342 no 1.1 (base 60), a string "22:22" no 1.2. A documentação do Compose do Docker recomenda colocar mapeamentos de portas entre aspas exatamente por isso.
• 1.10 → o número 1.1 nas duas versões. Coloque números de versão entre aspas.
• 2024-01-05 → um timestamp na maioria dos parsers, não uma string.
A regra que evita todos eles: coloque entre aspas qualquer valor que deveria ser texto, mas parece outra coisa.
Erros comuns de YAML e como corrigi-los
• "bad indentation of a mapping entry": indentação inconsistente ou um valor sem aspas que contém ": ".
• "end of the stream or a document separator is expected": normalmente uma linha menos indentada que as vizinhas, ou texto depois de uma aspa de fechamento.
• "can not read a block mapping entry; a multiline key may not be an implicit key": muitas vezes falta um dois-pontos na linha anterior, ou uma aspa foi aberta e não fechada.
• "unexpected end of the stream within a double quoted scalar": uma " não fechada em algum ponto acima da linha indicada.
• Valores que começam com @, `, *, &, !, | ou > têm significado especial ou são reservados. Coloque-os entre aspas.
• Um # precedido de espaço inicia um comentário, então password: abc #123 armazena abc. Coloque entre aspas valores que contêm " #".
Ferramentas grátis relacionadas
- Formatador de JSON — Formate, minifique e valide JSON, com erros de parsing localizados por linha e coluna. No seu navegador, sem upload.
- JSON para TypeScript — Cole um exemplo de JSON e receba interfaces TypeScript, um schema Zod, JSON Schema ou tipos para Go, Python, Java, C#, Kotlin, Swift e Rust.
- Formatador de SQL — Transforme SQL bagunçado em consultas legíveis e com indentação consistente para PostgreSQL, MySQL, T-SQL, BigQuery e mais. Roda no seu navegador.
- Testador de regex — Teste uma expressão regular num texto de exemplo, com destaque das correspondências ao vivo, grupos de captura e prévia de substituição. Grátis, no navegador.
- Comparador de textos — Compare duas versões de um texto, código ou arquivo JSON e veja exatamente quais linhas, palavras e caracteres mudaram.