JSON, CSV ou XML: escolher um formato de dados do qual você não vá se arrepender
Três formatos, três trabalhos diferentes. O que cada um consegue e não consegue expressar, as conversões que perdem informação e como escolher sem se arrepender depois.
Atualizado em 11 de agosto de 20265 min de leitura
Esses três formatos não são tanto concorrentes quanto respostas a perguntas diferentes. CSV é uma tabela. JSON é um grafo de objetos. XML é um documento com marcação. A maior parte da dor no trabalho com dados vem de pedir que um formato seja o que ele não é — aninhamento dentro de CSV, tabelas dentro de XML, comentários dentro de JSON — e a cura costuma ser mudar de formato em vez de brigar com ele.
O que cada um consegue expressar
| CSV | JSON | XML | |
|---|---|---|---|
| Formato | Linhas e colunas planas | Objetos e listas aninhados | Elementos aninhados |
| Tipos | Nenhum — tudo é texto | Texto, número, booleano, nulo | Nenhum de forma nativa; um esquema pode acrescentar |
| Comentários | Não | Não | Sim |
| Atributos vs conteúdo | Não se aplica | Sem distinção | Sim — uma diferença real |
| Tamanho | O menor | Intermediário — as chaves se repetem | O maior — as etiquetas se repetem duas vezes |
| Ler arquivos enormes em fluxo | Trivial | Desconfortável | Viável |
A linha que mais surpreende é a de comentários em JSON. A especificação não tem nenhum, e uma linha com // torna o arquivo inválido — razão pela qual tantas ferramentas inventaram dialetos próprios (JSON5, JSONC) para contornar isso. Se um arquivo de configuração precisa de explicação, esse é um motivo legítimo para preferir outra coisa.
Escolher pelo destino
- 1Vai para uma planilha, banco de dados ou ferramenta de análise? CSV. Tem suporte universal, é compacto, e o formato tabular é o que essas ferramentas esperam.
- 2Vai para uma API ou um aplicativo web? JSON. Ele carrega tipos, expressa aninhamento, e toda linguagem o interpreta sem que você precise escolher uma biblioteca.
- 3Conversando com um sistema corporativo ou de governo? Provavelmente XML, porque é o que a especificação vai dizer. Não brigue com isso.
- 4Um arquivo de configuração que as pessoas vão editar na mão? JSON não — sem comentários e com sintaxe implacável. YAML ou TOML são mais gentis.
- 5Milhões de linhas? CSV, processado linha a linha. Interpretar de uma vez um documento JSON de vários gigabytes é um problema de memória.
O que cada conversão perde
| Conversão | O que se perde |
|---|---|
| CSV → JSON | Nada em estrutura, mas tudo chega como texto a menos que os tipos sejam inferidos |
| JSON → CSV | O aninhamento. Objetos e listas precisam ser achatados ou descartados |
| XML → JSON | A distinção entre atributo e elemento, os comentários, as garantias de ordem |
| JSON → XML | Nada, mas o resultado é verboso e precisa de uma convenção de nomes |
| Excel → CSV | Fórmulas, formatação, várias abas — veja Excel para CSV e JSON |
A linha de JSON para CSV é a que morde. Achatar {customer: {name, address: {city}}} em colunas exige uma convenção — customer.address.city é comum — e qualquer coisa que seja uma lista não tem resposta boa nenhuma. Se o seu JSON é genuinamente aninhado, exportar para CSV é uma decisão com perdas, não uma troca de formato.
O problema de tipos no caminho contrário é mais silencioso e igualmente danoso. O CSV não tem tipos, então 007 pode chegar como o número 7, 2026-04-03 pode virar uma data no idioma errado, e TRUE pode ou não virar um booleano. São as mesmas falhas descritas em converter Excel em CSV e JSON, e elas são inerentes ao formato, não a uma ferramenta específica.
Formate, valide e explore — no seu próprio dispositivo. Dados de clientes e conteúdos de API nunca são enviados.
Formatar e inspecionar JSONHábitos práticos
- Valide antes de entregar. Uma vírgula sobrando ou uma aspa sem escape é rejeitada pelo sistema receptor com um erro que raramente aponta a linha real. O validador encontra em segundos.
- Use datas ISO em todo lugar.
2026-04-03não é ambíguo em nenhum idioma e ordena corretamente como texto puro. Nenhum outro formato faz isso. - Codifique em UTF-8, sempre. Qualquer outra coisa transforma nomes acentuados e símbolos de moeda em caracteres corrompidos em outro sistema.
- Mantenha identificadores como texto. CEPs, telefones e números de conta são rótulos, não quantidades — tratá-los como números tira os zeros à esquerda e arredonda valores longos.
- Ordene as chaves para comparar. Duas exportações dos mesmos dados com as chaves em ordens diferentes produzem uma comparação cheia de ruído. O ordenador de chaves deixa as mudanças legíveis.
Minificar ou formatar?
Os dois, em momentos diferentes. O JSON formatado — indentado, um valor por linha — é para humanos lerem e para controle de versão, onde comparar linha a linha é o objetivo inteiro. O JSON minificado tira todo espaço desnecessário e é para transmissão, onde normalmente economiza 20–30% antes da compressão.
O erro é versionar JSON minificado num repositório. Toda mudança então aparece como uma única linha gigantesca modificada, e revisar isso é impossível. Guarde legível e minifique na hora de construir ou enviar.
Todas essas ferramentas rodam localmente, no seu próprio dispositivo, o que importa especialmente no trabalho com dados: um conteúdo JSON ou uma exportação CSV costuma ser o arquivo mais sensível que uma organização manipula, e enviar um deles a um formatador online é uma divulgação, independentemente do que o serviço prometa fazer com ele.
Perguntas frequentes
Devo usar JSON ou CSV?
CSV para dados tabulares que vão para planilhas, bancos de dados ou ferramentas de análise — é compacto e tem suporte universal. JSON quando os dados são aninhados ou quando os tipos importam, como no conteúdo de uma API, porque o CSV não consegue expressar uma lista dentro de um registro e trata todo valor como texto.
O JSON está substituindo o XML?
Em APIs web, em boa medida sim — o JSON é mais leve e mapeia diretamente para as estruturas de dados que as linguagens de programação já usam. O XML segue padrão no meio corporativo, em governo, em publicação e em formatos de documento, onde seus esquemas, espaços de nomes e modelo de atributos fazem trabalho de verdade.
JSON pode ter comentários?
Não. A especificação não tem sintaxe de comentário, e acrescentar um torna o arquivo inválido. É por isso que existem variantes como JSON5 e JSONC. Se as pessoas precisam editar e entender o arquivo na mão, YAML ou TOML são escolhas melhores para configuração.
O que acontece com dados aninhados quando eu converto JSON em CSV?
Eles precisam ser achatados, normalmente em nomes de coluna com pontos como `customer.address.city`, e listas dentro de um registro não têm representação limpa nenhuma. Se o seu JSON é genuinamente aninhado, exportar para CSV é uma decisão com perdas, e não uma simples troca de formato.