JSON vs XML: qual formato escolher em cada projeto

Toda vez que alguém novo entra num projeto legado de integração corporativa e encontra XML pela primeira vez, a reação é a mesma: "por que isso existe?" E toda vez que alguém tenta usar JSON para um documento técnico com namespaces, metadados e schema rígido, a pergunta se inverte. A escolha entre os dois não é questão de modismo — é questão de entender onde cada formato foi projetado para viver.

Se você quer entender o que é JSON antes de compará-lo com XML, o post O que é JSON cobre a especificação, os seis tipos e os erros comuns.

Por que JSON ganhou a web

JSON surgiu como simplificação do formato de objeto do JavaScript e virou padrão de fato de APIs REST por razões práticas, não teóricas.

Comparação direta com o mesmo dado:

{
  "usuario": {
    "id": 42,
    "nome": "Rafael",
    "ativo": true
  }
}

<usuario>
  <id>42</id>
  <nome>Rafael</nome>
  <ativo>true</ativo>
</usuario>

O JSON tem menos bytes. Não tem tag de fechamento redundante. O parse é direto para estrutura nativa em qualquer linguagem moderna — JSON.parse(), json.loads(), json.Unmarshal(). Sem namespace, sem DTD, sem schema obrigatório para começar a trabalhar.

Isso não quer dizer que XML é pior. Quer dizer que JSON tem menos atrito para o caso de uso mais comum: uma API passando dados entre dois sistemas que você controla.

O que XML tem que JSON não tem

XML não é só JSON mais verboso. São formatos com capacidades diferentes.

Atributos e texto misto

XML permite que um elemento tenha ao mesmo tempo atributos e conteúdo textual:

<preco moeda="BRL" tipo="varejo">149.90</preco>

Em JSON você representa isso como objeto com campos separados:

{
  "preco": {
    "valor": 149.90,
    "moeda": "BRL",
    "tipo": "varejo"
  }
}

Funcionalmente equivalente, mas a distinção entre atributo e elemento filho tem semântica real em XML — especialmente quando o documento representa um texto marcado, como HTML ou DocBook.

Namespaces

XML tem suporte nativo a namespaces. Isso importa quando dois sistemas precisam combinar vocabulários sem colisão de nomes:

<pedido xmlns:fin="http://financeiro.exemplo.com"
        xmlns:log="http://logistica.exemplo.com">
  <fin:valor>500.00</fin:valor>
  <log:peso>2.3</log:peso>
</pedido>

JSON não tem equivalente nativo. Para resolver conflitos de nome em JSON você usa prefixos convencionados ou estruturas aninhadas — funciona, mas é convenção, não especificação.

Schema com poder real

XML Schema (XSD) é extenso e, sim, verboso. Mas tem capacidades que JSON Schema ainda não replica completamente: herança de tipos, restrições baseadas em pattern com grupos nomeados, cardinalidades complexas, validação de ordem de elementos.

Para documentos técnicos em domínios regulados — saúde (HL7/FHIR antigo), financeiro (SWIFT, Open Banking legado), nota fiscal eletrônica (NF-e) — XSD é o padrão estabelecido com décadas de tooling.

XSLT: transformação declarativa

XML tem XSLT, uma linguagem de transformação que permite converter um documento XML em outro formato (outro XML, HTML, texto) de forma declarativa. Não existe equivalente no ecossistema JSON. Se você precisa transformar documentos em pipeline sem código imperativo, XML é superior.

Onde XML ainda ganha na prática

Vou ser direto: JSON ganhou a guerra das APIs REST. Mas XML ainda é a escolha certa em contextos específicos.

SOAP: O protocolo SOAP usa XML obrigatoriamente — envelope, headers, body, fault. Se você integra com um webservice SOAP (bancos, governo, ERPs legados), não tem escolha. O WSDL que descreve o serviço também é XML.

NF-e e documentos fiscais brasileiros: A SEFAZ exige XML assinado digitalmente. A estrutura do XML é parte do contrato legal — não tem opção de "prefiro JSON".

Documentos técnicos ricos: O formato DITA, DocBook, e até o OpenDocument (.odt, .docx por dentro) são XML. Faz sentido quando o dado é um documento com semântica editorial — parágrafos, seções, referências cruzadas, metadados de publicação.

Mensageria corporativa: Sistemas como IBM MQ e antigos ESB (Enterprise Service Bus) constroem pipelines em cima de XML. Mudar para JSON exigiria reescrever integrações que funcionam há 15 anos.

RSS e Atom: Feeds de conteúdo ainda usam XML. Não porque seja ideal, mas porque o padrão foi definido assim e bilhões de leitores já sabem ler.

Parsing: a diferença que você vai sentir em produção

Em JSON, o parse é uma operação: string → estrutura nativa. O resultado tem tipos — número é número, booleano é booleano, null é null.

import json
dados = json.loads('{"ativo": true, "valor": 42.5}')
print(type(dados["ativo"]))  # <class 'bool'>
print(type(dados["valor"]))  # <class 'float'>

Em XML, o parser produz uma árvore de nós (DOM) ou dispara eventos (SAX). Cada valor é uma string — você extrai e converte manualmente:

import xml.etree.ElementTree as ET
root = ET.fromstring('<item><ativo>true</ativo><valor>42.5</valor></item>')
ativo = root.find('ativo').text == 'true'   # conversão manual
valor = float(root.find('valor').text)       # conversão manual

Isso não é um defeito de XML — é consequência do design. XML foi projetado para documentos, onde todo conteúdo é texto. Para dados estruturados com tipos, JSON é mais conveniente.

A diferença de performance em parsing puro favorece JSON: estrutura mais simples, string menor, menos memória alocada. Para a maioria das APIs isso não importa — o gargalo é rede e banco, não parsing. Mas em processamento de alto volume (ETL, event streams), a diferença aparece.

O ponto que as pessoas erram: verbosidade não é o problema principal

Quando alguém reclama que XML é verboso demais, o argumento é justo — mas verbosidade é compressível. Com gzip, a diferença de tamanho entre JSON e XML cai dramaticamente. Ambos comprimem bem porque têm muita repetição.

O problema real de XML não é byte count — é complexidade de tooling. Para consumir XML corretamente você precisa entender DOM, XPath, namespaces, o comportamento do parser com entidades. Para consumir JSON você precisa de uma função de parse.

A curva de aprendizado de XML é real. E o custo de manutenção de sistemas XML complexos é real. Isso é diferente de "XML é ruim" — é "XML cobra mais de quem o usa".

Decisão prática: uma tabela sem rodeios

A regra geral: se você controla os dois lados e está começando do zero, use JSON. Se você está integrando com um sistema que já existe e usa XML, use XML e não lute contra isso.

Perguntas frequentes

JSON vai substituir XML completamente?

Não. XML tem nichos onde vai continuar por décadas — fiscal, saúde, documentação técnica, feeds. O que mudou é que JSON virou o padrão para novos projetos de API, enquanto XML ficou concentrado em domínios onde o ecossistema de tooling e os padrões regulatórios já existem.

XML com schema é mais seguro que JSON sem schema?

Depende do que você chama de seguro. XSD é mais expressivo que JSON Schema em alguns aspectos (herança, cardinalidade de elementos). Mas JSON Schema já cobre a grande maioria dos casos de validação de API e é mais simples de adotar. Usar JSON sem schema algum é mais arriscado do que usar XML com XSD — mas o formato em si não garante segurança, a disciplina de validar inputs sim.

YAML é melhor que os dois para APIs?

YAML é ótimo para arquivos de configuração que humanos editam (Docker Compose, GitHub Actions, Kubernetes manifests). Para troca de dados entre sistemas, tem problemas sérios: especificação complexa com comportamentos surpreendentes, histórico de vulnerabilidades de deserialização, sem suporte nativo em muitas linguagens sem biblioteca extra. Use YAML para config, JSON para dados.

Como JSON e XML lidam com datas?

Os dois têm a mesma resposta: elas não existem no formato. Em JSON, data é string — o padrão ISO 8601 ("2026-06-13T10:00:00Z") é convenção, não especificação. Em XML, também é string, mas XSD define o tipo xs:dateTime que os parsers reconhecem. Resultado prático: XML com XSD tem suporte melhor a data tipada; JSON sem schema trata data como string opaca até o código da aplicação interpretar.

A escolha é sobre contexto, não superioridade

JSON ganhou para APIs REST modernas porque o tradeoff é óbvio: menos atrito, menos bytes, parse direto para tipos nativos. XML ainda domina onde foi projetado para dominar: documentos ricos, protocolos estabelecidos, domínios com schema obrigatório.

A pergunta certa não é "qual é melhor?" — é "qual o contexto em que estou trabalhando?" Se você está num projeto novo com liberdade de escolha, JSON. Se você está integrando com NF-e, SOAP ou qualquer sistema legado com XML estabelecido, XML — e sem drama.

Para trabalhar com JSON no dia a dia, uso o JSON Formatter para inspecionar e validar payloads — especialmente útil quando a API retorna um blob minificado e você precisa entender a estrutura rapidamente.