Por Que Existem Três Formatos
Todos os três — JSON, XML e YAML — resolvem o mesmo problema fundamental: representar dados estruturados em texto, de forma que sistemas diferentes possam trocá-los e que humanos possam, em algum grau, lê-los. A diferença está nas prioridades de design de cada um. XML nasceu priorizando rigor, validação e marcação de documentos. JSON nasceu priorizando simplicidade e afinidade com JavaScript. YAML nasceu priorizando legibilidade humana para configuração. Entender essas prioridades é o que permite escolher certo.
JSON — O Padrão da Web
JSON (JavaScript Object Notation) é hoje o formato dominante para APIs web e troca de dados entre serviços. Sua estrutura é minimalista: objetos com pares chave-valor entre chaves, arrays entre colchetes, e quatro tipos primitivos (string, número, booleano, null). Essa simplicidade tem consequências práticas: é leve, rápido de fazer parse, suportado nativamente por praticamente toda linguagem moderna, e mapeia diretamente para estruturas de dados de código.
Onde JSON brilha: APIs REST, comunicação entre frontend e backend, feeds de dados, armazenamento de documentos (NoSQL). Onde ele incomoda: não suporta comentários, é verboso em configurações longas por causa das aspas e chaves, e não tem validação de schema embutida (embora JSON Schema exista como camada opcional).
Pontos fortes do JSON
- Leve e rápido de processar.
- Suporte universal e nativo nas linguagens.
- Mapeamento direto para objetos e arrays de código.
- Ideal para APIs e troca de dados máquina-a-máquina.
XML — Rigor e Documentos
XML (eXtensible Markup Language) é o mais antigo e o mais rigoroso dos três. Usa tags de abertura e fechamento, como HTML, e permite atributos dentro das tags. Essa estrutura é mais verbosa, mas oferece recursos que os outros não têm de forma nativa: namespaces (para evitar conflito de nomes entre vocabulários diferentes), validação rigorosa via XSD ou DTD, e ferramentas maduras de transformação (XSLT) e consulta (XPath).
Onde XML brilha: documentos complexos com estrutura mista de texto e marcação, sistemas corporativos legados, padrões do setor (SOAP, muitos protocolos bancários e governamentais), e cenários onde a validação estrita do formato é requisito contratual. Onde ele incomoda: é verboso, mais lento de processar, e exagerado para troca simples de dados — onde JSON faz o mesmo trabalho com metade do texto.
YAML — Configuração Legível
YAML (YAML Ain't Markup Language) prioriza a legibilidade humana acima de tudo. Em vez de chaves e colchetes, usa indentação para representar a hierarquia — como o Python faz com código. O resultado é um formato limpo, com pouca pontuação, que suporta comentários e é confortável de editar à mão. É por isso que dominou o mundo de configuração e infraestrutura: Docker Compose, Kubernetes, pipelines de CI/CD e arquivos de configuração de aplicações usam YAML extensivamente.
Onde YAML brilha: arquivos de configuração editados por humanos, infraestrutura como código, definições de pipeline. Onde ele incomoda: a dependência de indentação o torna frágil — um espaço errado quebra o arquivo de forma sutil e difícil de depurar. Além disso, tem armadilhas conhecidas, como valores que são interpretados de forma inesperada (o clássico caso de "no" ou "yes" virando booleano, ou de números com zero à esquerda).
Comparativo Direto: Quando Usar Cada Um
- API web ou troca de dados entre serviços: JSON. É o padrão de fato, leve e universal.
- Arquivo de configuração editado por pessoas: YAML. Legível, com comentários e pouca pontuação.
- Documento com estrutura complexa, validação estrita ou padrão corporativo: XML. Namespaces e schema rigoroso justificam a verbosidade.
- Integração com sistema legado ou governamental: frequentemente XML, por exigência do outro lado.
- Armazenamento de documentos NoSQL: JSON, pelo mapeamento direto.
A regra mental simples: JSON para máquinas conversarem entre si, YAML para humanos configurarem máquinas, XML quando o rigor ou o legado exigem.
Convertendo e Validando na Prática
Na vida real, você vai cruzar os três formatos — receber um XML de um sistema legado, configurar um pipeline em YAML, e expor uma API em JSON. Saber ler e validar cada um é parte do trabalho. Como JSON é o mais comum no dia a dia de integrações web, ter um bom formatador à mão acelera o debug: use o Formatador de JSON para indentar, validar e inspecionar a estrutura de qualquer payload JSON, identificando erros de sintaxe que travam integrações antes que eles cheguem à produção.
O Mesmo Dado nos Três Formatos
Nada ilustra melhor as diferenças do que ver o mesmo dado representado nos três formatos. Imagine um registro simples de produto, com nome, preço e duas categorias.
Em JSON, ele seria conciso, com chaves entre aspas, valores tipados e arrays entre colchetes — compacto e direto para uma API consumir. Em XML, o mesmo produto viraria uma árvore de tags de abertura e fechamento (<produto>, <nome>, <categorias>), mais verboso, porém com a vantagem de permitir atributos, namespaces e validação por schema. Em YAML, o produto seria expresso por indentação, sem chaves nem aspas na maioria dos casos, com as categorias listadas por hífens — a versão mais enxuta visualmente e a mais confortável de editar à mão.
A contagem de caracteres conta a história: para o mesmo conteúdo, o YAML costuma ser o mais curto, o JSON fica no meio, e o XML é o mais longo por causa das tags de fechamento. Mas comprimento não é tudo. O XML carrega capacidade de validação que os outros não têm nativamente; o JSON oferece o parsing mais rápido e universal; o YAML entrega a melhor experiência de edição humana. Cada formato paga um preço diferente pela sua vantagem principal.
Conversão Entre Formatos no Dia a Dia
É comum precisar converter dados de um formato para outro: receber uma configuração em YAML e precisar dela como JSON para uma API, ou exportar um XML legado para um formato mais leve. Conceitualmente, a conversão é viável porque os três representam a mesma estrutura subjacente — objetos, listas e valores. Na prática, há perdas a considerar: comentários do YAML não têm equivalente em JSON e se perdem na conversão; atributos e namespaces do XML não mapeiam de forma limpa para JSON; e a tipagem automática do YAML pode introduzir ambiguidades. Por isso, ao converter, sempre valide o resultado no formato de destino antes de confiar nele em produção — uma conversão que parece correta pode ter alterado sutilmente um booleano ou perdido um metadado importante.
Perguntas Frequentes
JSON pode ter comentários?
Não, pelo menos não na especificação oficial. JSON não suporta comentários por design — qualquer comentário torna o arquivo inválido para parsers que seguem o padrão. Isso é uma limitação real em arquivos de configuração, e é uma das razões pelas quais YAML é preferido para configs editadas por humanos. Algumas ferramentas aceitam variantes não oficiais como JSON5 ou JSONC (JSON with Comments), mas não conte com suporte universal a elas.
YAML é mais perigoso que JSON?
YAML tem mais armadilhas. A dependência de indentação significa que um espaço a mais ou a menos quebra a estrutura de forma sutil. Além disso, a interpretação automática de tipos pode surpreender — valores não citados como "no", "yes", "on" ou números com zero à esquerda podem ser convertidos de forma inesperada. Por isso, em YAML, vale citar strings ambíguas e validar o arquivo após editar. JSON é mais rígido e previsível, o que reduz essa classe de erro.
XML está obsoleto?
Não, está em nicho. Para APIs web modernas, JSON o substituiu quase completamente por ser mais leve. Mas XML continua firme onde seus pontos fortes importam: documentos com marcação complexa, sistemas corporativos e bancários, protocolos como SOAP, integrações governamentais e qualquer cenário que exija validação rigorosa via schema (XSD) e namespaces. Se você trabalha com sistemas legados ou setores regulados, vai continuar encontrando XML por muitos anos.
