Formatador e Minificador JSON

Formatador JSON - Formatar e Validar JSON Online

Ferramenta poderosa de formatador e validador JSON online que ajuda você a formatar, embelezar, minificar e validar dados JSON.

Como o formatador lida com JSON inválido?

O formatador primeiro executa sua entrada por uma passagem estrita de JSON.parse. Se o parsing falhar, ele retorna o erro com o deslocamento exato em bytes, linha e coluna do caractere ofensor, mais uma dica sobre a causa provável: vírgula final, aspas simples em vez de duplas, chaves sem aspas, bloco de comentário, ou string não terminada. Ele nunca "corrige" silenciosamente seu JSON, porque isso mascararia bugs reais em produtores a montante. Se você precisa de parsing tolerante para dados escritos à mão (comentários, vírgulas finais, chaves sem aspas), mude para o modo JSON5 ou JSONC onde disponível — mas entenda que a saída desses modos não é mais JSON ECMA-404 e pode ser rejeitada por consumidores a jusante. O parser estrito está conforme com RFC 8259 e ECMA-404, os dois padrões equivalentes que definem JSON.

Qual a diferença entre JSON, JSON5, JSONC e NDJSON?

JSON (RFC 8259 / ECMA-404) é o formato canônico estrito: chaves entre aspas duplas, sem comentários, sem vírgulas finais. JSONC ("JSON com comentários") é a variante VS Code que permite comentários // e /* */; é usado para tsconfig.json e arquivos de configuração. JSON5 é um superconjunto mais rico que adiciona chaves identificador ECMAScript sem aspas, aspas simples, strings multilinha, números hexadecimais, pontos decimais iniciais/finais, +Infinity, NaN e vírgulas finais. NDJSON (JSON delimitado por nova linha) é um formato de streaming onde cada linha é um valor JSON completo, usado para arquivos de log, conjuntos de dados de aprendizado de máquina e fluxos de API. NÃO são intercambiáveis: um parser JSON estrito rejeitará JSONC e JSON5. Escolha conforme o consumidor: APIs quase sempre exigem JSON estrito.

Por que meu JSON contém de repente números como 9999999999999999 virando 10000000000000000?

JSON em si não impõe limite à precisão numérica, mas a maioria dos parsers — incluindo JSON.parse do JavaScript — armazena números como floats IEEE 754 de precisão dupla, que podem representar exatamente apenas inteiros até 2^53 - 1 (cerca de 9,007 quatrilhões, ou Number.MAX_SAFE_INTEGER). Inteiros maiores são silenciosamente arredondados para o double representável mais próximo. Isso afeta APIs que retornam IDs de 64 bits (snowflakes do Twitter, Discord, chaves primárias BIGINT de bancos de dados) — quando o JavaScript os parseia, os últimos dígitos estão errados. Correções: (1) o servidor deve serializar inteiros grandes como strings; (2) use um parser ciente de BigInt como json-bigint ou o parâmetro reviver de JSON.parse para interceptar o token bruto; (3) parseie manualmente como string.

Devo minificar JSON para APIs em produção?

Sim para endpoints sensíveis ao tamanho, não para todo o resto. Minificar remove todos os espaços em branco (espaços, tabs, quebras de linha em torno de : e ,) e tipicamente economiza 20-40% dos bytes dependendo do comprimento das chaves e distribuição de valores. As economias de transmissão são largamente apagadas uma vez que a compressão HTTP gzip ou Brotli entra em ação — compressores modernos lidam com espaço em branco eficientemente — então o ganho prático sobre transporte comprimido geralmente é menos de 5%. O trade-off: JSON minificado é ilegível em DevTools do navegador e agregadores de log, tornando a depuração em produção mais difícil. Melhor prática: servir JSON formatado em desenvolvimento e em APIs internas, JSON minificado apenas para endpoints públicos de alto tráfego.

Por que o formatador ordena minhas chaves, e posso desligar isso?

A ordenação de chaves é opcional e desligada por padrão nesta ferramenta — a formatação preserva a ordem original de chaves da sua entrada. Alguns workflows se beneficiam de chaves ordenadas: saída determinística para diffs git, JSON canônico para assinatura criptográfica (JCS, RFC 8785) e conflitos de merge reduzidos. Outros workflows dependem da ordem de inserção: schemas OpenAPI onde campos obrigatórios são listados primeiro, registros de log onde o timestamp deve vir primeiro, arquivos de configuração seguindo um template documentado. Objetos JavaScript preservam a ordem de inserção para chaves string conforme ES2015, e JSON.stringify reflete essa ordem; JSON.parse também preserva a ordem no round trip. Se você quiser saída ordenada, a opção "Ordenar chaves" desta ferramenta realiza uma ordenação recursiva profunda usando comparação ciente de locale.

Como encontro um valor ou caminho específico dentro de um arquivo JSON grande?

Para exploração ad-hoc, JSONPath ($..book[?(@.price<10)]) e JMESPath (locations[*].name | sort(@)) são linguagens de consulta projetadas exatamente para isso — ambas têm implementações JavaScript. A ferramenta de linha de comando jq é a opção mais poderosa para pipelines shell: jq '.users[] | select(.age > 30) | .name' filtra e projeta em uma expressão. Para navegação em árvore neste formatador, use os nós colapsáveis para drill in visualmente, depois use Ctrl+F para busca de texto. Para arquivos verdadeiramente massivos (acima de 100 MB), evite carregar o documento inteiro na memória — use parsers de streaming como Node.js stream-json, Python ijson, ou Decoder do Go encoding/json para processar tokens um a um. Indexar em um banco de dados (SQLite JSON1, Postgres JSONB) é a resposta certa quando um arquivo é consultado repetidamente.

Por que meu parser rejeita chaves duplicadas em um objeto?

RFC 8259 diz que o comportamento é definido pela implementação: "Os nomes dentro de um objeto DEVERIAM ser únicos". A maioria dos parsers não levanta erro; eles silenciosamente mantêm o último valor visto (JSON.parse do JavaScript), ou o primeiro (algumas bibliotecas Go com unmarshalers customizados), ou os mesclam (raro). Essa ambiguidade é uma fonte real de bugs e questões de segurança — veja Vulnerabilidades de Interoperabilidade JSON (padrões CVE em HTTP smuggling e verificação JWT). A prática mais segura é rejeitar duplicatas: o modo estrito desta ferramenta levanta um erro claro e aponta para a segunda ocorrência para que você possa corrigir o produtor. Se você deve tolerar duplicatas por razões históricas, documente qual valor vence e teste unitariamente. JCS (RFC 8785) proíbe totalmente chaves duplicadas.

Como escapo caracteres especiais como nova linha, tab ou aspas dentro de uma string JSON?

Strings JSON usam um pequeno conjunto de escapes com barra invertida definidos na RFC 8259 seção 7: \" para aspas duplas, \\ para barra invertida, \/ para barra (opcional), \b para backspace, \f para form feed, \n para nova linha, \r para retorno de carro, \t para tab, e \uXXXX para qualquer ponto de código Unicode até U+FFFF. Pontos de código acima de U+FFFF (emoji, CJK raros) usam um par substituto UTF-16: \uD83D\uDE00 para 😀. Caracteres de controle U+0000 a U+001F DEVEM ser escapados — um byte de nova linha literal dentro de uma string JSON é inválido. O escape de barra é permitido mas não exigido; muitas ferramentas o escapam dentro de </script> para defender contra injeção HTML quando o JSON é embutido em tags <script>. Este formatador preserva seu estilo de escape no round trip e oferece uma opção de normalização.

Recursos Principais

• Formatar JSON com indentação personalizável
• Minificar JSON para reduzir tamanho
• Validar sintaxe JSON
• Ordenar chaves alfabeticamente