Como formatar e validar JSON online

Se voce trabalha com APIs, arquivos de configuracao ou qualquer tipo de dados estruturados, lida com JSON regularmente. E se voce ja olhou para uma parede de JSON minificado tentando encontrar um colchete faltante, sabe por que a formatacao importa. Um formatador baseado em navegador lida com todo o trabalho localmente sem enviar seus dados para um servidor.

O que a formatacao JSON faz

O JSON bruto de uma resposta API ou um arquivo minificado se parece com isto:

{"users":[{"name":"Alice","age":30,"roles":["admin","editor"]},{"name":"Bob","age":25,"roles":["viewer"]}]}

Um formatador o transforma em algo legivel:

{
  "users": [
    {
      "name": "Alice",
      "age": 30,
      "roles": ["admin", "editor"]
    },
    {
      "name": "Bob",
      "age": 25,
      "roles": ["viewer"]
    }
  ]
}

Os mesmos dados, mas agora voce pode realmente le-los, identificar erros e entender a estrutura.

Como formatar JSON online

1. Cole seu JSON no campo de entrada. O formatador detectara imediatamente erros de sintaxe e validara a estrutura.
2. Escolha sua indentacao: selecione 2 ou 4 espacos, ou clique em Minificar para comprimir o JSON em uma unica linha.
3. Copie o resultado: a saida formatada inclui destaque de sintaxe codificado por cores. Copie-o para usar em seu codigo, arquivo de configuracao ou documentacao.

Uma breve historia do JSON

JSON (JavaScript Object Notation) foi especificado por Douglas Crockford em 2001, formalmente documentado no RFC 4627 (2006), e padronizado como ECMA-404 em 2013 e ISO/IEC 21778 em 2017. Crockford nao inventou o JSON: ele o extraiu de um subconjunto da sintaxe literal de objeto JavaScript que ja estava em uso, e deu a ele um nome e uma especificacao de uma pagina em json.org.

JSON rapidamente deslocou XML para APIs web porque e dramaticamente mais simples. Uma resposta XML e verbosa com tags de abertura/fechamento; o JSON equivalente tem metade do tamanho. Os navegadores podem analisar JSON nativamente (JSON.parse, JSON.stringify desde ECMAScript 5 em 2009) sem analisador XML necessario.

Em 2015, cada API principal do mundo falava JSON: APIs REST, consultas GraphQL, mensagens WebSocket, arquivos de configuracao (package.json, tsconfig.json, .vscode/settings.json), e ate bancos de dados (PostgreSQL JSONB, MongoDB BSON que e tipo JSON). Tornou-se a lingua franca dos dados estruturados na web.

A simplicidade do JSON e tambem sua limitacao: sem comentarios, sem virgulas finais, sem tipo de data, sem suporte binario. Varias variantes JSON surgiram para abordar essas lacunas (veja «Formatos alternativos tipo JSON» abaixo).

Erros comuns de JSON e como detecta-los

A maioria dos erros JSON se resume a alguns erros comuns:

• Virgulas faltantes ou adicionais: uma virgula apos o ultimo item em um array ou objeto e invalida em JSON (diferente do JavaScript)
• Chaves sem aspas: JSON requer aspas duplas em torno de todas as chaves: "name" nao name
• Aspas simples: JSON so aceita aspas duplas: "value" nao 'value'
• Virgulas finais: {"a": 1,} e invalido; remova a virgula apos a ultima entrada
• Comentarios: JSON nao suporta comentarios // linha ou /* bloco */; a maioria dos analisadores os rejeita
• Undefined / NaN / Infinity: JSON so permite numeros, strings, booleanos, null, arrays e objetos. Valores JavaScript como undefined, NaN ou Infinity nao sao validos
• Valores de funcao: uma referencia de funcao nao pode aparecer em JSON
• Numeros hexadecimais ou octais: apenas numeros decimais sao validos (0xFF e 0o17 nao sao)
• Zeros iniciais: 01 e invalido em JSON; use 1
• Escapes hexadecimais: apenas escapes Unicode \u sao permitidos em strings, nao \x ou \0
• Chaves duplicadas: tecnicamente validas pela especificacao, mas a maioria dos analisadores silenciosamente usa o ultimo valor; conte com isso por sua propria conta e risco
• BOM UTF-8: uma marca de ordem de bytes no inicio de um arquivo nao e JSON valido e quebra analisadores estritos
• Espaco em branco ou conteudo final: qualquer texto apos o ] ou } de fechamento torna o documento invalido

Um bom formatador destaca exatamente onde o erro esta, para que voce possa corrigi-lo imediatamente em vez de adivinhar.

Tipos de dados JSON

JSON tem exatamente 6 tipos de dados:

Notavelmente faltando: datas (use strings ISO 8601), dados binarios (use strings Base64), comentarios (use um campo de documentacao separado), e bigint (numeros JSON sao de precisao dupla; valores >= 2^53 perdem precisao).

Quando formatar vs minificar

Formatar (pretty-print) quando voce precisa:

• Ler e entender os dados
• Depurar respostas API
• Editar arquivos de configuracao
• Compartilhar JSON com colegas
• Fazer commit no controle de versao (diffs mais limpos)

Minificar quando voce precisa:

• Enviar dados por uma rede (carga util menor = transferencia mais rapida)
• Armazenar JSON em um banco de dados ou log onde a legibilidade nao importa
• Incorporar JSON em um parametro URL ou campo de formulario
• Gerar respostas API compactas

A diferenca de tamanho e significativa: um JSON tipico de 50 KB pretty-printed minifica para cerca de 30 KB. Para APIs de alto trafego, respostas minificadas economizam largura de banda. Para arquivos editados por humanos, formatado e essencial.

Formatos alternativos tipo JSON

Quando a rigidez do JSON e um problema, varias variantes relaxam as regras:

Para intercambio de dados (respostas API, configuracao), mantenha-se com JSON estrito. Para configuracao editada por humanos, JSON5 ou JSONC sao mais amigaveis. Para streaming de dados, NDJSON e o padrao de facto.

Armadilhas comuns

• Numeros perdendo precisao: numeros JSON sao doubles IEEE 754. Inteiros maiores que 2^53 (9.007.199.254.740.992) perdem precisao. Transmita IDs grandes como strings ("id": "12345678901234567890").
• Escapes Unicode mutilados por editores: alguns editores convertem caracteres automaticamente ao salvar, o que pode fazer com que os analisadores se comportem de forma inesperada. Use UTF-8 em todo lugar.
• Pretty-print de datas incorretamente: datas como strings ISO 8601 ("2026-05-20T13:00:00Z") sao padrao. Evite timestamps Unix como strings; eles parecem numeros, mas geralmente sao destinados a serem datas.
• Espaco em branco em chaves: {"first name": "..."} e JSON valido, mas quebra muitos ORMs e geradores de codigo que esperam chaves seguras como identificadores.
• Valores vazios vs chaves faltantes: {"a": null} e {} (sem a em absoluto) sao coisas diferentes. Escolha uma convencao e documente-a.
• Incompatibilidade de bigint: colunas bigint PostgreSQL serializadas como numeros JSON podem perder precisao. Use strings para IDs acima de 2^53.
• Nova linha final: algumas ferramentas adicionam uma nova linha final apos a chave de fechamento; alguns analisadores estritos a rejeitam. JSON-stringify nao produz nova linha final.
• Incompatibilidade de codificacao: a especificacao JSON requer UTF-8 (ou UTF-16/UTF-32 com BOM). Latin-1 com caracteres nao-ASCII falha. Sempre serialize como UTF-8.
• JSON stringificado em JSON: caracteres de escape aninhados ficam ingerenciaveis rapidamente. Aninhe o objeto diretamente ou escolha uma convencao JSON codificada em base64.
• Comentarios no arquivo de origem: se voce fizer commit de JSONC ou JSON5 em um sistema que espera JSON estrito, a analise falha. Converta para JSON estrito em sua etapa de build.

Dicas para trabalhar com JSON

• Valide antes de enviar: se voce esta construindo uma solicitacao API manualmente, cole seu JSON em um validador primeiro. Uma virgula mal colocada pode causar erros confusos no lado do servidor.
• Use indentacao de 2 espacos para dados profundamente aninhados. Mantem as linhas mais curtas e a estrutura mais facil de escanear.
• Adicione a ferramenta aos favoritos: se voce trabalha com JSON regularmente, ter um formatador a um clique de distancia economiza tempo em comparacao com procurar um a cada vez.
• Use jq para trabalho de linha de comando: jq (e as alternativas de linguagem jq como gron, dasel, yq) sao essenciais para filtrar e transformar JSON na linha de comando.
• Use um esquema JSON para validacao: para formatos importantes (contratos de API, arquivos de configuracao), defina um Esquema JSON e valide contra ele. Ferramentas como ajv (JavaScript), python-jsonschema ou a validacao de esquema integrada do VS Code previnem erros de forma.
• Use Postman ou Insomnia para solicitacoes API: essas ferramentas tem formatadores e validadores JSON integrados, destaque de sintaxe e historico de solicitacoes.
• Execute JSON atraves do prettier em sua base de codigo: o Prettier formata JSON de forma consistente; integre-o como um hook pre-commit para que a formatacao nunca seja uma preocupacao de revisao de codigo.
• Para diff, classifique as chaves primeiro: chaves de objeto JSON nao sao ordenadas. Um diff de {"a":1,"b":2} vs {"b":2,"a":1} mostra que tudo mudou, a menos que voce classifique as chaves primeiro. Use jq -S ou similar.

Privacidade e JSON confidencial

O formatador JSON roda inteiramente no seu navegador. O JSON que voce cola, o processamento intermediario e a saida formatada ficam todos no seu dispositivo. Nada e enviado para um servidor, registrado ou compartilhado com ninguem.

Isso importa porque JSON frequentemente contem dados extremamente sensiveis: respostas API com registros de clientes e enderecos de e-mail, tokens de autenticacao e dados de sessao, esquemas API internos que revelam a arquitetura do produto, arquivos de configuracao com senhas de banco de dados, dados financeiros de APIs de contabilidade, registros medicos de APIs FHIR, estrutura interna da empresa de APIs de RH, cargas uteis de depuracao com rastreamentos de pilha revelando infraestrutura. Formatadores JSON em nuvem registram cada colagem em seus logs de solicitacao, as vezes os retem para «melhoria do servico», e estiveram envolvidos em incidentes reais onde respostas API coladas vazaram dados de clientes e chaves API. Um formatador baseado em navegador tem exposicao zero: o JSON nunca sai da sua maquina.

A formatacao baseada em navegador tambem funciona offline depois que a pagina e carregada, util para formatar JSON em avioes, em ambientes seguros sem acesso a internet, ou em qualquer lugar onde voce nao pode ou nao deveria colar dados API (especialmente com credenciais incorporadas) em um servico de terceiros.