O que é JSON? O formato de dados da web

Se você abrir as ferramentas de desenvolvedor de qualquer site moderno e olhar o tráfego de rede, vai encontrar JSON por toda parte. Ele é o formato em que apps, servidores e APIs trocam dados o tempo todo. Neste artigo você vai entender o que é JSON, como funciona sua sintaxe, quais são seus tipos, como serializar e validar dados e por que ele se tornou a língua franca da troca de dados na web.

O que significa JSON

JSON significa JavaScript Object Notation — Notação de Objetos JavaScript. É um formato de texto leve para representar dados estruturados. Apesar do nome, JSON não é exclusivo do JavaScript: praticamente toda linguagem de programação sabe ler e escrever JSON.

A ideia central é simples: representar dados de uma forma que seja, ao mesmo tempo, fácil para humanos lerem e fácil para máquinas processarem. O formato foi padronizado pela RFC 8259 (Tim Bray, 2017), o que garante que sistemas diferentes interpretem o mesmo arquivo da mesma maneira.

Uma característica que ajuda muito é que JSON é independente de linguagem e de plataforma. Um servidor escrito em Go pode mandar JSON para um app em Swift, que repassa para um front-end em JavaScript, e nenhum deles precisa saber em que linguagem o outro foi escrito. Esse "menor denominador comum" é o que faz o JSON funcionar como cola entre sistemas heterogêneos.

Um exemplo vale mais que mil palavras

Veja como JSON representa uma pessoa:

{
  "nome": "Carla Mendes",
  "idade": 29,
  "ativo": true,
  "habilidades": ["JavaScript", "Python", "SQL"],
  "endereco": {
    "cidade": "São Paulo",
    "uf": "SP"
  },
  "telefone": null
}

Mesmo sem nunca ter visto JSON antes, você consegue ler isso. Há pares de chave e valor, separados por dois-pontos; itens separados por vírgula; e estruturas que se aninham umas dentro das outras. Essa legibilidade imediata é uma das razões da popularidade do formato.

A sintaxe: as regras básicas

JSON tem poucas regras, e segui-las é obrigatório:

Duas pegadinhas pegam iniciantes: aspas simples não são válidas (só aspas duplas), e não pode haver vírgula sobrando depois do último item. Esses pequenos erros de sintaxe quebram o arquivo inteiro.

Erros de sintaxe que mais derrubam iniciantes

Vale ver lado a lado o que é inválido e por quê, porque essas falhas costumam aparecer em produção:

{
  'nome': 'Carla',        // ERRADO: aspas simples não são JSON
  "idade": 29,
  "tags": ["a", "b",],    // ERRADO: vírgula sobrando antes do ]
  "comentario": "linha 1
linha 2",                  // ERRADO: quebra de linha crua dentro da string
}                          // ERRADO: vírgula sobrando depois do último par

Três regras salvam você da maioria desses casos: use sempre aspas duplas, nunca deixe vírgula antes de } ou ], e escape caracteres especiais dentro de strings (quebra de linha vira \n, aspas viram \"). Outro ponto: JSON puro não permite comentários. Os // acima só estão aqui para explicação — em um arquivo real eles quebrariam o parsing. Quando você precisa de comentários (em arquivos de configuração, por exemplo), está usando algum superset como JSON5 ou JSONC, não JSON estrito.

Os tipos de dados do JSON

A especificação RFC 8259 (Bray, 2017) define exatamente seis tipos de valor:

Note que datas não são um tipo nativo — elas são representadas como strings (geralmente no formato ISO 8601, como "2026-06-25"). Isso é uma fonte comum de confusão para quem está começando.

Há outras sutilezas com números que valem atenção. JSON não distingue inteiro de decimal a nível de formato — 5 e 5.0 são ambos "número". E como muitas linguagens representam números em ponto flutuante de 64 bits, inteiros muito grandes podem perder precisão ao passar pelo JSON. Por isso, identificadores longos (como IDs de banco de dados ou números de cartão) costumam ser transmitidos como strings, não como números, para garantir que nenhum dígito se perca. É um detalhe pequeno que já causou bugs muito difíceis de rastrear.

Por que o JSON venceu o XML

Antes do JSON dominar, o formato padrão para troca de dados era o XML. O JSON ganhou espaço por três motivos principais:

Para sentir a diferença de verbosidade na prática, compare o mesmo dado nos dois formatos:

<usuario>
  <nome>Diego</nome>
  <ativo>true</ativo>
</usuario>

{ "nome": "Diego", "ativo": true }

O XML repete o nome de cada campo duas vezes (abertura e fechamento) e exige mais ferramentas para ser processado. Isso não significa que o XML seja "ruim" — ele ainda brilha em documentos com formatação rica, validação por schema madura e namespaces. Mas para troca de dados entre APIs, a leveza do JSON venceu.

Essa eficiência casou com a explosão das APIs web. Quando Roy T. Fielding (2000) descreveu a arquitetura REST, ele falava em "representações" dos recursos — e o JSON se tornou, na prática, a representação preferida.

JSON e as APIs

Hoje, quando um aplicativo conversa com um servidor através de uma API, o corpo da mensagem quase sempre é JSON. O cliente envia JSON e recebe JSON de volta.

POST /usuarios
Content-Type: application/json

{ "nome": "Diego", "email": "diego@exemplo.com" }

Esse formato é o veículo padrão nas APIs REST, transportado sobre o protocolo HTTP. O cabeçalho Content-Type: application/json avisa ao servidor que o corpo da mensagem está em JSON. Dominar esse fluxo é essencial para qualquer integração.

Uma resposta típica de API costuma trazer mais do que os dados crus — ela envolve metadados, paginação e indicadores de status. Veja um padrão muito comum:

{
  "data": [
    { "id": "1", "nome": "Diego" },
    { "id": "2", "nome": "Eva" }
  ],
  "paginacao": {
    "pagina": 1,
    "total_paginas": 7,
    "total_itens": 142
  }
}

Esse tipo de envelope é uma convenção, não uma regra do JSON: o formato em si não impõe nenhuma estrutura. Cabe a quem projeta a API decidir como organizar os campos. Manter consistência nesse formato entre todos os endpoints é uma das marcas de uma API bem desenhada.

Validação: JSON Schema

JSON garante apenas que o texto é sintaticamente válido — não que ele tem os campos certos, com os tipos certos. Para isso existe o JSON Schema, um padrão que descreve a "forma" esperada de um documento JSON e permite validá-lo automaticamente:

{
  "type": "object",
  "properties": {
    "nome":  { "type": "string" },
    "idade": { "type": "integer", "minimum": 0 },
    "email": { "type": "string", "format": "email" }
  },
  "required": ["nome", "email"]
}

Com um schema desses, qualquer biblioteca de validação consegue rejeitar um payload sem email, ou com idade negativa, antes mesmo de o dado chegar à lógica de negócio. Validar a entrada na borda — e nunca confiar cegamente no que chega — é uma prática de segurança e robustez fundamental em qualquer API séria.

JSON em SEO e dados estruturados

O JSON não vive só em APIs. Ele também é o formato recomendado para dados estruturados que ajudam buscadores a entender o conteúdo de uma página. Usando JSON-LD (uma variação do JSON para dados ligados), você descreve produtos, artigos e avaliações de forma que o Google possa exibir resultados ricos. Esse uso é detalhado em Schema.org e dados estruturados: rich snippets no Google.

JSON e inteligência artificial

Outro uso que cresceu muito é a comunicação com modelos de IA. Quando você dá "ferramentas" a um modelo de linguagem, ele responde indicando qual função chamar e com quais argumentos — e esses argumentos vêm estruturados em JSON. Isso permite que a saída do modelo seja processada por código de forma confiável. Esse mecanismo é explicado em Function calling: como dar ferramentas ao seu LLM. A previsibilidade da sintaxe JSON é justamente o que torna essa ponte entre linguagem natural e código possível.

Não por acaso, é comum pedir que um modelo responda "apenas em JSON" para que sua saída possa ser consumida por código. Aqui o JSON Schema reaparece: muitos provedores deixam você anexar um schema para forçar que a resposta do modelo siga exatamente o formato esperado — uma técnica conhecida como saída estruturada, que reduz drasticamente a necessidade de "limpar" texto depois.

Serialização: do objeto ao texto e de volta

Na prática, você raramente escreve JSON à mão. Seu programa trabalha com objetos em memória e os converte para texto JSON quando precisa enviá-los pela rede — processo chamado de serialização. No caminho inverso, ele faz o parsing, transformando o texto recebido de volta em objetos. Quase toda linguagem oferece isso de forma embutida:

// Objeto JavaScript → texto JSON
const texto = JSON.stringify({ nome: "Eva", idade: 31 });

// Texto JSON → objeto JavaScript
const objeto = JSON.parse(texto);

Esse par serializar/desserializar é o que conecta o mundo dos dados em memória ao mundo da transmissão pela rede.

Algumas armadilhas de serialização merecem destaque, especialmente em JavaScript. O JSON.stringify descarta valores undefined e funções, e converte datas em strings automaticamente — o que significa que, ao desserializar, você recebe uma string, não um objeto Date de volta. Estruturas com referências circulares (um objeto que aponta para si mesmo) fazem o JSON.stringify lançar erro. Conhecer esses comportamentos evita surpresas em que um dado "some" no meio do caminho sem nenhuma mensagem de erro.

JSON.stringify({ a: undefined, b: () => {}, c: 1 });
// → '{"c":1}'  (a e b desapareceram)

Boas práticas no dia a dia

Para fechar a parte prática, alguns hábitos que poupam dor de cabeça:

Perguntas frequentes

JSON e objeto JavaScript são a mesma coisa? Não. JSON é um formato de texto; um objeto JavaScript é uma estrutura em memória. JSON foi inspirado na notação de objetos do JavaScript, mas é mais restrito — por exemplo, chaves precisam de aspas duplas e não há funções nem comentários.

Posso colocar comentários em JSON? Em JSON estrito, não. Variantes como JSONC e JSON5 permitem comentários, mas não são JSON padrão e nem todo parser as aceita.

JSON tem limite de tamanho? A especificação não impõe limite, mas na prática servidores e bibliotecas costumam aplicar tetos para evitar consumo excessivo de memória. Para dados muito grandes, considere paginação ou streaming.

Qual a diferença entre JSON e JSON Schema? JSON é o dado em si. JSON Schema é uma descrição de como esse dado deveria ser, usada para validá-lo.

Conclusão

JSON é simples por design, e é justamente essa simplicidade que o tornou o formato universal de troca de dados. Com apenas seis tipos e um punhado de regras de sintaxe, ele consegue representar estruturas complexas de forma legível por humanos e máquinas. Mas a simplicidade não dispensa cuidado: validar a entrada com JSON Schema, tratar números grandes e datas corretamente e conhecer as armadilhas da serialização é o que separa uma integração frágil de uma robusta. Seja consumindo APIs, configurando SEO ou conversando com modelos de IA, você vai encontrar JSON em todo lugar — e entendê-lo bem é um dos fundamentos do desenvolvimento web moderno.

Referências