Ferramentas de desenvolvedor·7 min

Boas práticas de formatação JSON para desenvolvedores

Aprenda boas práticas de formatação JSON: evite erros comuns, valide, embeleze e domine APIs com exemplos práticos e reais.

O que é JSON e por que a formatação importa?

JSON (JavaScript Object Notation) é o formato de troca de dados padrão da web. É leve, legível e praticamente todas as linguagens o suportam nativamente. Seja construindo uma API REST, guardando configuração ou movendo dados entre frontend e backend, JSON é quase sempre a escolha.

Mas "legível" depende de como você escreve. Uma única linha de JSON minificado pode ter 4 KB; os mesmos dados com indentação de dois espaços podem ter 8 KB. Ambos são válidos. A diferença é se o próximo desenvolvedor — incluindo você no futuro — consegue ler às 2 da manhã durante um incidente.

Boa formatação não é só estética. Ela afeta diretamente:

  • Depurabilidade: um payload embelezado mostra a estrutura de cara. Objetos anidados são fáceis de navegar, chaves faltando saltam aos olhos e erros de digitação se destacam.
  • Legibilidade do diff: revisar código em JSON minificado é inútil. Um diff indentado com dois espaços mostra claramente quais campos mudaram.
  • Localização de erros: quando o parse falha, os números de linha e coluna só fazem sentido se o documento tem um layout real.
  • Colaboração: um estilo consistente no time evita que ninguém perca tempo reformatando arquivos antes de trabalhar com eles.

Em resumo, formatar é uma forma de comunicação. Trate seu JSON como trata seu código.

Os erros mais comuns em JSON

Até desenvolvedores experientes cometem esses equívocos. Eles são sintaxe válida em JavaScript, por isso passam despercebidos pelo editor.

Vírgulas no final

Uma vírgula extra após o último elemento de um array ou objeto é perfeitamente válida em JavaScript. JSON não permite.

```json // INVÁLIDO { "name": "Ada", "age": 36, } ```

A correção é trivial: remova a vírgula. A maioria dos linters pega isso. Se o seu não pega, troque por um que pegue.

Aspas simples para strings

Strings em JSON devem usar aspas duplas. Aspas simples são convenção de JavaScript, não de JSON.

```json // INVÁLIDO { 'name': 'Ada' } ```

Isso acontece com frequência ao copiar valores de um literal de objeto em JavaScript ou de um dicionário em Python. Use sempre aspas duplas, tanto para chaves quanto para valores string.

Chaves sem aspas

Chaves em JSON precisam ser strings, e strings precisam estar entre aspas.

```json // INVÁLIDO { name: "Ada" } ```

Comentários

JSON não suporta comentários. Nem `//` nem `/ /` serão parseados. Se precisar de anotações, use um campo `"_comment"`, um arquivo auxiliar, ou migre para JSON5/JSONC — mas só no lado produtor, porque a maioria dos consumidores espera JSON estrito.

Chaves e colchetes desbalanceados

Um `}` faltando ou um `]` a mais é a causa mais comum de "Unexpected end of JSON input" e similares. Embelezar é a forma mais rápida de encontrar: seus olhos percebem o desequilíbrio na hora.

Como validar JSON

Validação se divide em duas categorias: sintática (está bem formado?) e semântica (corresponde ao esquema esperado?).

Para validação sintática, qualquer editor moderno resolve. O VS Code destaca em vermelho o JSON malformado. A ferramenta CLI `jq` indica erro no primeiro caractere que falhou. Validadores online funcionam, mas tenha cuidado com dados sensíveis — cole apenas amostras não sensíveis.

Para validação semântica, você precisa de um JSON Schema (ver abaixo) ou um parser tipado na sua linguagem. Em TypeScript, bibliotecas como `zod` ou `io-ts` permitem descrever a forma esperada e rejeitar o que não bate. Isso captura a pior classe de bug: a API retorna silenciosamente um campo novo, ou um campo antigo vira `null`, e seu código quebra três camadas abaixo.

Um bom fluxo de trabalho:

  1. Embeleze o JSON recebido enquanto depura.
  2. Valide contra um esquema na fronteira do sistema (controller, cliente de API, handler de mensagem).
  3. Não confie em nada dentro da fronteira.

Embelezar vs. minificar

São dois lados da mesma moeda, e ambos são úteis — só que em lugares diferentes.

Embelezar (também "beautify" ou "expand") adiciona indentação e quebras de linha. Use para:

  • Arquivos fonte commitados no git
  • Respostas de API que você inspeciona em desenvolvimento
  • Entradas de log que talvez precise ler depois
  • Documentação e exemplos

Minificar remove todos os espaços em branco. Use para:

  • Respostas de API em produção
  • Tokens e cookies (JWT, armazenamento de sessão)
  • Armazenamento em bancos de dados ou caches com pouco espaço
  • Cargas de rede onde cada byte conta

Regra prática: embeleze em desenvolvimento, minifique em produção. A maioria das ferramentas de build faz isso automaticamente. Para tarefas pontuais, um formatador de JSON gratuito resolve as duas direções com um único paste.

Se precisar comparar dois documentos JSON, uma ferramenta de diff de texto destaca exatamente quais campos mudaram — bem mais útil do que encarar uma saída minificada.

Trabalhando com dados aninhados

Objetos e arrays aninhados são onde o JSON brilha — e onde os bugs adoram se esconder.

Alguns princípios:

  • Mantenha o aninhamento raso. Três níveis está ótimo. Cinco níveis significa que você provavelmente deve modelar os dados como uma lista plana com chaves estrangeiras, ou dividir em vários endpoints.
  • Seja consistente entre arrays e objetos. Um campo que às vezes é array e às vezes é `null` é causa comum de `Cannot read property 'map' of null`. Decida antes: se não houver itens, retorne `[]`, não `null`.
  • Use uma ordem de chaves estável quando importar. JSON não exige ordem, mas parsers e ferramentas de diff se comportam melhor com ordem previsível. Ordem alfabética é um padrão seguro.
  • Cuidado com arrays gigantes. Um blob JSON de 50 MB com um milhão de itens em um array é tecnicamente válido, mas impossível de fazer streaming. Considere NDJSON (um objeto JSON por linha) ou uma API paginada.

JSON em APIs: content-type e códigos de status

Se você constrói APIs HTTP, dois cabeçalhos fazem quase todo o trabalho:

  • `Content-Type: application/json` — informa ao cliente (e a qualquer intermediário) o que esperar. Esquecê-lo é o bug de API mais comum em produção.
  • `Accept: application/json` — o que o cliente aceita receber. Útil para negociação de conteúdo.

No lado da resposta, combine o código de status com o resultado:

  • `200 OK` — sucesso, corpo contém o recurso ou resultado.
  • `201 Created` — um novo recurso foi criado; o cabeçalho `Location` deve apontar para ele.
  • `204 No Content` — sucesso, sem corpo (comum em DELETE).
  • `400 Bad Request` — requisição malformada (JSON inválido, campo obrigatório faltando).
  • `401 Unauthorized` — sem credenciais válidas.
  • `403 Forbidden` — credenciais válidas, mas sem permissão.
  • `404 Not Found` — o recurso não existe.
  • `422 Unprocessable Entity` — JSON válido, mas semanticamente errado (ex.: idade negativa).
  • `500 Internal Server Error` — algo quebrou no servidor. Nunca exponha stack traces.

Um padrão comum é envelopar as respostas: `{ "data": ..., "error": null }` ou `{ "data": null, "error": { "code": "...", "message": "..." } }`. Tudo bem, mas não é obrigatório. Qualquer um dos dois é melhor do que formatos improvisados e inconsistentes.

Básico de JSON Schema

JSON Schema é um vocabulário que permite descrever a forma e as restrições de um documento JSON. Pense nele como o sistema de tipos do JSON.

Um esquema mínimo:

```json { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "required": ["name", "age"], "properties": { "name": { "type": "string", "minLength": 1 }, "age": { "type": "integer", "minimum": 0 } } } ```

Diz: o documento deve ser um objeto com `name` não vazio e `age` inteiro não negativo. Você pode estender com formatos (`"format": "email"`), enums, regex e referências a outros esquemas.

Por que se dar a esse trabalho? Validar na fronteira impede que dados ruins se propaguem. Também serve como documentação viva: o esquema descreve o que sua API realmente aceita, não o que alguém acha que aceita.

Quase toda linguagem tem um validador de JSON Schema. No ecossistema TypeScript, ferramentas como `zod` são cada vez mais populares porque geram tipos TypeScript a partir do esquema para você.

Armadilhas comuns com datas, números e caracteres especiais

JSON é intencionalmente minimalista. Não tem tipo data, e isso pega todo mundo.

  • Datas: armazene como strings ISO 8601 (`"2026-02-01T12:00:00Z"`). Evite formatos como `"02/01/2026"` — ambíguos e dependentes de locale.
  • Números: números em JSON são decimais. Não existe tipo inteiro. No JavaScript, inteiros acima de 2^53 perdem precisão. Para IDs ou dinheiro, prefira strings.
  • Booleanos: apenas os literais `true` e `false`. Strings como `"true"` não são convertidas automaticamente.
  • Unicode: strings em JSON são Unicode, então emojis e caracteres CJK funcionam diretamente. Mas as sequências de escape importam: `\n` é nova linha, `\\` é barra invertida, `\u0041` é `A`. Em caso de dúvida, cole seus dados em um formatador de JSON e inspecione os bytes brutos.
  • Null vs. ausente: `{"age": null}` e `{}` significam coisas diferentes. Decida qual representa "desconhecido" no seu sistema e mantenha o padrão.

Ferramentas que economizam seu tempo

Um bom formatador é uma daquelas ferramentas que você não percebe que precisa até usar. Nosso formatador de JSON gratuito roda inteiramente no seu navegador — sem upload, sem cadastro, sem rastreamento. Cole um payload minificado, receba uma árvore legível, copie. Ele valida enquanto formata, então erros de sintaxe aparecem em linha, apontando o caractere problemático.

Para comparar duas versões de um documento JSON — por exemplo, antes e depois de uma migração — a ferramenta de diff de texto faz o mesmo trabalho com qualquer texto puro, com destaque linha a linha.

Ambas fazem parte de um conjunto maior de ferramentas de desenvolvedor pensadas para aquelas utilidades rápidas no navegador que você usa dezenas de vezes por dia.

Conclusão

A formatação de JSON é uma daquelas pequenas disciplinas que se acumulam ao longo de um projeto. Embeleze em desenvolvimento, minifique em produção. Valide na fronteira. Use esquemas quando os dados forem além de um caso pontual. Armazene datas como ISO 8601, números grandes como strings, e trate `null` com intenção.

Nada disso é glamoroso. Mas tudo isso vai te poupar horas de depuração na próxima vez que algo der errado — e algo sempre dá errado. A boa notícia é que, com um formatador e um esquema à mão, a correção costuma estar a um único paste de distância.