Resultado da conversão de JSON para YAML no FormatArcResultado da conversão de JSON para YAML no FormatArc
Publicado: 2026-03-15Atualizado: 2026-06-02

Converter JSON para YAML — Kubernetes, Docker Compose, Ansible (Navegador e CLI)

Converta JSON para YAML para manifests do Kubernetes, Docker Compose, valores do Helm e playbooks do Ansible. Ferramenta no navegador (sem upload), yq, Python, Node.js, Go. Preserva a ordem das chaves, lida com block scalars, saída multi-documento, aspas em strings e o problema da Noruega.

TL;DR — escolha um método em 10 segundos

  • Precisa agora, sem instalar nada → FormatArc JSON para YAML (roda no navegador, sem upload, valida o JSON, preserva a ordem das chaves)
  • CLI / one-liner → yq -P '.' file.json (o padrão do DevOps, -P para block style)
  • Script Python com ordem das chaves → yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True)
  • Aplicação Node.js → js-yaml yaml.dump(data, { lineWidth: -1 })
  • Serviço em Go → gopkg.in/yaml.v3 yaml.Marshal
  • Round-trip no Kubernetes → kubectl get ... -o json | jq '...' | yq -P '.'
  • De array JSON para YAML multi-documento → yq -P '.[]' --split-exp 'true' json.array.json
Método Configuração Preserva ordem das chaves Block scalars (|) Saída multi-doc Inserção de comentários
FormatArc no navegador Nenhuma Sim Sim Não Não (você adiciona depois)
yq -P '.' brew install yq Sim Sim Sim (split-exp) Não
Python yaml.dump (PyYAML) pip install pyyaml Precisa de sort_keys=False Sim Separador --- manual Não
Python ruamel.yaml pip install ruamel.yaml Sim Sim Sim Sim (API manual)
Node js-yaml npm install js-yaml Sim Sim Manual Não
Go yaml.Marshal go get gopkg.in/yaml.v3 Sim (para yaml.Node) Sim Loop com Encoder Não

Converter JSON para YAML é estruturalmente trivial — os dois formatos representam o mesmo modelo de dados. As partes difíceis são preservar a ordem das chaves, decidir quando colocar strings entre aspas, lidar com strings de múltiplas linhas, dividir arrays JSON em YAML multi-documento e evitar o problema da Noruega na saída.

Por que converter JSON para YAML?

JSON e YAML conseguem representar as mesmas estruturas de dados — mapas, listas, strings, números, booleanos e null. Eles são funcionalmente intercambiáveis. A razão para preferir um em vez do outro geralmente se resume ao contexto e à legibilidade.

Kubernetes e orquestração de contêineres

O Kubernetes aceita tanto JSON quanto YAML para definições de recursos, mas o ecossistema usa YAML de forma esmagadora. Documentação, tutoriais, posts de blog e respostas do Stack Overflow são quase exclusivamente em YAML. Se você gera uma definição de recurso de forma programática (o que costuma produzir JSON), convertê-la para YAML a deixa consistente com todo o resto da configuração do seu cluster e mais fácil de revisar em pull requests.

O kubectl até tem um modo embutido para isso:

kubectl get deployment web-app -o yaml > deployment.yaml

Mas quando a fonte da verdade é JSON (a resposta de um webhook de admission controller, a saída do provider Kubernetes do Terraform, o resultado de reconciliação de um operator customizado), a conversão explícita é necessária.

Docker Compose e valores do Helm

Arquivos do Docker Compose são YAML por definição. Se você tem a configuração de serviços armazenada como JSON (talvez de uma API de gerenciamento de configuração ou do control plane de um service mesh), você precisa de YAML antes de poder usá-la como um arquivo Compose.

Os arquivos de valores de charts do Helm são YAML. Quando você busca valores de uma fonte externa como o Vault ou o AWS Parameter Store (que retornam JSON), converta para YAML antes de passar para helm install -f values.yaml.

Playbooks do Ansible

Playbooks e inventários do Ansible são YAML. A saída de APIs de nuvem, sistemas CMDB ou bancos de dados de ativos normalmente chega como JSON. A conversão para YAML é o primeiro passo antes de usá-la em playbooks.

Legibilidade e edição

YAML é mais amigável para humanos no caso de arquivos de configuração. Ele elimina o ruído visual de chaves, colchetes e vírgulas. Compare:

JSON:

{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "workers": 4,
    "logging": {
      "level": "info",
      "format": "json"
    }
  }
}

YAML:

server:
  host: 0.0.0.0
  port: 8080
  workers: 4
  logging:
    level: info
    format: json

A versão YAML tem menos caracteres, menos pontuação, e a estrutura hierárquica é comunicada pela indentação. Para arquivos que humanos leem e editam com frequência, isso faz diferença.

Adicionar comentários

JSON não suporta comentários. YAML suporta. Se você precisa anotar um arquivo de configuração — explicando por que um valor está definido de certa forma, documentando os valores permitidos ou deixando notas para o seu time — o YAML permite fazer isso diretamente:

server:
  host: 0.0.0.0
  port: 8080
  # Aumente os workers em produção; 4 está ok para staging
  workers: 4

Converter JSON para YAML costuma ser o primeiro passo antes de adicionar esse tipo de anotação. Os comentários em si não podem vir do JSON — JSON não tem sintaxe de comentário. Veja Como adicionar comentários ao JSON para alternativas caso você precise manter a fonte como JSON.

Quando você precisa de JSON para YAML: 4 cenários concretos

Cenário 1: API do Kubernetes para manifest no Git

A API do Kubernetes retorna JSON. Você quer commitar o deployment no seu repositório GitOps como YAML:

kubectl get deployment web-app -o json | yq -P '.' > deployment.yaml
git add deployment.yaml && git commit -m "Capture web-app current state"

Cenário 2: valores do Helm vindos do Vault

O Vault retorna segredos como JSON. O Helm espera arquivos de valores em YAML:

vault read -format=json secret/prod/app | jq '.data.data' | yq -P '.' > values.yaml
helm upgrade --install app ./chart -f values.yaml

Cenário 3: Docker Compose a partir de uma API de control plane

O control plane de um service mesh retorna definições de serviço como JSON. O Docker Compose precisa de YAML:

curl -s https://control-plane/services | jq '.' | yq -P '.' > docker-compose.yml
docker compose up -d

Cenário 4: inventário do Ansible a partir de um CMDB

A maioria dos CMDBs (Device42, ServiceNow, NetBox) retorna JSON via REST. Os inventários do Ansible são YAML:

curl -s https://cmdb/hosts | jq '.hosts' | yq -P '.' > inventory.yaml
ansible-playbook -i inventory.yaml site.yaml

Em todos os quatro cenários, a conversão é um único passo de pipeline e facilmente scriptável.

No navegador vs. conversores na nuvem: por que enviar arquivos de configuração é arriscado

Muitos conversores de JSON para YAML online afirmam fazer "processamento client-side", mas na verdade dão POST dos seus dados para o servidor deles. Para arquivos de configuração isso é perigoso, porque configs costumam conter:

  • Tokens de API e credenciais em blocos secret:
  • Strings de conexão de banco de dados com senhas
  • Chaves de acesso de provedores de nuvem (IAM roles, JSON de service account)
  • Hostnames internos e o layout da infraestrutura
  • Chaves de criptografia e certificados TLS

Mesmo que o serviço afirme não registrar uploads, uma única configuração incorreta do lado deles vaza os seus segredos. A abordagem segura é a conversão no navegador, que de fato nunca envia dados a um servidor.

Isso não é hipotético. Em novembro de 2025, a empresa de segurança watchTowr relatou que o JSONFormatter e o CodeBeautify — dois dos sites de formatação e conversão online mais populares — tinham anos de envios salvos de usuários navegáveis publicamente pelo recurso "Recent Links" deles. Os pesquisadores coletaram mais de 80.000 entradas (mais de 5GB), incluindo credenciais do Active Directory, chaves de acesso de banco de dados e de nuvem, chaves privadas, segredos de CI/CD, tokens JWT e de API, credenciais de gateways de pagamento e exports completos do AWS Secrets Manager, afetando organizações de governo, bancos, saúde e setor aeroespacial (divulgação da watchTowr). Qualquer coisa que você cole em um conversor que armazena ou transmite a sua entrada pode ser exposta da mesma forma.

Para verificar: abra o conversor, abra o DevTools, vá em Network, desabilite a rede e cole o seu JSON. Se a ferramenta continuar funcionando, ela é client-side. Se travar ou der erro, ela é baseada em nuvem.

A ferramenta FormatArc JSON para YAML continua funcionando com a rede desabilitada. O yq local também. E qualquer script Python / Node / Go no seu laptop também.

Para Secrets do Kubernetes, valores do Helm contendo tokens de API ou qualquer config com credenciais, use sempre um conversor local.

Para um método completo de verificar se um conversor online é seguro antes de colar, veja Conversores de JSON online são seguros?.

Método 1: ferramenta FormatArc no navegador (sem upload)

A ferramenta JSON para YAML converte o seu JSON em YAML formatado corretamente em segundos, inteiramente no seu navegador.

  1. Abra o conversor JSON para YAML.
  2. Cole o seu JSON no painel da esquerda.
  3. Clique em Convert.

Resultado da conversão de JSON para YAMLResultado da conversão de JSON para YAML

A ferramenta valida o seu JSON antes de converter, então se houver um erro de sintaxe — uma vírgula faltando, uma chave sobrando, chaves sem aspas — ela informa o problema com o número da linha. Isso a torna útil como validador de JSON mesmo quando você não precisa da saída em YAML. Veja Solução de problemas de parse error em JSON para problemas comuns de sintaxe JSON.

Como a conversão roda no seu navegador, você pode colar credenciais, configurações internas ou qualquer outro dado sensível com segurança, sem que isso seja transmitido para lugar nenhum.

A saída usa indentação de 2 espaços (o padrão do Kubernetes), preserva a ordem das chaves do JSON de entrada e usa block style por padrão (então fica com a aparência de YAML normal, e não flow style com chaves).

Método 2: yq (o padrão do DevOps)

O yq lida com a conversão de JSON para YAML com a mesma elegância que faz no sentido inverso:

# Conversão básica
yq -P '.' input.json > output.yaml

# Pipe a partir do stdin
cat config.json | yq -P '.' > output.yaml

# Pretty (block style); sem -P, a saída pode usar flow style
yq -P '.' input.json

# Define a indentação (padrão 2)
yq -P -I=4 '.' input.json

# Extrai uma sub-árvore e converte
yq -P '.spec.template' deployment.json

# Saída multi-documento a partir de um array JSON
yq -P '.[]' --split-exp 'true' kubernetes-list.json

A flag -P é a forma curta de --prettyPrint, que força o block style do YAML. Sem ela, o yq pode gerar flow style (que se parece com JSON com menos aspas) para estruturas aninhadas.

Instalação:

# macOS
brew install yq

# Linux (binário)
sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
sudo chmod +x /usr/local/bin/yq

# Docker
docker run --rm -i mikefarah/yq -P '.' < input.json > output.yaml

yq com jq para filtrar durante a conversão

# Extrai apenas spec.template de um deployment e converte para YAML
jq '.spec.template' deployment.json | yq -P '.'

# Ou faz tudo no yq
yq -P '.spec.template' deployment.json

Método 3: Python (yaml.dump e ruamel.yaml)

Uso básico do PyYAML

import json
import yaml

with open("config.json") as f:
    data = json.load(f)

with open("config.yaml", "w") as f:
    yaml.dump(
        data,
        f,
        default_flow_style=False,   # block style (a aparência usual do YAML)
        allow_unicode=True,          # não escapa caracteres Unicode
        sort_keys=False,             # preserva a ordem original das chaves
    )

As três opções que importam:

  • default_flow_style=False — produz YAML normal, e não a forma compacta {a: 1, b: 2}
  • allow_unicode=True — mantém japonês, latim acentuado e emoji como estão, em vez de escapes \uXXXX
  • sort_keys=False — preserva a ordem da entrada JSON (essencial no Kubernetes, onde apiVersion precisa vir antes de kind)

One-liner

python3 -c 'import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False, allow_unicode=True, sort_keys=False)' < input.json > output.yaml

ruamel.yaml para round-trip com comentários

Se você precisa adicionar comentários ao YAML gerado ou preservar uma formatação específica:

from ruamel.yaml import YAML
import json

yaml_writer = YAML()
yaml_writer.default_flow_style = False
yaml_writer.preserve_quotes = True
yaml_writer.indent(mapping=2, sequence=4, offset=2)

with open("config.json") as fin:
    data = json.load(fin)

# Adiciona comentários de forma programática
data.yaml_set_comment_before_after_key("server", before="Web server configuration")

with open("config.yaml", "w") as fout:
    yaml_writer.dump(data, fout)

O ruamel.yaml é a escolha certa quando comentários importam — JSON não tem comentários, então qualquer anotação precisa ser adicionada durante ou depois da conversão.

Método 4: Node.js (js-yaml)

const fs = require("fs");
const yaml = require("js-yaml");

const data = JSON.parse(fs.readFileSync("config.json", "utf8"));
const ymlText = yaml.dump(data, {
  lineWidth: -1,    // nunca quebra linhas longas
  noRefs: true,     // não emite anchors / aliases do YAML
  sortKeys: false,  // preserva a ordem da entrada
  quotingType: '"', // prefere aspas duplas quando for preciso usar aspas
});

fs.writeFileSync("config.yaml", ymlText);

lineWidth: -1 impede que o js-yaml quebre linhas longas, o que pode causar quebras de linha inesperadas em URLs e outros valores extensos. noRefs: true desabilita a geração de anchors — útil quando o consumidor é o kubectl ou outra ferramenta que não suporta anchors do YAML.

Método 5: Go (gopkg.in/yaml.v3)

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    data, _ := os.ReadFile("config.json")
    var obj interface{}
    json.Unmarshal(data, &obj)
    out, _ := yaml.Marshal(obj)
    fmt.Print(string(out))
}

Para preservar a ordem das chaves em Go, use yaml.Node diretamente em vez de interface{} — fazer json.Unmarshal em um map[string]interface{} não preserva a ordem (os maps de Go são intencionalmente randomizados). Para manifests do Kubernetes onde a ordem importa, isso é um problema:

// Use yaml.Node para ordenação explícita
var node yaml.Node
yaml.Unmarshal(data, &node)
out, _ := yaml.Marshal(&node)

Como alternativa, como o encoding/json do Go ordena as chaves de mapas em ordem alfabética, use uma biblioteca de terceiros como github.com/iancoleman/orderedmap para preservar a ordem de inserção.

Exemplo de Deployment do Kubernetes: round-trip de JSON para YAML

Um exemplo completo e do mundo real. Comece com uma definição de deployment em JSON:

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "web-app",
    "labels": { "app": "web", "tier": "frontend" }
  },
  "spec": {
    "replicas": 3,
    "selector": { "matchLabels": { "app": "web" } },
    "template": {
      "metadata": { "labels": { "app": "web" } },
      "spec": {
        "containers": [{
          "name": "nginx",
          "image": "nginx:1.25",
          "ports": [{ "containerPort": 80 }],
          "env": [
            { "name": "LOG_LEVEL", "value": "info" }
          ]
        }]
      }
    }
  }
}

Converta com o yq:

yq -P '.' deployment.json

Saída:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          env:
            - name: LOG_LEVEL
              value: info

Note que apiVersion permanece antes de kind, antes de metadata — a ordem das chaves é preservada. Com o PyYAML e sort_keys=True (o padrão), a saída ficaria em ordem alfabética e o kubectl apply ainda funcionaria, mas o diff em relação ao exemplo upstream do Kubernetes fica mais difícil de revisar.

Aplique: kubectl apply -f deployment.yaml.

Aspas em strings no YAML: quando "8080" vira 8080

O YAML tem regras complexas sobre quando strings precisam de aspas. Os conversores de JSON para YAML aplicam essas regras na saída, o que pode causar mudanças de tipo inesperadas.

Números como strings perdem as aspas

Se o seu JSON tem "8080" como string (porque a API retornou assim), os conversores podem remover as aspas no YAML, transformando-o em número:

JSON:

{ "port": "8080" }

Depois da conversão (algumas ferramentas):

port: "8080"   # bom: preservado como string

Ou:

port: 8080     # ruim: virou número

O yq v4 preserva o tipo original (string continua string). O PyYAML com as configurações padrão também preserva. O js-yaml preserva. O risco é maior com código de conversão escrito à mão que usa heurísticas.

Para forçar as aspas no PyYAML, envolva os valores:

class QuotedString(str): pass

def represent_quoted(dumper, data):
    return dumper.represent_scalar("tag:yaml.org,2002:str", str(data), style='"')

yaml.add_representer(QuotedString, represent_quoted)

Strings que parecem booleanos

{ "active": "yes" }

Depois da conversão (com o schema do YAML 1.1):

active: yes    # interpretado como booleano true no próximo round trip

Um bom conversor coloca essas strings entre aspas:

active: "yes"

Se você controla a fonte JSON, prefira true / false / null (os tipos nativos do JSON) a strings como "yes" / "no" — isso elimina por completo o problema da Noruega.

Strings que começam com caracteres especiais

Os caracteres especiais do YAML (*, &, !, {, [, >, |, #, @, \``, -` inicial) precisam de aspas quando iniciam um valor:

{ "tag": "*production*" }

Vira:

tag: "*production*"   # entre aspas por causa do * inicial

Todos os conversores principais lidam com isso corretamente. O risco só aparece com conversores feitos à mão.

Block scalars: | vs > para strings de múltiplas linhas

O JSON representa strings de múltiplas linhas com sequências de escape \n. Quando convertidas para YAML, um bom conversor usa a notação de block scalar:

JSON:

{
  "description": "Line one\nLine two\nLine three"
}

Um conversor tem três escolhas razoáveis em YAML:

Bloco literal (|) — preserva as quebras de linha exatamente

description: |
  Line one
  Line two
  Line three

Cada quebra de linha na fonte vira uma quebra de linha na string de saída. É isso que você quer para mensagens de log, blocos PEM de certificados e trechos de código embutidos na config.

Bloco dobrado (>) — junta linhas com espaços

description: >
  Line one
  Line two
  Line three

Isso produz a string Line one Line two Line three (quebras de linha viram espaços, linhas em branco viram uma única quebra de linha). Bom para textos longos que devem ser exibidos como um parágrafo.

Linha única entre aspas

description: "Line one\nLine two\nLine three"

A sequência de escape literal \n dentro de uma string entre aspas duplas. Funciona, mas é difícil de ler com mais de 2 ou 3 linhas.

O yq -P usa | (literal) por padrão para qualquer string que contenha quebras de linha. O PyYAML usa | quando default_style=None (o padrão) e a string tem uma quebra de linha. O js-yaml usa | por padrão para strings com quebra de linha.

Para forçar um estilo específico no PyYAML:

yaml.dump(data, default_style='|')   # todas as strings como blocos literais
yaml.dump(data, default_style='"')   # todas as strings entre aspas duplas

Para ConfigMaps do Kubernetes contendo scripts de múltiplas linhas ou certificados PEM, | é a escolha certa e é o que o kubectl create configmap --from-file produz.

Ordenação das chaves: preservando apiVersion antes de kind antes de metadata

Objetos JSON e mappings YAML são ambos tecnicamente não ordenados, segundo a spec. Na prática, todo mundo espera as chaves em uma ordem significativa — especialmente recursos do Kubernetes, onde a convenção coloca apiVersion primeiro, depois kind, depois metadata, depois spec.

A maioria dos conversores preserva a ordem da fonte:

  • yq (Go yaml.v3): preserva a ordem internamente via yaml.Node
  • PyYAML com sort_keys=False: preserva a ordem (o padrão é sort_keys=True, que ordena em ordem alfabética — defina explicitamente)
  • js-yaml com sortKeys: false: preserva a ordem
  • ruamel.yaml: preserva a ordem por padrão

Fique atento a:

  • O padrão sort_keys=True do PyYAML — ordena tudo em ordem alfabética, colocando apiVersion depois de kind e quebrando a convenção
  • O unmarshalling de interface{} em Go — randomiza a ordem (use yaml.Node no lugar)
  • Conversores feitos à mão que constroem um map[string]string e o emitem — os maps de Go são intencionalmente aleatórios

Se você commita YAML no Git, a randomização das chaves causa muito ruído no diff mesmo quando os dados não mudaram. Sempre verifique se o seu conversor preserva a ordem antes de adotá-lo em fluxos de GitOps.

De array JSON para YAML multi-documento

Um padrão comum: você tem um array JSON de recursos do Kubernetes e quer um único arquivo YAML com vários documentos separados por --- (um por recurso).

Com yq

yq -P '.[]' --split-exp 'true' kubernetes-list.json

Isso gera:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: v1
kind: Service
metadata:
  name: app-service

Salve em um arquivo: yq -P '.[]' --split-exp 'true' kubernetes-list.json > resources.yaml. O arquivo agora está pronto para kubectl apply -f resources.yaml.

Com Python

import json
import yaml

with open("list.json") as f:
    items = json.load(f)["items"]   # ajuste o caminho para o seu array

with open("resources.yaml", "w") as f:
    yaml.dump_all(
        items,
        f,
        default_flow_style=False,
        allow_unicode=True,
        sort_keys=False,
    )

O yaml.dump_all emite vários documentos separados por ---.

Com Node.js

const yaml = require("js-yaml");
const fs = require("fs");

const items = JSON.parse(fs.readFileSync("list.json", "utf8")).items;
const ymlText = items.map(item => yaml.dump(item, { lineWidth: -1 })).join("---\n");

fs.writeFileSync("resources.yaml", ymlText);

Junção manual com ---\n, já que o js-yaml não tem um dumpAll embutido.

Integração com pipeline de CI/CD

GitHub Actions

name: Convert JSON config to YAML for deployment
on:
  push:
    paths: ["config/*.json"]

jobs:
  convert:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install yq
        run: |
          sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
          sudo chmod +x /usr/local/bin/yq
      - name: Convert all configs
        run: |
          for f in config/*.json; do
            yq -P '.' "$f" > "${f%.json}.yaml"
          done
      - name: Validate against Kubernetes
        run: |
          for f in config/*.yaml; do
            kubectl apply --dry-run=client -f "$f"
          done
      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "Auto-convert configs to YAML"

GitLab CI

generate-yaml:
  image: mikefarah/yq:latest
  stage: build
  script:
    - for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done
  artifacts:
    paths:
      - config/*.yaml

Jenkins (declarativo)

pipeline {
  agent any
  stages {
    stage('Convert configs') {
      steps {
        sh 'for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done'
      }
    }
    stage('Validate') {
      steps {
        sh 'for f in config/*.yaml; do kubectl apply --dry-run=client -f "$f"; done'
      }
    }
  }
}

O pipeline completo (converter + validar) adiciona menos de 5 segundos a execuções típicas de CI.

Um fluxo de trabalho prático para Kubernetes

Aqui está o cenário do mundo real mais comum. Você usa o kubectl para obter um recurso como JSON, modifica, salva como YAML e commita no Git:

# Obtém o deployment atual como JSON
kubectl get deployment web-app -o json > deployment.json

# Edita (ou usa jq para mudanças automatizadas)
jq '.spec.replicas = 5' deployment.json > updated.json

# Converte para YAML para o seu repositório Git
yq -P '.' updated.json > deployment.yaml

# Inspeciona, commita, faz push
git diff deployment.yaml
git add deployment.yaml && git commit -m "Scale web-app to 5 replicas"

Ou em um único pipeline:

kubectl get deployment web-app -o json | jq '.spec.replicas = 5' | yq -P '.' > deployment.yaml

Para modificações rápidas em que você não precisa de scripting, cole o JSON na ferramenta JSON para YAML, copie a saída em YAML e salve no seu arquivo.

Perguntas frequentes

Por que a porta 8080 vira string na minha saída YAML?

Não vira — o YAML trata números sem aspas como números. O que às vezes acontece é o contrário: uma string JSON "8080" é emitida como um 8080 sem aspas no YAML, virando número no próximo round trip. Para preservar o tipo string, garanta que o seu conversor coloque entre aspas os valores ambíguos. O yq v4 e o PyYAML moderno lidam com isso corretamente.

Posso preservar comentários YAML em um round trip?

Não. JSON não tem comentários. Se você converte JSON para YAML e adiciona comentários, esses comentários se perdem no momento em que você converte de volta para JSON. Mantenha o YAML como fonte da verdade se os comentários importam, e use as alternativas de comentários em JSON no lado do JSON.

Por que o PyYAML ordena minhas chaves em ordem alfabética?

O yaml.dump do PyYAML usa sort_keys=True por padrão. Defina sort_keys=False para preservar a ordem da entrada. Isso importa para recursos do Kubernetes, onde a convenção coloca apiVersion primeiro.

Posso converter values.json do Helm para values.yaml?

Sim. A estrutura dos valores é idêntica, só o formato difere. Use yq -P '.' values.json > values.yaml. Verifique o resultado com helm template ./chart -f values.yaml > rendered.yaml para confirmar que os manifests batem.

Por que meu null em YAML aparece como ~?

O YAML tem várias representações para null: null, Null, NULL, ~ ou simplesmente um valor vazio. Conversores diferentes escolhem representações diferentes. O yq usa null, o PyYAML usa nada por padrão (vazio), o js-yaml usa null. Todas são equivalentes — apenas cosméticas. Para forçar uma representação específica:

yaml.add_representer(type(None), lambda d, _: d.represent_scalar("tag:yaml.org,2002:null", "null"))

Os anchors do JSON são preservados na saída YAML?

JSON não tem anchors. Se você quer usar anchors do YAML (&anchor / *alias) na saída, precisa adicioná-los manualmente depois da conversão ou usar um editor que entenda YAML. O ruamel.yaml suporta a criação programática de anchors caso você precise automatizar isso.

Como converto JSON para YAML sem acesso à internet?

Três opções locais: instale o yq (binário em Go, arquivo único, sem dependências), use um script Python com pyyaml ou use um script Node.js com js-yaml. A ferramenta FormatArc JSON para YAML também funciona offline depois que a página carrega — a conversão no navegador significa que nenhum acesso de rede adicional é necessário.

Indo no sentido oposto

Para converter YAML de volta para JSON — para envio a uma API, depuração ou alimentar ferramentas que só aceitam JSON — veja Como converter YAML para JSON. A ferramenta YAML para JSON do FormatArc lida com o sentido inverso com a mesma facilidade.

Guias relacionados

Resumo

Converter JSON para YAML aparece o tempo todo em fluxos de DevOps, infraestrutura como código e gerenciamento de configuração. Cinco métodos cobrem todas as situações:

  • Sem instalação, dados sensíveis: FormatArc JSON para YAML — roda no navegador, preserva a ordem das chaves, erros de JSON com número de linha.
  • CLI / pipelines: yq -P '.' — o padrão do DevOps, suporta filtragem e saída multi-documento.
  • Aplicações Python: yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True).
  • Aplicações Node.js: js-yaml yaml.dump com lineWidth: -1 e sortKeys: false.
  • Serviços em Go: gopkg.in/yaml.v3 Marshal, usando yaml.Node para preservar a ordem.

As quatro preocupações críticas em produção: preserve a ordem das chaves (essencial para o Kubernetes), lide com strings de múltiplas linhas usando block scalars (|), divida arrays JSON em YAML multi-documento quando o consumidor esperar isso, e fique atento a strings sem aspas que parecem booleanos ou números, disparando o problema da Noruega no próximo round trip.