O que é JSON: formato de troca de dados

JSON (JavaScript Object Notation) é um formato textual leve e independente de linguagem para serializar dados estruturados. Ele representa strings, números, booleanos, null, objetos e arrays em texto portátil, o que facilita a troca de informações entre sistemas, serviços e aplicações web sem amarrar o dado a um único ambiente de execução.

Você abre o painel de rede do navegador, clica numa resposta de login e vê um bloco de texto com chaves, aspas e listas. Em muitos casos, esse bloco é JSON, e a tela só monta o que chega nesse formato. Quem nunca abriu o código ainda assim vive cercado por ele, porque o celular, o checkout da loja e o painel do sistema falam assim entre si.

O custo de ignorar o formato aparece no primeiro erro de vírgula ou no número grande que perde casas ao cruzar de um sistema para outro. Por isso este guia explica o que o JSON carrega, o que ele não carrega, onde ele costuma aparecer e quais armadilhas valem atenção antes de você confiar nele em produção.

Para que serve o JSON no dia a dia#

O JSON serve para transportar e armazenar dados estruturados em texto, de modo que programas diferentes leiam o mesmo conteúdo com o mesmo significado combinado. A especificação vigente da IETF, publicada em dezembro de 2017 como RFC 8259 (também STD 90), descreve o formato JSON como leve, baseado em texto e independente de linguagem, derivado do padrão ECMAScript, porém útil fora do JavaScript.

Na web, a utilidade mais comum é a resposta de uma API. O servidor devolve um objeto com status, lista de produtos ou perfil do usuário, e o cliente transforma esse texto em estruturas internas. Além disso, o mesmo formato aparece em arquivos de configuração, exportações de sistemas e mensagens entre microserviços, porque o texto passa por proxies, logs e ferramentas de inspeção sem exigir binário proprietário.

O benefício da leitura humana vem com um preço. O texto é mais verboso que um binário compacto, e um payload mal validado pode quebrar o parse ou, em bibliotecas inseguras, abrir caminho para abuso na desserialização. Em outras palavras, JSON facilita a integração, porém não substitui contrato, validação nem transporte seguro com HTTPS.

Imagine uma loja que envia o carrinho ao backend. Um objeto com itens, moeda e total viaja como JSON. O frontend renderiza a lista e o servidor recalcula o total. Se o campo total vier só do cliente sem checagem, o formato continua válido e o risco passa a ser de regra de negócio, não de sintaxe.

Na prática, o que eu vejo com mais frequência é equipe tratar JSON como só um arquivo de texto e esquecer que cada campo precisa de tipo, obrigatoriedade e limite. Quem define o contrato antes do código evita metade dos incidentes de integração.

Onde o formato JSON aparece com mais frequência#

O formato JSON aparece em respostas HTTP com tipo de mídia application/json, em arquivos com extensão .json e em corpos de webhook. Segundo a documentação de aprendizado da MDN sobre trabalhar com JSON, um texto JSON pode viver em arquivo próprio com essa extensão e com o MIME application/json.

Em fluxos modernos, o navegador busca dados parciais sem recarregar a página inteira, e o recurso pedido costuma ser JSON. Assim, o tempo de espera cai para o trecho que mudou, enquanto o HTML da casca permanece. Por outro lado, o mesmo padrão aumenta a superfície de dados que o cliente precisa validar, porque cada resposta parcial pode trazer campos novos ou nulos.

Como a sintaxe JSON organiza tipos e estruturas#

A sintaxe JSON organiza quatro tipos primitivos (string, number, boolean e null) e dois tipos estruturados (object e array). A RFC 8259 descreve esses seis tipos como o conjunto portátil do formato, e a MDN reforça que funções, expressões regulares e datas não existem como tipo nativo no JSON.

Um objeto é uma coleção de pares nome e valor, em que o nome é string. Um array é uma sequência ordenada de valores. Por exemplo, um cadastro com nome Ana, ativos verdadeiro, tags vip e b2b, e saldo nulo forma um texto JSON válido típico. Em seguida, o parser reconstrói a estrutura na linguagem de destino.

A sintaxe JSON exige aspas duplas em nomes e em strings, rejeita vírgula final em objetos e arrays e não admite comentários. A página de aprendizado da MDN lista essas restrições com clareza e também lembra que undefined, NaN e Infinity não entram no conjunto válido. Portanto, o que parece quase JavaScript falha no parse se você colar um literal solto da linguagem.

Há um custo escondido na simplicidade. Como o JSON não carrega tipo de data, a maioria dos sistemas usa string no padrão ISO 8601 e combina o significado fora do formato. Se um lado espera data e hora em texto UTC e o outro manda timestamp numérico, ambos os textos podem ser JSON válidos e a integração ainda assim quebra.

Se fosse comigo, eu começaria todo contrato listando campos, tipos, nulidade e exemplos válidos e inválidos antes de liberar o primeiro endpoint. Sem esse mapa, a sintaxe limpa mascara desalinhamento semântico.

Números, precisão e o que o RFC recomenda#

Números em JSON são sequências de dígitos em base 10, com sinal opcional, parte fracionária e expoente, sem zero à esquerda fora do próprio zero. A RFC 8259 deixa claro, na seção de números, que Infinity e NaN não são permitidos, e que implementações podem limitar faixa e precisão aceitas.

Para interoperabilidade ampla, o mesmo RFC aponta o uso prático de números no espírito do IEEE 754 binary64 (precisão dupla). Inteiros no intervalo de -(2^53)+1 a (2^53)-1 tendem a ser acordados exatamente entre implementações comuns. Valores maiores ou com precisão excessiva podem ser apenas aproximados. Números como 1E400 ou π com dezenas de casas sinalizam risco de incompatibilidade.

E se o seu identificador for um inteiro de 64 bits de banco? O caminho seguro costuma ser enviar o valor como string e documentar a semântica, em linha com o perfil I-JSON (RFC 7493) para troca restrita e previsível. O benefício de manter o número puro some quando a precisão diverge entre JavaScript, Java e SQL.

JSON e JavaScript não são a mesma coisa#

JSON inspira-se na notação de objetos do JavaScript, porém não é o mesmo conjunto da linguagem. A MDN, na referência do objeto JSON, enfatiza que o formato serializa objetos, arrays, números, strings, booleanos e null, e que a maior parte do JavaScript não é JSON. Nomes de propriedade precisam de aspas duplas, vírgulas finais são proibidas e undefined não tem representação.

No ambiente JavaScript, JSON.stringify transforma um valor em texto, e JSON.parse faz o caminho inverso. No entanto, um objeto com referência circular não serializa, e funções são omitidas ou rejeitadas conforme o caso. Ou seja, funcionar no console como objeto não prova que o payload será JSON válido na rede.

A confusão gera dois erros clássicos. O primeiro é usar eval ou execução de script sobre texto recebido, prática que a própria história do formato tentou afastar ao isolar dados de código. O segundo é misturar literais da linguagem com o arquivo JSON de configuração e depois culpar o parser quando a vírgula sobra.

Comparado ao HTML, o JSON não marca apresentação de página. Ele carrega dados. Comparado a um banco de dados, ele não oferece consulta, índice nem transação. Ele só representa um recorte de informação num momento, e esse recorte precisa de dono, versão e validação.

O erro que mais custa caro aqui é achar que validar “é JSON” basta. Um payload pode ser sintaticamente perfeito e semanticamente hostil, com campos a mais, tipos trocados ou metadados de tipo que certas bibliotecas interpretam de forma perigosa.

Como ler, gerar e validar um arquivo JSON com segurança#

Ler e gerar JSON com segurança começa por usar o parser da plataforma, nunca um atalho que execute o texto como código. Em JavaScript, isso significa preferir JSON.parse para entrada e JSON.stringify para saída, com tratamento de erro quando o texto vier truncado. Texto inválido resulta em SyntaxError, e uma função reviver pode transformar valores depois do parse, conforme a documentação da MDN sobre o método.

Validar vai além do parse. Depois que a estrutura existe na memória, você ainda precisa checar campos obrigatórios, intervalos e enums do seu domínio. Ferramentas de schema (por exemplo JSON Schema em ecossistemas que o adotam) ajudam, porém o schema só funciona se estiver versionado junto do contrato da API. Enquanto isso, logs devem mascarar dado pessoal, porque um arquivo JSON de exportação costuma concentrar PII.

Um exemplo concreto ajuda a separar sintaxe de regra. Você recebe um pedido com identificador A-19 e uma lista de itens em que o primeiro item tem sku X1 e quantidade 2. O parse passa. Em seguida a regra de negócio exige quantidade inteira entre 1 e 99 e sku conhecido. Se a quantidade vier 2.5 ou a string "2", a decisão de aceitar ou rejeitar é sua, não do formato.

O custo de validar pouco aparece em incidentes de mass assignment e em inconsistência de cache, quando respostas JSON antigas ficam armazenadas com campos que o cliente novo não entende. Por isso versionar o contrato e invalidar cache com chave explícita reduz surpresa.

Muita gente acha que JSON é seguro por ser só dados, e quase sempre está enganada, porque o risco mora na biblioteca e no código que consome o objeto depois do parse. Trate todo texto externo como não confiável até provar o contrário.

Quais riscos de segurança cercam JSON em APIs#

Os riscos de segurança em torno de JSON concentram-se menos na gramática e mais no modo de desserializar e confiar no conteúdo. O guia de testes da OWASP sobre desserialização insegura explica que desserializar dado não confiável sem verificação suficiente pode levar a execução remota de código, negação de serviço, bypass de autenticação e abuso de lógica. No caso de JSON, o alerta reforçado cai sobre bibliotecas com tipagem polimórfica que aceitam metadados como @class, @type ou $type controlados pelo atacante.

A própria OWASP recomenda preferir formatos só de dados, como JSON, quando parseados sem metadados de tipo controlados pelo atacante, e restringir tipos aceitos com allow-list quando a desserialização for inevitável. Em runtimes JavaScript, o guia também associa a fusão descuidada de objetos ao problema de prototype pollution, que deve ser testado à parte.

Há ainda o risco de transporte e de vazamento. JSON em claro em rede aberta expõe o conteúdo. Por isso o canal precisa de HTTPS e de controles de autenticação adequados ao serviço. Logs que gravam o body inteiro podem vazar token, CPF ou segredo de sessão. O formato não cifra nada por conta própria, e criptografia ou tokenização entram como camada separada quando o dado exige.

E se o payload for enorme de propósito? Parsers e frameworks podem sofrer com uso excessivo de memória ou CPU. Limitar tamanho do body, profundidade de aninhamento e tempo de parse é defesa operacional, não detalhe cosmético.

Quando reviso contratos de API, eu trato JSON de entrada como superfície de ataque igual a formulário ou upload. Desligo tipagem polimórfica por padrão, valido schema e nunca confio em campo de papel ou preço que venha só do cliente.

Termos relacionados#

• API (interface de programação de aplicações) é o canal em que o JSON mais circula como corpo de requisição e resposta.
• HTTPS protege o transporte do texto JSON contra leitura e adulteração no caminho.
• banco de dados costuma ser a origem ou o destino dos valores que o JSON apenas representa em trânsito.
• HTML estrutura páginas, enquanto o JSON estrutura dados que a página ou o app consomem.
• microserviços trocam eventos e comandos com frequência em JSON, o que torna contrato e versionamento obrigatórios.
• cache pode armazenar respostas JSON e reapresentar dado velho se a chave ou o tempo de vida estiverem errados.

Perguntas frequentes sobre JSON#

Antes das respostas, vale reunir as dúvidas que mais aparecem quando alguém busca o que é JSON pela primeira vez. As perguntas abaixo cobrem definição, diferença para JavaScript, arquivo na prática, precisão numérica e segurança no parse, para você consultar só o trecho que falta.

Afinal, o que é JSON em uma frase útil?#

JSON é um formato textual padrão para serializar dados estruturados com objetos, arrays e valores simples, de modo que sistemas distintos troquem a mesma informação sem compartilhar a mesma linguagem de programação. A definição normativa atual está na RFC 8259 de dezembro de 2017. Ele descreve a forma do texto, não a regra de negócio do seu sistema.

JSON é a mesma coisa que um objeto JavaScript?#

Não. O formato se inspira na notação de objetos do JavaScript, porém impõe regras mais rígidas, como aspas duplas obrigatórias e ausência de comentários, funções e undefined. Um objeto literal da linguagem pode ser inválido como JSON. Use JSON.parse e JSON.stringify em vez de tratar o texto como código executável.

O que costuma ir em um arquivo JSON?#

Um arquivo JSON é texto puro com extensão .json e, quando servido na web, tipo application/json. Ele pode guardar configuração, fixtures de teste, exportação de cadastro ou mock de API. O conteúdo ainda precisa respeitar a gramática e o significado combinado entre quem grava e quem lê.

Por que meu número grande muda depois do parse?#

Porque muitas implementações tratam números no espírito da precisão dupla IEEE 754, e inteiros fora da faixa segura em torno de 2^53 podem deixar de ser exatos. A RFC 8259 documenta esse limite prático de interoperabilidade. Para identificadores longos, prefira string e documente o formato.

JSON sozinho garante segurança da API?#

Não. O parse correto evita erro de sintaxe, porém não impede campo malicioso, metadado de tipo perigoso em bibliotecas inseguras nem vazamento em log. A OWASP trata desserialização insegura como classe de risco própria. Transporte com HTTPS, autenticação, autorização e validação de schema continuam obrigatórios.

Conclusão#

Para a maioria dos times, JSON continua sendo a escolha certa para trocar dados estruturados na web e entre serviços, porque é legível, amplamente suportado e padronizado de forma estável. A decisão muda quando você precisa de binário compacto extremo, de tipagem rica nativa ou de streaming com outro contrato já estabelecido no ecossistema.

O primeiro passo prático é simples. Abra um payload real do seu sistema, confira se cada campo tem dono e tipo, e garanta que o parse usa biblioteca sem tipagem polimórfica aberta. Depois disso, versionar o contrato e limitar tamanho e profundidade evita a maior parte das surpresas caras.

Este conteúdo é informativo e geral sobre JSON e formatos de dados. Ele não substitui revisão de segurança, arquitetura ou conformidade (incluindo LGPD quando houver dado pessoal) para o seu caso. Bibliotecas, parsers e políticas de API mudam. Confira a documentação oficial da sua stack na data em que for implementar ou auditar.