A integração falha, o log mostra Unexpected token } in JSON at position 1847, e começa a caçada. Você abre o payload, vai até a posição 1847, e a chave que está ali parece perfeitamente correta — porque ela está. O erro foi causado em outro lugar.
Entender como o parser reporta o problema encurta muito essa caçada. E conhecer o conjunto pequeno de coisas que o JSON não aceita, apesar de parecerem naturais, evita a maior parte dos erros antes que aconteçam.
Por que a posição do erro engana
O parser lê a entrada da esquerda para a direita mantendo uma pilha do que está aberto. Ele não valida a estrutura inteira de uma vez: ele acusa erro no primeiro caractere que não pode ocupar aquela posição dado o que veio antes.
{
"cliente": {
"nome": "Maria", <- a chave aberta aqui nunca fecha
"pedidos": [
{ "id": 1, "total": 99.9 },
{ "id": 2, "total": 12.5 }
]
} <- o parser só percebe aquiA chave de cliente ficou sem fechamento. O parser segue lendo normalmente, porque tudo que vem depois é sintaticamente válido dentro de um objeto aberto. Só no final, quando encontra o fim da entrada com um objeto ainda na pilha, ele acusa. A posição reportada fica dezenas de linhas depois da causa.
As cinco causas mais comuns
1. Vírgula sobrando antes do fechamento
É o campeão absoluto. JavaScript, Python e a maioria das linguagens modernas aceitam a vírgula final em literais; JSON não. O erro aparece quando alguém edita um payload à mão e remove o último item sem tirar a vírgula do anterior.
{
"nome": "Maria",
"idade": 34, <- vírgula sem item seguinte
}2. Aspas simples
Copiar um objeto do código JavaScript e colar como JSON traz aspas simples e, com frequência, chaves sem aspas nenhuma. Ambas são válidas na linguagem e inválidas no formato.
// JavaScript válido, JSON inválido
{ nome: 'Maria', ativo: true }
// JSON válido
{ "nome": "Maria", "ativo": true }3. Valores que não existem em JSON
A especificação define seis tipos: objeto, array, string, número, booleano e null. Tudo além disso quebra — e o problema aparece principalmente na serialização, não na escrita manual.
| Valor | Origem comum | O que acontece |
|---|---|---|
| NaN | Divisão inválida, parse de número falho | Serializa como null ou lança erro |
| Infinity | Divisão por zero | Serializa como null |
| undefined | Propriedade não atribuída | A chave desaparece do resultado |
| Date | Objeto de data | Vira string ISO na serialização, não volta como Date |
| BigInt | Identificador grande | Lança erro na serialização |
| function | Método em objeto | A chave desaparece silenciosamente |
As duas linhas que somem silenciosamente — undefined e function — são as mais perigosas. Nenhum erro é lançado; o campo simplesmente não chega ao outro lado, e o bug aparece como valor ausente numa camada distante.
4. Comentários
Arquivos de configuração em JSON convidam ao comentário, e a especificação não os aceita. Se o seu caso de uso pede configuração comentada, o formato errado foi escolhido: YAML e TOML resolvem isso nativamente. Quando trocar não é opção, a convenção é uma chave de comentário no próprio objeto.
5. Caracteres de controle e BOM
Uma quebra de linha literal dentro de uma string precisa ser escapada como \\n. E um arquivo salvo com marca de ordem de bytes começa com um caractere invisível que o parser encontra antes da primeira chave, produzindo um erro na posição 0 que não faz sentido nenhum ao olhar o arquivo.
O que JSON aceita e surpreende
Do outro lado, algumas coisas são válidas apesar de parecerem erradas.
- O documento não precisa ser um objeto: 42, "texto" e true são JSON válidos por si sós.
- Chaves duplicadas não são erro de sintaxe; o comportamento fica a critério do parser, e a maioria mantém a última ocorrência.
- A ordem das chaves não tem significado semântico, ainda que os parsers geralmente a preservem.
- Não há limite de profundidade na especificação, mas parsers impõem um para evitar estouro de pilha.
- Um número pode ter expoente: 1.2e10 é válido.
Um método de depuração
- 1Formate o documento com indentação. Boa parte dos erros estruturais fica visível quando o nível de aninhamento não volta ao esperado.
- 2Se o erro aponta para o fim, procure uma abertura sem fechamento acima, não um problema no ponto indicado.
- 3Se aponta para o começo, suspeite de BOM ou de caractere invisível antes da primeira chave.
- 4Corte o documento pela metade e valide cada parte; duas ou três iterações isolam o trecho problemático mesmo em payloads grandes.
- 5Confira a origem: se o JSON foi gerado por concatenação de strings, o problema quase certamente é escape de aspas dentro de valores.
- 6Se foi gerado por serializador, procure por NaN, undefined e datas no objeto de origem.
O passo cinco merece destaque: montar JSON concatenando texto é a origem de uma classe inteira de erros que desaparece ao usar o serializador da linguagem. Se o código do seu lado constrói JSON com template string, esse é o bug, mesmo que o sintoma pareça outro.
Onde a ferramenta ajuda
O JSON Formatter do Codigio Labs aponta a posição do erro, aplica indentação e mostra a estrutura em árvore, o que torna imediato ver onde um nível não fechou. O processamento acontece no navegador, então dá para inspecionar um payload interno sem colá-lo em um serviço de terceiros — o que importa quando o documento carrega token, chave ou dado de cliente.
Resumo
- A posição do erro é onde o parser detectou, não onde a causa está; abertura sem par é reportada no fim.
- Vírgula sobrando e aspas simples respondem pela maioria dos erros escritos à mão.
- NaN, Infinity, undefined e function não têm representação; os dois últimos somem sem erro.
- Comentários não existem em JSON — se você precisa deles, o formato escolhido foi o errado.
- Números acima de 2^53 perdem precisão silenciosamente: trafegue identificadores como texto.