JSON vs XML: Which Data Format Should You Use?

Uma Rápida Aula de História

XML (eXtensible Markup Language) nasceu em 1998, quando applets Java e serviços web SOAP eram tecnologia de ponta. Foi projetado como um subconjunto simplificado do SGML — a meta-linguagem por trás do HTML — e cumpriu bem sua função. Durante anos, XML foi o padrão para intercâmbio de dados, configuração, armazenamento de documentos e praticamente tudo mais.

Então, no início dos anos 2000, os desenvolvedores web começaram a construir aplicações AJAX e perceberam que precisavam de algo mais leve que XML para passar dados entre navegadores e servidores. Douglas Crockford formalizou o JSON por volta de 2001-2002, e a mudança foi rápida. Em 2010, a maioria das novas APIs REST estava usando JSON. Em 2015, isso já não era mais uma discussão.

Mas aqui está a questão que as pessoas erram: XML não "perdeu". Ele recuou para os domínios onde realmente se destaca. Compreender esses domínios é o que separa uma decisão arquitetônica reflexiva de uma adesão a modismos.

Comparação de Sintaxe

Vamos olhar para os mesmos dados — uma lista de livros — representados em ambos os formatos:

JSON

{
  "library": {
    "books": [
      {
        "isbn": "978-0-13-468599-1",
        "title": "The Pragmatic Programmer",
        "author": "David Thomas, Andrew Hunt",
        "year": 2019,
        "available": true,
        "tags": ["programming", "best-practices", "career"]
      },
      {
        "isbn": "978-0-596-51774-8",
        "title": "JavaScript: The Good Parts",
        "author": "Douglas Crockford",
        "year": 2008,
        "available": false,
        "tags": ["javascript", "programming"]
      }
    ]
  }
}

XML

<?xml version="1.0" encoding="UTF-8"?>
<library>
  <books>
    <book isbn="978-0-13-468599-1" available="true">
      <title>The Pragmatic Programmer</title>
      <author>David Thomas, Andrew Hunt</author>
      <year>2019</year>
      <tags>
        <tag>programming</tag>
        <tag>best-practices</tag>
        <tag>career</tag>
      </tags>
    </book>
    <book isbn="978-0-596-51774-8" available="false">
      <title>JavaScript: The Good Parts</title>
      <author>Douglas Crockford</author>
      <year>2008</year>
      <tags>
        <tag>javascript</tag>
        <tag>programming</tag>
      </tags>
    </book>
  </books>
</library>

A versão XML é cerca de 40% maior, e isso é típico. Cada nome de elemento aparece duas vezes (tags de abertura e fechamento), e arrays requerem elementos de wrapper. XML também tem o conceito de "atributos" vs "elementos" — note como isbn e available são atributos na tag <book>, enquanto outros campos são elementos filhos. Essa flexibilidade é tanto uma característica quanto uma fonte de debates intermináveis sobre design.

JSON, em contraste, tem uma única maneira de fazer as coisas: chaves e valores. Sem distinção entre atributos e elementos. Sem tags de fechamento. Menos cerimônia, menos ambiguidade.

Experimente você mesmo: Cole JSON em nosso conversor de JSON para XML para ver o equivalente em XML instantaneamente. Ou converta na outra direção com XML para JSON.

Comparação de Recursos

Recurso	JSON	XML
Verbosidade	Compacto	Verboso (tags de abertura + fechamento)
Legibilidade	Bom para estruturas de dados	Bom para documentos
Comentários	❌ Não	✅ Sim (<!-- comentário -->)
Validação de esquema	JSON Schema (especificação separada)	XSD, DTD, RELAX NG (maduro, poderoso)
Suporte a namespaces	❌ Não	✅ Sim (evita colisões de nomes)
Tipos de dados	Strings, números, booleanos, nulo, objetos, arrays	Tudo é texto (tipos via esquema apenas)
Atributos	❌ Não (apenas chaves)	✅ Sim (metadados em elementos)
Conteúdo misto	❌ Não	✅ Sim (texto + marcação intercalados)
Transformação	Código manual	XSLT (transformações declarativas)
Linguagem de consulta	JSONPath, JMESPath	XPath, XQuery (mais maduro)
Velocidade de análise	Rápido (gramática simples)	Mais lento (gramática complexa, validação)
Análise nativa no navegador	✅ JSON.parse()	✅ DOMParser
Tamanho do arquivo (mesmos dados)	Menor (~60-70% do XML)	Maior (tags redundantes)
Ecossistema de ferramentas	Moderno, em crescimento	Maduro, extenso

Quando o XML Ainda Vence

Sei que é tentador descartar o XML completamente. Resista a esse impulso. Existem domínios específicos onde o XML não é apenas adequado, mas genuinamente superior.

1. Marcação de Documentos e Conteúdo Misto

Esta é a característica matadora do XML. Considere um parágrafo com formatação inline:

<paragraph>
  Este é um texto <bold>importante</bold> com um
  <link href="/page">hiperlink</link> embutido nele.
</paragraph>

Tente representar isso em JSON. Você acabaria com algo horrível — um array de elementos de string e objeto misturados, ou algum tipo de sintaxe de escape de marcação. JSON foi projetado para dados estruturados, não para documentos. XML foi projetado para ambos.

É por isso que HTML (um primo do XML), DocBook, DITA e formatos de publicação usam sintaxe baseada em XML. Arquivos EPUB são XML. Arquivos do Microsoft Office (.docx, .xlsx) são XML compactados. O mundo dos documentos funciona com XML, e o JSON não está vindo para tomar esse trono.

2. Serviços Web SOAP

Sistemas empresariais, especialmente em bancos, saúde e governo, ainda dependem fortemente do SOAP. Esses serviços usam XML com esquemas rigorosos (WSDL), e não estão migrando para REST tão cedo. Se você estiver integrando com APIs empresariais legadas, você trabalhará com XML, goste você ou não.

3. Transformações XSLT

XSLT permite que você transforme documentos XML de forma declarativa — reestruture, filtre, formate — sem escrever código procedural. É poderoso para gerar relatórios HTML a partir de dados XML, converter entre esquemas XML e processar pipelines de documentos. JSON não tem equivalente que chegue perto das capacidades do XSLT.

4. Namespaces

Quando você precisa combinar dados de várias fontes em um único documento sem colisões de nomes, namespaces XML resolvem isso de forma elegante:

<root xmlns:hr="http://example.com/hr"
      xmlns:fin="http://example.com/finance">
  <hr:employee>
    <hr:name>Alice</hr:name>
    <fin:salary currency="USD">95000</fin:salary>
  </hr:employee>
</root>

JSON não tem conceito de namespace. Se duas APIs usam o mesmo nome de chave com significados diferentes, você está por conta própria para resolver o conflito.

5. RSS, Atom e SVG

Feeds RSS e Atom são XML. Gráficos SVG são XML. Esses formatos estão profundamente embutidos no ecossistema web e não estão mudando. Se você está gerando ou consumindo algum desses, precisa de suporte a XML.

Quando o JSON Vence

Para a maioria das tarefas de desenvolvimento moderno, JSON é a escolha pragmática. Aqui está onde ele domina claramente:

1. APIs REST

Os números contam a história. De acordo com várias pesquisas de API, mais de 90% das APIs públicas usam JSON como seu formato de resposta principal. É mais leve na transmissão, mais rápido para analisar e se mapeia diretamente para estruturas de dados nativas em JavaScript, Python, Ruby, Go e na maioria das outras linguagens.

// Chamando uma API REST — a resposta já é JSON
const response = await fetch("https://api.github.com/users/octocat");
const user = await response.json();
console.log(user.login); // "octocat"

Com XML, você precisaria instanciar um parser DOM, percorrer nós e extrair o conteúdo de texto manualmente. Com JSON, você chama .json() e obtém um objeto nativo. A diferença na experiência do desenvolvedor é enorme.

2. Bancos de Dados NoSQL

MongoDB, CouchDB, DynamoDB, Firestore, Elasticsearch — todo o ecossistema NoSQL é construído em torno de documentos JSON (ou semelhantes ao JSON). Se seus dados já estão em JSON, armazená-los em um banco de dados de documentos é praticamente sem atrito.

3. Aplicações Móveis e Frontend

Aplicativos móveis precisam ser eficientes com largura de banda e bateria. O tamanho menor da carga útil do JSON e a análise mais rápida se traduzem diretamente em melhor desempenho do aplicativo. Tanto iOS (Codable) quanto Android (Gson, Moshi, Kotlin Serialization) têm excelentes bibliotecas JSON.

4. Configuração (com ressalvas)

package.json, tsconfig.json, .eslintrc.json — JSON está em toda parte no ecossistema de ferramentas JavaScript. A falta de comentários é um verdadeiro ponto de dor aqui, razão pela qual muitas ferramentas agora aceitam JSONC ou JSON5. Para configurações mais complexas, recomendo olhar para YAML como uma alternativa.

5. Comunicação em Tempo Real

Mensagens WebSocket, Eventos Enviados pelo Servidor e feeds de dados em tempo real usam quase universalmente JSON. A compactação do formato e a análise nativa no navegador o tornam ideal para troca de dados de alta frequência.

Trabalhando com ambos os formatos? Nossos conversores JSON para XML e XML para JSON facilitam a tradução entre eles. Tente colar seus dados e veja a saída instantaneamente.

A Mudança na Indústria em Números

A mudança de XML para JSON tem sido dramática e bem documentada:

• Tendências do Stack Overflow: Perguntas marcadas como "json" superaram "xml" por volta de 2013 e agora superam em cerca de 2:1.
• Formatos de API pública: Dados do ProgrammableWeb mostraram que JSON superou XML como o formato de API mais oferecido por volta de 2011. Hoje, JSON domina por uma ampla margem.
• Ecossistema npm: A principal biblioteca de análise de JSON (o JSON.parse embutido) não tem dependências e é enviada com todos os tempos de execução JavaScript. A análise de XML requer bibliotecas de terceiros na maioria das linguagens.
• Novas especificações: A maioria dos novos padrões de dados (JSON-LD, GeoJSON, JSON Schema, JWT) são baseados em JSON. Especificações baseadas em XML estão principalmente em modo de manutenção.

Dito isso, indústrias como saúde (HL7, FHIR usa parcialmente XML), publicação (EPUB, DITA), governo (muitos sistemas legados) e finanças (protocolo FIX, ISO 20022) ainda dependem fortemente do XML. Se você está trabalhando nesses setores, a proficiência em XML não é opcional.

Comparação de Desempenho

Para uma carga de dados típica, aqui está como os dois formatos se comparam:

Métrica	JSON	XML
Tempo de análise (1MB, Node.js)	~15ms	~60ms (SAX) / ~150ms (DOM)
Tempo de serialização	~10ms	~45ms
Tamanho da carga útil (formatado)	1.0 MB	1.5–1.7 MB
Tamanho da carga útil (minificado)	0.6 MB	1.2 MB (tags não podem ser eliminadas)
Tamanho comprimido	~120 KB	~140 KB (diferença diminui com compressão)

A comparação comprimida é interessante — as tags repetitivas do XML realmente se comprimem bem, então a diferença de tamanho diminui significativamente após a compressão. Se você estiver servindo respostas comprimidas (o que deve fazer), o argumento do tamanho da carga útil é menos convincente do que parece à primeira vista. No entanto, a diferença de velocidade de análise permanece significativa.

Dicas de Migração

Se você está migrando de XML para JSON (uma tarefa comum), aqui estão algumas coisas a serem observadas:

1. Atributos não têm um equivalente direto. Atributos XML geralmente se tornam propriedades regulares do JSON, às vezes prefixadas com @ por ferramentas de conversão.
2. Conteúdo misto é difícil de representar. Se seu XML tem texto intercalado com elementos, você precisará decidir sobre uma convenção (como arrays de strings e objetos misturados).
3. Informações de namespace se perdem. JSON não tem conceito de namespaces, então você precisará lidar com conflitos manualmente.
4. A ordem pode ou não importar. A ordem dos elementos XML é significativa. A ordem das chaves de objeto JSON não é tecnicamente garantida (embora a maioria das implementações preserve a ordem de inserção).
5. Valide após a conversão. Use nosso Validador JSON para garantir que a saída convertida seja válida, e a ferramenta JSON Compare para verificar a integridade dos dados.

O Veredicto

Para a maioria do desenvolvimento web moderno, JSON é o padrão correto. É mais simples, mais leve, mais rápido de analisar e suportado nativamente em navegadores. O impulso do ecossistema é avassalador.

Mas "use JSON para tudo" é um conselho ruim. O XML continua sendo a melhor escolha para dados centrados em documentos, conteúdo misto, validação de esquema complexa, integrações ricas em namespaces e sistemas empresariais legados. Conhecer ambos os formatos — e quando cada um é apropriado — é o que faz de você um desenvolvedor completo.

Na minha experiência, a melhor abordagem é pragmática: use qualquer formato que o ecossistema em que você está trabalhando espera, e não lute contra a corrente. Converta entre eles quando precisar e passe para resolver o problema real.

Continue explorando:

• O que é JSON? — o guia completo para iniciantes
• JSON vs YAML — outra comparação de formato comum
• Conversor de JSON para XML
• Conversor de XML para JSON
• Formatador JSON — formate e valide JSON instantaneamente