Formatador e Validador de JSON para Feeds e APIs

Você cola um JSON (resposta de API, feed de produto, arquivo de configuração) e recebe a versão indentada ou minificada, ou a mensagem de erro do navegador apontando onde a sintaxe quebrou, para quem integra loja, marketplace e ERP.

O que é o Formatador de JSON?

O JSON (JavaScript Object Notation) é o formato de troca de dados mais usado em APIs e aplicações web. Minificado, ele é difícil de ler — esta ferramenta formata com indentação de 2 espaços para facilitar a leitura e depuração.

Como usar

Cole seu JSON no campo da esquerda e clique em Formatar para aplicar indentação legível, ou em Minificar para compactar e reduzir o tamanho. Se o JSON tiver erros de sintaxe, a mensagem de erro aparecerá à direita indicando a posição do problema.

Validação de erros

A validação usa JSON.parse() nativo do navegador — o mesmo motor que qualquer API JavaScript usa. Erros comuns incluem aspas simples no lugar de duplas, vírgula após o último item, e chaves/colchetes não fechados.

Quando usar e quando não usar

Use para ler uma resposta de API que chegou em linha única, para achar a vírgula que derrubou o feed de produtos e para minificar um trecho antes de colar em um campo que não aceita quebra de linha. É o primeiro teste quando o marketplace responde apenas "arquivo inválido".

A ferramenta valida sintaxe, não conteúdo. Um JSON perfeito aqui ainda pode ser recusado pelo Merchant Center por falta de um campo obrigatório ou por preço em formato de texto; essa conferência é feita contra a especificação de cada plataforma. Arquivos de dezenas de megabytes também não são o caso de uso: colados em um campo de texto, deixam a aba lenta. Para esses, prefira uma ferramenta de linha de comando como o jq.

Exemplo: o erro e a formatação

Trecho de feed com a vírgula sobrando depois do último campo, o erro mais comum em JSON montado por concatenação:

{"sku": "7891000100103", "preco": 21.98,}

Ao clicar em Formatar, o Chrome devolve:

Erro de sintaxe: Expected double-quoted property name in JSON at position 40 (line 1 column 41)

A posição 40 é exatamente o } que veio depois da vírgula: o parser esperava o nome de mais uma propriedade. A mensagem vem do motor JavaScript do navegador, em inglês, e muda de redação entre Chrome, Firefox e Safari; a indicação de linha e coluna depende dessa versão.

Com a vírgula removida e um bloco de estoque acrescentado, a entrada {"sku":"7891000100103","preco":21.98,"estoque":{"loja_12":40,"cd":1200}} sai assim:

{
  "sku": "7891000100103",
  "preco": 21.98,
  "estoque": {
    "loja_12": 40,
    "cd": 1200
  }
}

O que acontece por baixo

O texto é lido com JSON.parse, o parser nativo do navegador, que segue a especificação estrita do formato: chaves e textos entre aspas duplas, nenhuma vírgula no fim de lista, nenhum comentário. Se a leitura der certo, o objeto é escrito de volta com JSON.stringify, com recuo de dois espaços para Formatar e sem espaço algum para Minificar.

Por ser uma releitura e não uma simples troca de espaços, o resultado normaliza alguns detalhes. O número 21.90 sai como 21.9. Se a mesma chave aparece duas vezes no objeto, só o último valor sobrevive. Chaves que são números inteiros, como "10" e "2", vão para o início do objeto em ordem crescente. E números inteiros acima de 9.007.199.254.740.991 perdem precisão: 12345678901234567890 vira 12345678901234567000.

Limitações

  • Valida apenas sintaxe; não há validação contra JSON Schema nem contra a especificação de feed de nenhuma plataforma.
  • Não aceita JSON5 nem variantes com comentários ou aspas simples.
  • IDs numéricos muito longos perdem os últimos dígitos na saída. Se o sistema de origem manda pedido ou código longo como número, confira no original.
  • O recuo é fixo em dois espaços e a ordem das chaves inteiras muda, como descrito acima.
  • Arquivos grandes deixam a aba lenta, porque tudo é processado na memória do navegador.

Privacidade

O JSON não é enviado ao servidor. Isso importa porque resposta de API costuma trazer token, e-mail e CPF de cliente: aqui o processamento é local e o conteúdo desaparece ao fechar a página. Mesmo assim, apague credenciais do trecho antes de compartilhar a tela ou o resultado.

Para continuar

Como Usar o Formatador de JSON para Debugar APIs de E-commerce segue um incidente do erro à correção, e JSON em Feeds de Produto trata da estrutura do feed entre ERP e marketplace. Quando o dado vem de planilha, o Conversor CSV ↔ JSON faz a ponte; se o payload chega codificado, o Base64 Encoder/Decoder revela o conteúdo antes da formatação.

Perguntas frequentes

Por que o validador aceita um JSON que minha API recusa?

Porque esta ferramenta confere a sintaxe do formato, não as regras do seu sistema. Campo obrigatório ausente, preço enviado como texto ou data em formato errado passam aqui e são recusados pela API. Compare o JSON com a documentação ou o schema da plataforma.

Por que o número 21.90 virou 21.9?

O JSON é lido como dado e escrito de novo, e zeros à direita da parte decimal não fazem parte do valor numérico. Se o sistema de destino exige duas casas, envie o preço como texto ou formate na saída do sistema, não no JSON.

Por que a ordem das chaves mudou depois de formatar?

No JavaScript, chaves que são números inteiros, como "10" ou "2", ficam sempre no início do objeto e em ordem crescente. As demais mantêm a ordem original. A especificação do JSON não dá significado à ordem das chaves, então o dado é o mesmo.

JSON aceita comentários?

Não. A especificação do JSON não prevê comentários, e o parser do navegador recusa // e /* */. Arquivos de configuração que aceitam comentário usam variantes como JSON5 ou JSONC, que esta ferramenta não lê.

Por que um ID numérico longo mudou nos últimos dígitos?

Números no JavaScript têm precisão exata só até 9.007.199.254.740.991. Um ID como 12345678901234567890 é arredondado ao ser lido. Por isso sistemas que trocam IDs longos costumam enviá-los como texto, entre aspas.

Como Usamos Isso na NuAto

Cenário: Depuração de Feed JSON de 50.000 Produtos para Google Shopping

Uma plataforma de marketplace de varejo de moda com 50.000 SKUs ativos enfrentava uma queda inexplicável de 34% nas impressões do Google Shopping em um único fim de semana. A investigação inicial no Merchant Center apontava erro genérico de "feed inválido" sem especificar qual produto ou campo causava a rejeição. O feed era gerado automaticamente por um script Python toda madrugada, exportando dados do banco de produtos para um arquivo JSON de aproximadamente 28 MB. Aparentemente nada havia mudado no script, mas o feed estava sendo rejeitado parcialmente — o Google aceitava os primeiros registros e descartava silenciosamente todo o restante.

Copiamos os primeiros 500 registros do feed para o Formatador JSON e imediatamente identificamos o problema: o campo description de um produto específico (registro #312) continha uma aspa dupla não escapada dentro do valor — um produto cujo nome em inglês tinha um apóstrofo que o sistema havia convertido incorretamente. O JSON quebrava exatamente naquele ponto, e tudo que vinha depois era ignorado pelo parser do Google. Sem a formatação visual hierárquica que esta ferramenta oferece, encontrar o erro em 28 MB de JSON compactado em linha única teria levado horas.

A correção no script foi adicionar sanitização adequada do campo description com json_encode() forçando JSON_HEX_APOS e JSON_HEX_QUOT. O feed foi regenerado, validado aqui e submetido manualmente. Em 6 horas os produtos voltaram a aparecer no Shopping, e em 72 horas as impressões retornaram ao nível anterior. A perda estimada de vendas durante o incidente ficou em R$ 180.000 em GMV — um valor que justifica com folga implementar validação de JSON como etapa obrigatória em qualquer pipeline de feed.

Para agências que gerenciam campanhas de Shopping para grandes varejistas, validar o JSON do feed antes de cada push para o Merchant Center deveria ser tão automático quanto salvar um arquivo. Um único caractere fora do lugar pode derrubar semanas de otimização de campanha sem nenhum alerta visível.