JSON, XML ou CSV? Escolhendo o Formato de Dados Certo Para o Trabalho
13 de outubro de 2026
JSON, XML e CSV existem todos para mover dados estruturados entre sistemas, mas tratá-los como intercambiáveis é como projetos de integração acabam com dados perdidos, importações quebradas, ou arquivos inchados. Cada formato fez trocas reais de design para os problemas e as épocas para os quais foi construído, e conhecer essas trocas torna simples escolher o certo para uma determinada tarefa.
Em que o CSV é realmente bom, e onde ele falha?
O CSV (valores separados por vírgula) é praticamente o formato estruturado mais simples que existe — texto puro, uma linha por registro, valores separados por vírgulas —, o que o torna universalmente legível por planilhas, bancos de dados, e praticamente qualquer ferramenta de dados já criada. Ele é excelente para dados planos e tabulares: uma lista de registros em que toda linha tem os mesmos campos. Ele falha no momento em que os dados têm qualquer estrutura real além de uma tabela plana — objetos aninhados, relações de um para muitos, ou campos que legitimamente contêm vírgulas ou quebras de linha (tratados de forma inconsistente entre diferentes implementações de CSV) empurram o CSV para além do que ele foi projetado para fazer.
Por que o JSON se tornou especificamente o padrão para APIs web?
A estrutura de objetos e arrays do JSON mapeia quase diretamente para a forma como a maioria das linguagens de programação modernas já representa dados na memória, o que significa que um payload JSON muitas vezes pode ser interpretado diretamente em uma estrutura de dados nativa com o mínimo de trabalho de tradução — uma grande vantagem prática para APIs web, em que velocidade e simplicidade tanto na produção quanto no consumo de dados importam. Ele também é comparativamente compacto e legível por humanos, um equilíbrio que o tornou o padrão natural conforme as APIs web se proliferaram, deslocando amplamente o XML em novos designs de API, mesmo o XML tendo surgido primeiro.
O que o XML consegue fazer que o JSON estruturalmente não consegue?
O XML suporta atributos em elementos (metadados anexados à própria tag, distintos de seu conteúdo), namespaces (evitando colisões de nomes ao combinar vocabulários de fontes diferentes), e um ecossistema maduro e formal de validação por esquema (XSD) para definir e impor rigorosamente exatamente o que um documento válido deve conter — capacidades que o modelo mais simples de objeto/array do JSON não oferece nativamente (o JSON Schema existe, mas chegou depois e é menos universalmente adotado). É por isso que o XML persiste em domínios que exigem validação rigorosa de documentos, documentos com vocabulário misto, ou padrões de dados corporativos e governamentais antigos, anteriores à ascensão do JSON.
Por que converter CSV para um formato aninhado como o JSON exige mais do que uma conversão mecânica?
O CSV não tem o conceito de aninhamento — toda linha é plana —, então converter dados de CSV para um formato que suporta hierarquia (como o JSON representando, digamos, um pedido com vários itens de linha) exige uma decisão real sobre como as linhas planas se mapeiam para uma estrutura aninhada: cada linha vira um objeto separado no nível superior, ou várias linhas que compartilham um mesmo ID são agrupadas em um objeto com um array aninhado? Essa decisão de mapeamento não é recuperável apenas a partir dos dados do CSV — depende de entender as relações reais dos dados, e é por isso que 'só converta meu CSV para JSON' às vezes produz um resultado tecnicamente válido, mas praticamente inutilizável, se a estrutura não foi especificada.
O tamanho de arquivo ou a velocidade de leitura difere de forma significativa entre os três formatos?
O CSV geralmente é o mais compacto para dados genuinamente planos e uniformes, já que tem quase nenhuma sobrecarga estrutural — sem nomes de tag ou de chave repetidos em cada registro. O JSON é mais compacto do que o XML para os mesmos dados aninhados porque não tem a redundância das tags de fechamento do XML, mas inclui mais sobrecarga do que o CSV por causa dos nomes de chave repetidos em cada objeto, a menos que se use uma codificação mais compacta baseada em array. O XML costuma ser o maior dos três para dados equivalentes, devido às tags de abertura e fechamento verbosas, embora isso raramente seja o fator decisivo em comparação com quais capacidades estruturais e ecossistema de ferramentas uma determinada integração realmente precisa.