JSON vs XML vs YAML: como escolher o formato de dados certo

Os mesmos dados, de três maneiras

Aqui está um pequeno objeto representado nos três formatos. Compará-los lado a lado é a forma mais rápida de enxergar o que cada formato realmente troca.

{
  "user": {
    "name": "Ada Lovelace",
    "roles": ["admin", "editor"],
    "active": true
  }
}

user:
  name: Ada Lovelace
  roles:
    - admin
    - editor
  active: true

<user active="true">
  <name>Ada Lovelace</name>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
</user>

Três campos, três quantidades muito diferentes de pontuação. Essa diferença é a história toda: o JSON é o mais amigável para máquinas, o YAML é o mais amigável para escrever à mão, e o XML é o mais expressivo quando o próprio documento precisa de estrutura que vai além de simples dados chave/valor.

Onde o JSON vence

O JSON é o padrão por um motivo: ele mapeia diretamente para as estruturas de dados que toda linguagem mainstream já possui (objetos/dicts e arrays/lists), então a análise converte para tipos nativos sem nenhuma ambiguidade. Ele não tem comentários, nem múltiplas formas de escrever o mesmo valor, nem sensibilidade a espaços em branco — o que parece limitador, mas é exatamente o que o torna rápido de analisar e seguro de gerar programaticamente.

Use JSON para qualquer comunicação máquina-a-máquina: payloads de APIs REST e GraphQL, dados passados entre serviços, qualquer coisa armazenada em um banco de documentos (MongoDB, o JSONB do PostgreSQL) e qualquer configuração que seja principalmente lida e escrita por código, e não editada à mão.

Onde o YAML vence

O YAML é um superconjunto estrito do modelo de dados do JSON com uma sintaxe muito mais amigável para humanos: sem colchetes de fechamento para contar, comentários com # e indentação em vez de pontuação. Isso é exatamente o que você quer para arquivos que uma pessoa edita diretamente e relê num diff — pipelines de CI (GitHub Actions, GitLab CI), manifests do Kubernetes e configuração de aplicação.

A contrapartida é que a flexibilidade do YAML também é sua maior armadilha: erros de indentação produzem silenciosamente uma estrutura diferente em vez de um erro de análise, e valores sem aspas como `no`, `yes`, `on` e datas podem ser convertidos automaticamente para booleanos ou timestamps que você não pretendia (o infame 'problema da Noruega', em que o código de país NO vira o booleano false). Coloque aspas nas strings sempre que houver qualquer ambiguidade.

Onde o XML vence

O XML parece um legado pesado ao lado do JSON, mas faz coisas que nem JSON nem YAML conseguem: atributos alongside o conteúdo do elemento, conteúdo misto (texto e elementos intercalados, como o HTML), namespaces para combinar vocabulários de fontes diferentes e validação madura por schema (XSD) mais transformação (XSLT) — ferramentas que antecedem o JSON em uma década.

É por isso que o XML persiste em domínios centrados em documentos — APIs SOAP, SVG, DOCX/XLSX (que são arquivos ZIP cheios de XML) e sistemas corporativos (bancos, saúde, governo) com pipelines validados por XSD que ninguém vai reescrever. Se seus dados são genuinamente em formato de documento (pense 'um parágrafo com um trecho em negrito no meio') em vez de registros, o XML muitas vezes ainda é a melhor escolha.

Convertendo entre formatos

Como os três descrevem o mesmo modelo de dados objeto/array/string/número/booleano/null (os atributos e o conteúdo misto do XML são a única coisa que não mapeia de forma limpa), converter entre JSON, YAML e XML costuma ser mecânico para qualquer dado em formato de registro. As ferramentas JSON to YAML, YAML to JSON, JSON to XML e XML to JSON do JSONForge fazem a conversão no navegador — útil quando você está migrando o formato de um arquivo de configuração ou precisa entregar um export em JSON para um colega que só usa YAML.