Conversor JSON ↔ YAML · Encoding
Converta JSON ↔ YAML — e veja exatamente o que muda.
Todo conversor transforma YAML em JSON. Este também diz o que isso custou: os comentários que ele descartou, as âncoras que ele expandiu, a data que ele reescreveu, o inteiro que ele arredondou. Parser YAML 1.2 real, inteiramente no seu navegador.
Roda no seu navegador — nada do que você cola sai desta página. Como comprovamos isso
Playground do conversor JSON ↔ YAML
Every JSON file is already valid YAML — YAML 1.2 is a superset of JSON. The reverse is not true, which is why the direction is yours to pick.
Off by default: the order you wrote is kept, except for integer-like keys.
Results update as you type — press Enter to run now.
Press Esc to release keyboard focus from the editor; ⌘/Ctrl + Enter converts and leaves the editor. Nothing you paste is uploaded.
An anchor (&name) marks a value so an alias (*name) can reuse it. JSON has neither, so every alias is written out as a full copy.
Paste JSON or YAML above — or tap an example — to see the converted document here, plus every comment, anchor, timestamp and out-of-range number the conversion costs you.
A lacuna
Conversores silenciosos, e respostas que dependem do parser.
A dúzia de conversores bancados por anúncios no topo dos resultados de busca faz todos a mesma coisa: imprime o outro formato e não fala nada. Seus comentários se foram. Suas âncoras foram expandidas em cópias. Aquela data sem aspas agora é uma string com um fuso horário que você nunca escreveu. O identificador de 19 dígitos perdeu os dois últimos. Nada na página menciona nada disso, então a primeira vez que você descobre é na revisão. Ou em produção.
Pergunte a um assistente de IA e você ganha um segundo problema: a resposta depende de qual versão do YAML o modelo aprendeu. verify: no é a string "no" no YAML 1.2 e o booleano false no YAML 1.1, e as duas respostas são afirmadas com a mesma confiança. 0777 é 777 em uma e 511 na outra — o que, para um modo de arquivo, é a diferença entre um deploy quebrado e um deploy que funciona.
Esta ferramenta responde com fato verificável em vez de suposição: um parser YAML 1.2 real roda na sua aba, a saída é determinística e cada passo com perda é nomeado com a linha ou o caminho em que aconteceu. A tabela de referência abaixo fixa os valores em que as duas versões do YAML divergem, para você conferir uma afirmação em segundos.
Trabalhando em um pipeline? O validador do GitHub Actions e o validador do GitLab CI analisam o YAML em si.
O pipeline
Como funciona.
Quatro passos determinísticos rodam enquanto você digita — todos dentro da sua aba, e cada passo com perda se reporta sozinho.
-
Analisar com um parser real.
js-yaml 4 sobre o esquema core do YAML 1.2, ou JSON.parse — nunca uma expressão regular. Se não analisar, você recebe a linha e a coluna, não "inválido".
-
Normalizar, e registrar.
Uma única passagem converte datas em strings ISO-8601, !!binary em base64 e ±Infinity/NaN em null — cada conversão emitindo um diagnóstico com o caminho em que aconteceu.
-
Emitir de forma determinística.
Sem dobra de linhas e sem âncoras geradas: a mesma entrada sempre produz os mesmos bytes, e a saída é relida exatamente como aparece.
-
Reportar cada perda.
Comentários, âncoras, chaves de mesclagem, documentos extras, chaves numéricas reordenadas e inteiros arredondados ficam listados ao lado da saída, para você decidir se a conversão foi aceitável.
Com exemplos
Quatro perdas em seis linhas.
Um comentário, uma âncora, uma chave de mesclagem e uma data sem aspas — o YAML do dia a dia que nenhum conversor consegue levar intacto para o outro lado.
Entrada
YAML comum: um comentário, uma âncora, uma chave de mesclagem, uma data nua.
# padrões do rollout, compartilhados pelos dois jobs
defaults: &defaults
retries: 2
verify: no # string no YAML 1.2, false no YAML 1.1
release:
<<: *defaults
date: 2024-01-15Saída, com o recibo
Quatro perdas reportadas: o comentário se foi, *defaults foi copiado, <<: foi achatado, e a data virou uma string ISO-8601. no continuou string — e é sinalizado, porque o PyYAML leria como false.
{
"defaults": { "retries": 2, "verify": "no" },
"release": {
"retries": 2,
"verify": "no",
"date": "2024-01-15T00:00:00.000Z"
}
}Referência
Onde o YAML 1.2 e o YAML 1.1 divergem.
O mesmo escalar sem aspas, lido por esta ferramenta (js-yaml 4, esquema core do YAML 1.2) e por um parser YAML 1.1 como PyYAML. Quando uma ferramenta e um colega discordam sobre um valor, a resposta está quase sempre nesta tabela.
| Entrada sem aspas | YAML 1.2 — esta ferramenta | YAML 1.1 — PyYAML |
|---|---|---|
| no | "no" (string) | false (booleano) O problema da Noruega. O mesmo vale para yes / on / off / y / n. |
| true | true (booleano) | true (booleano) As duas versões só concordam em true e false. |
| ~ | null | null null, Null, NULL, ~ e um valor vazio são null nas duas. |
| 2024-01-15 | 2024-01-15T00:00:00.000Z | 2024-01-15T00:00:00.000Z As duas resolvem uma data sem aspas como timestamp; JSON não tem tipo data, então ela é escrita como string ISO-8601. |
| 0777 | 777 (decimal) | 511 (octal) A divergência mais perigosa de todas: modos de arquivo mudam de significado em silêncio. Escreva 0o777. |
| 0o777 | 511 | "0o777" (string) O YAML 1.1 não entende a forma octal explícita do YAML 1.2 de jeito nenhum. |
| 1:30 | "1:30" (string) | 90 (sexagesimal) O YAML 1.1 lia números separados por dois-pontos na base 60. O YAML 1.2 removeu isso. |
| .inf | Infinity | Infinity JSON não tem infinito, então o valor vira null — com um aviso. |
| 9007199254740993 | 9007199254740992 | 9007199254740993 Não é uma divergência do YAML, e sim do JavaScript: acima de 2^53 − 1 o valor exato se foi. |
Colocar entre aspas elimina toda divergência desta tabela. Quando um escalar precisa continuar string nos dois mundos, use aspas — e quando esta ferramenta emite YAML, ela coloca as aspas por você.
Próximo passo
Agora confira se o YAML em si é válido.
Converter prova que um documento é analisável; não prova que o pipeline vai aceitá-lo. Passe o YAML do seu workflow pelo validador do GitHub Actions ou pelo validador do GitLab CI para pegar os problemas de esquema e de segurança que um conversor não consegue ver.
YAML → JSON · 2 docs · 31 keys · 1 warning · 3 notes
note: comments were dropped
note: 1 alias expanded into a copy
note: "no" stayed a string (YAML 1.1 reads false)
warning: 9007199254740993 → 9007199254740992FAQ
Suas perguntas, respondidas.
Toque em uma pergunta para expandir a resposta.
O que o conversor JSON ↔ YAML faz?
Ele converte JSON para YAML ou YAML para JSON no seu navegador e, depois, diz o que a conversão custou. Comentários, âncoras e aliases, chaves de mesclagem, datas, streams com vários documentos e inteiros grandes demais para o JavaScript representar com exatidão não sobrevivem ao caminho: cada um deles é reportado como um aviso ou uma nota com nome próprio ao lado da saída, em vez de desaparecer silenciosamente.
Qual versão do YAML é usada?
YAML 1.2, via js-yaml 4 e seu esquema padrão (core) — o mesmo leitor que a maioria das ferramentas JavaScript modernas usa. Isso importa porque o YAML 1.2 abandonou as grafias booleanas do YAML 1.1: aqui no, yes, on e off são strings comuns, e só true e false são booleanos. PyYAML, o Psych do Ruby e ferramentas antigas do Kubernetes ainda seguem o YAML 1.1, então a tabela de referência desta página fixa exatamente os valores em que as duas versões divergem.
O que é o "problema da Noruega"?
Um parser YAML 1.1 lê o escalar sem aspas NO como o booleano false, então uma lista de países que contém o código ISO da Noruega passa a ser uma lista que contém false. A mesma armadilha pega ON, OFF, YES, Y e N. Este conversor segue o YAML 1.2, então esses valores continuam sendo strings — e cada ocorrência encontrada é sinalizada, para você saber que uma ferramenta YAML 1.1 mais adiante na cadeia discordaria. No sentido inverso eles saem entre aspas ("NO" vira 'NO'), e é exatamente isso que mantém o arquivo seguro para o PyYAML.
Meu documento sai do meu navegador em algum momento?
Não. A análise, a conversão e o relatório rodam 100% no cliente, dentro da sua aba: não há servidor, não há conta e não há registro de log. Você pode colar manifestos de produção, configurações de CI e arquivos com nomes de host internos ou secrets sem risco.
O que acontece com os comentários do YAML?
Eles são perdidos, e a ferramenta avisa. JSON não tem sintaxe de comentário, e preservá-los em uma ida e volta exigiria uma árvore sintática que entende comentários em vez de um parser de valores: esse é um não-objetivo deliberado aqui. Se os comentários precisam sobreviver, edite o YAML direto em vez de passá-lo por JSON.
Como as âncoras e os aliases do YAML são convertidos?
Eles são expandidos no lugar. Uma âncora (&defaults) marca um valor; um alias (*defaults) o reutiliza. JSON não tem nenhum dos dois, então cada alias vira uma cópia completa do valor ancorado: o documento significa a mesma coisa, mas fica maior e o compartilhamento se perde. Chaves de mesclagem (<<:) são expandidas do mesmo jeito, com as chaves herdadas escritas por inteiro. Um alias recursivo, em que um nó contém a si mesmo, não pode ser representado em JSON de forma alguma e é reportado como erro em vez de derrubar a página.
Por que meu número grande mudou?
O JavaScript guarda números como doubles IEEE-754, então inteiros acima de 2^53 − 1 (9007199254740991) não podem ser representados com exatidão. 9007199254740993 vira 9007199254740992 no instante em que é analisado — por esta ferramenta, pelo JSON.parse no seu próprio código e por qualquer outro conversor de navegador. A diferença é que este avisa e cita os dígitos originais. Se o valor é um identificador e não uma quantidade, mantenha-o como string entre aspas.
Como converto um manifesto YAML do Kubernetes para JSON para o kubectl patch?
Cole o manifesto, deixe o sentido em YAML → JSON e copie a saída. O kubectl patch --type=merge -p espera um documento JSON, e um manifesto com vários documentos (vários recursos separados por ---) vira aqui um array JSON, que o kubectl não aceita como patch: separe-os e converta um recurso por vez. Quantidades como 256Mi e 500m continuam sendo strings nos dois formatos, que é o que o Kubernetes espera.
Posso converter um template do CloudFormation?
Não enquanto ele usar as tags abreviadas. !Ref, !GetAtt e !Sub são tags YAML específicas do CloudFormation, e não fazem parte do esquema padrão, então um parser aderente ao padrão as rejeita — esta ferramenta diz exatamente em qual tag ela travou e onde. Reescreva-as na forma longa (Ref: BucketName em vez de !Ref BucketName) e o template converte.
A ordem da saída corresponde à da minha entrada?
Sim, com uma exceção inevitável. A ordem das chaves é preservada por padrão, e "Sort keys" ordena todos os níveis quando você quer um diff estável. A exceção são as chaves com cara de inteiro: objetos JavaScript sempre enumeram chaves como "1" e "2" primeiro, em ordem numérica crescente, antes de qualquer outra chave — não importa em que ordem foram escritas nem se estavam entre aspas. A ferramenta avisa quando seu documento contém essas chaves.
More free, private DevOps tools.
O conversor JSON ↔ YAML é uma das ferramentas do OpsCanopy — uma copa crescente de validadores, conversores e testadores de navegador que nunca tocam um servidor.
Mais em Codificação
39 ferramentas gratuitas, todas capazes de funcionar offline — o opscanopy.com não exige cadastro e não envia nada.
Relacionados: o validador do GitHub Actions e o validador do GitLab CI para analisar YAML de pipeline, o conversor Docker Run para Compose para transformar um comando em YAML, o testador de rotas do Alertmanager para percorrer uma árvore de roteamento, e o codificador / decodificador Base64 quando o payload vem codificado e não estruturado — ou navegue pelo diretório de ferramentas completo.
Fornecido como está, por conveniência; sempre confirme configuração crítica com a ferramenta que vai consumi-la. OpsCanopy é gratuito e aberto.