JSON vs XML — Qual usar?

Se você já integrou com alguma API corporativa antiga ou trabalhou com feeds RSS, já conheceu o XML. Se você construiu qualquer coisa na web moderna, você vive em JSON. Os dois formatos resolvem o mesmo problema central — representar dados estruturados como texto — mas de maneiras bem diferentes. Este artigo destrincha as diferenças reais para você fazer uma escolha informada.

Os mesmos dados, dois formatos

Vamos começar com um exemplo concreto. Aqui está um objeto de usuário representado em JSON:

{
  "user": {
    "id": 101,
    "name": "Bob",
    "email": "[email protected]",
    "roles": ["admin", "editor"],
    "active": true
  }
}

E aqui estão exatamente os mesmos dados em XML:

<?xml version="1.0" encoding="UTF-8"?>
<user>
  <id>101</id>
  <name>Bob</name>
  <email>[email protected]</email>
  <roles>
    <role>admin</role>
    <role>editor</role>
  </roles>
  <active>true</active>
</user>

A versão JSON tem 62 caracteres. A versão XML tem 198 caracteres — 3× maior para os mesmos dados. Para um payload pequeno, isso não importa. Para uma API de alto tráfego atendendo milhões de requisições por dia, a banda vai somando rápido.

Onde o JSON vence

• Concisão. Sem tags de fechamento. Menos repetição. Payloads menores na rede.
• Suporte nativo no JavaScript. JSON.parse() e JSON.stringify() estão embutidos em todo runtime JS. Sem biblioteca externa.
• Simplicidade. Seis tipos de dados e um punhado de regras. Você consegue ler a spec do JSON inteira em 10 minutos.
• Suporte a arrays. JSON tem arrays nativos. Em XML, você fica preso repetindo elementos como <role> <role> <role>.
• Tooling. Bancos modernos como PostgreSQL, MongoDB e MySQL têm suporte de primeira classe a JSON. A maioria das plataformas de log faz parse de JSON nativamente.
• Legibilidade. Devs acham JSON mais fácil de escanear. Menos ruído de colchetes angulares e tags de fechamento.

Onde o XML ainda vence

• Atributos e metadados. Elementos XML podem carregar atributos: <user id="101" active="true">. Útil quando você precisa anotar dados sem adicionar elementos filhos.
• Namespaces. Namespaces XML permitem misturar vocabulários num mesmo documento — essencial em formatos como XHTML, SVG, SOAP e Office Open XML.
• Validação com Schema. XML Schema (XSD) oferece validação poderosa e padronizada incluindo tipos de dados, padrões e cardinalidade. O JSON Schema está evoluindo, mas XML Schema tem décadas de tooling.
• Casos de uso centrados em documentos. XML foi projetado para documentos, não só dados. Formatos como XHTML, DocBook e DITA são construídos sobre XML e funcionam lindamente para conteúdo com texto e marcação misturados.
• Transformações XSLT. Você pode transformar XML em HTML, outro XML ou texto simples usando XSLT — uma ferramenta poderosa para pipelines de publicação.
• Comentários. XML suporta comentários. JSON não. Para arquivos de config onde você quer explicar por que uma configuração existe, isso importa.

Performance: isso realmente importa?

Para a maioria das aplicações, a diferença de performance de parse entre JSON e XML é irrelevante. Onde importa — feeds de dados de alta frequência, telemetria IoT, sistemas em tempo real — o JSON vence com folga. Parsers JSON são mais simples e rápidos porque o próprio formato é mais simples. Um benchmark rápido: fazer parse de um arquivo JSON de 1MB no Node.js normalmente leva 10–30ms. O XML equivalente, usando um parser SAX, costuma ser 2–5× mais lento, e um parser DOM é pior ainda.

Se a performance é realmente crítica, nenhum dos dois formatos é ideal — você buscaria um formato binário como Protocol Buffers ou MessagePack. Mas para o trabalho típico de API web, a performance do JSON é mais que suficiente.

Guia de decisão: quando usar cada um

Use JSON quando:

• Construir APIs REST ou GraphQL
• Armazenar configuração ou settings (package.json, tsconfig.json, etc.)
• Trabalhar com JavaScript, TypeScript, Python, Ruby, Go — qualquer linguagem moderna
• Consumir qualquer API moderna de terceiros
• Armazenar documentos no MongoDB, Elasticsearch ou colunas JSONB do PostgreSQL

Use XML quando:

• Integrar com sistemas legados corporativos (SAP, APIs SOAP do Salesforce, etc.)
• Trabalhar com formatos de documentos: SVG, EPUB, Office Open XML (.docx, .xlsx)
• Pipelines de publicação que usam transformações XSLT
• Feeds RSS / Atom
• Trocar dados em setores com padrões XML estabelecidos (HL7 na saúde, FpML em finanças, etc.)

Trabalhando com os dois formatos

Às vezes você vai precisar converter entre os dois. Talvez você esteja consumindo uma API XML legada e queira guardar os dados como JSON, ou precise enviar dados para um serviço XML a partir de um backend JSON nativo. Você pode usar o conversor de XML para JSON ou o conversor de JSON para XML para lidar com essas transformações. Para inspecionar respostas XML, o XML Formatter e o XML Validator são bem úteis.

Considerações finais

JSON e XML resolvem o mesmo problema mas atendem contextos diferentes. JSON é a escolha certa para a grande maioria do desenvolvimento moderno — é mais simples, mais leve e tem melhor suporte nativo em todas as linguagens. XML tem pontos fortes genuinamente únicos em casos de uso centrados em documentos e que precisam de namespaces. A boa notícia é que você não precisa ser dogmático — os dois formatos são maduros, bem suportados e vão coexistir por muito tempo. Conheça os tradeoffs e escolha a ferramenta certa para o trabalho.