Formatador e Validador de JSON

Continuar na ferramenta

Mais páginas desta ferramenta

json número grande perde precisão

Número grande em JSON perde precisão: o limite de 2^53 e como evitar

Cole o JSON com o id ou o decimal suspeito: cada número que o JavaScript não consegue guardar com exatidão recebe um aviso com o valor que ele leria, e o texto de saída mantém os dígitos originais. Na árvore, o número ganha uma marca de precisão.

Por que o JavaScript muda o número e o JSON não

O formato JSON não impõe limite ao tamanho de um número: 12345678901234567890 é um texto válido. O problema aparece em quem lê. O JavaScript guarda todo número como um double IEEE 754 de 64 bits, que tem 53 bits de precisão para os dígitos, e por isso só representa todos os inteiros com exatidão até 9007199254740991, o valor de Number.MAX_SAFE_INTEGER, ou 2^53 - 1. Acima disso os doubles ficam espaçados de 2 em 2, depois de 4 em 4, e assim por diante, e vários inteiros vizinhos viram o mesmo número. A própria RFC 8259 avisa que a interoperabilidade é boa quando as implementações não esperam mais precisão nem alcance que um double oferece.
Na prática, 9007199254740993 é lido como 9007199254740992, e 12345678901234567890 é lido como 12345678901234567168. O caso clássico são ids de 64 bits, como os "snowflake" do Twitter/X e do Discord: por isso essas APIs devolvem também o id como string. Decimais sofrem de forma parecida: um valor com mais de 15 a 17 dígitos significativos, como 0.1234567890123456789, é arredondado para 0.12345678901234568. E um expoente grande demais, como 1e999, vira Infinity, que por sua vez não pode ser escrito de volta em JSON. O formatador distingue os casos: inteiro inseguro (dizendo se o double ainda representa o valor exato, como acontece com 2^60), decimal com dígitos perdidos e estouro.
Formatar aqui não corrompe nada, porque o parser guarda o texto original de cada número e escreve os mesmos dígitos na saída; a perda só acontece quando outro programa em JavaScript ler o texto. Para evitar o problema, trafegue ids longos e valores que precisam de exatidão total, como números de cartão ou de documento, como strings; para dinheiro, use inteiros em centavos ou strings decimais. No JavaScript moderno, a leitura pode usar BigInt por meio de um parser que o suporte, mas o JSON.parse nativo sempre devolve double. Se a conta passa de 2^53 - 1, trate o campo como texto desde a origem.

Números testados no formatador

2^53 + 1

Entrada: {"id": 9007199254740993}
Saída esperada: aviso na coluna 8: o JavaScript lê 9007199254740992

O texto de saída mantém 9007199254740993.

Id de 20 dígitos

Entrada: {"id": 12345678901234567890}
Saída esperada: aviso na coluna 8: o JavaScript lê 12345678901234567168

Os últimos dígitos são perdidos na leitura.

Último inteiro seguro

Entrada: {"id": 9007199254740991}
Saída esperada: sem aviso

Number.MAX_SAFE_INTEGER é exato.

Decimal com 19 dígitos

Entrada: {"x": 0.1234567890123456789}
Saída esperada: aviso na coluna 7: o JavaScript lê 0.12345678901234568

Perda de precisão em decimal.

Expoente grande demais

Entrada: {"x": 1e999}
Saída esperada: aviso na coluna 7: o JavaScript lê Infinity

Estouro do maior double.

2^60, exato mas inseguro

Entrada: {"id": 1152921504606846976}
Saída esperada: aviso na coluna 8: representado exatamente, mas vizinhos colidem

Potências de 2 cabem no double.

FAQ da ferramenta completa

Por que meu JSON dá "Unexpected token" e onde está o erro?

As causas mais comuns são vírgula depois do último item, aspas simples, chave sem aspas, comentário e vírgula faltando entre dois valores. O JSON.parse informa só o primeiro problema e, em alguns navegadores, apenas a posição em caracteres. Este formatador lista todos os erros do texto, cada um com linha e coluna, mostra o trecho com uma seta sob o ponto exato, marca a linha na margem do editor e tem o botão Ir para o erro, que seleciona o trecho.

O JSON pode ter comentários ou vírgula no final?

Aspas simples funcionam em JSON? E o dict do Python?

O que o modo Reparar faz e quais são os limites?

O que acontece quando o JSON tem a mesma chave duas vezes?

Por que um número grande muda depois de passar pelo JavaScript?

Ordenar as chaves ou minificar altera o significado do JSON?

Como validar um arquivo JSON Lines ou NDJSON?

Qual sintaxe de consulta é suportada?

Meu JSON é enviado a algum servidor? E arquivos grandes?

Perguntas frequentes

Qual é o maior inteiro seguro no JavaScript?

É 9007199254740991, ou 2^53 - 1, exposto como Number.MAX_SAFE_INTEGER. Até esse valor todo inteiro tem uma representação única; acima dele, números diferentes podem ser lidos como o mesmo.

O JSON em si limita o tamanho dos números?

Não. A gramática aceita qualquer quantidade de dígitos. O limite vem das implementações, e a RFC 8259 recomenda não esperar mais precisão do que um double IEEE 754 oferece quando a interoperabilidade importa.

Como enviar um id de 64 bits sem perder dígitos?

Envie como string: "id": "1234567890123456789". O receptor em JavaScript guarda o texto, e quem precisa de aritmética converte para BigInt. É por isso que várias APIs oferecem o campo id_str ao lado do numérico.

Formatar ou minificar aqui altera esses números?

Não. O formatador guarda o texto original de cada número e escreve os mesmos dígitos, inclusive os zeros finais, como em 1.50. O aviso existe para você saber que o próximo programa em JavaScript vai arredondar.

Próximos passos

Por que o JavaScript muda o número e o JSON não

O formato JSON não impõe limite ao tamanho de um número: 12345678901234567890 é um texto válido. O problema aparece em quem lê. O JavaScript guarda todo número como um double IEEE 754 de 64 bits, que tem 53 bits de precisão para os dígitos, e por isso só representa todos os inteiros com exatidão até 9007199254740991, o valor de Number.MAX_SAFE_INTEGER, ou 2^53 - 1. Acima disso os doubles ficam espaçados de 2 em 2, depois de 4 em 4, e assim por diante, e vários inteiros vizinhos viram o mesmo número. A própria RFC 8259 avisa que a interoperabilidade é boa quando as implementações não esperam mais precisão nem alcance que um double oferece.

Na prática, 9007199254740993 é lido como 9007199254740992, e 12345678901234567890 é lido como 12345678901234567168. O caso clássico são ids de 64 bits, como os "snowflake" do Twitter/X e do Discord: por isso essas APIs devolvem também o id como string. Decimais sofrem de forma parecida: um valor com mais de 15 a 17 dígitos significativos, como 0.1234567890123456789, é arredondado para 0.12345678901234568. E um expoente grande demais, como 1e999, vira Infinity, que por sua vez não pode ser escrito de volta em JSON. O formatador distingue os casos: inteiro inseguro (dizendo se o double ainda representa o valor exato, como acontece com 2^60), decimal com dígitos perdidos e estouro.

Formatar aqui não corrompe nada, porque o parser guarda o texto original de cada número e escreve os mesmos dígitos na saída; a perda só acontece quando outro programa em JavaScript ler o texto. Para evitar o problema, trafegue ids longos e valores que precisam de exatidão total, como números de cartão ou de documento, como strings; para dinheiro, use inteiros em centavos ou strings decimais. No JavaScript moderno, a leitura pode usar BigInt por meio de um parser que o suporte, mas o JSON.parse nativo sempre devolve double. Se a conta passa de 2^53 - 1, trate o campo como texto desde a origem.

Números testados no formatador

2^53 + 1

Entrada: {"id": 9007199254740993}
Saída esperada: aviso na coluna 8: o JavaScript lê 9007199254740992

O texto de saída mantém 9007199254740993.

Id de 20 dígitos

Entrada: {"id": 12345678901234567890}
Saída esperada: aviso na coluna 8: o JavaScript lê 12345678901234567168

Os últimos dígitos são perdidos na leitura.

Último inteiro seguro

Entrada: {"id": 9007199254740991}
Saída esperada: sem aviso

Number.MAX_SAFE_INTEGER é exato.

Decimal com 19 dígitos

Entrada: {"x": 0.1234567890123456789}
Saída esperada: aviso na coluna 7: o JavaScript lê 0.12345678901234568

Perda de precisão em decimal.

Expoente grande demais

Entrada: {"x": 1e999}
Saída esperada: aviso na coluna 7: o JavaScript lê Infinity

Estouro do maior double.

2^60, exato mas inseguro

Entrada: {"id": 1152921504606846976}
Saída esperada: aviso na coluna 8: representado exatamente, mas vizinhos colidem

Potências de 2 cabem no double.

FAQ da ferramenta completa

Por que meu JSON dá "Unexpected token" e onde está o erro?

O JSON pode ter comentários ou vírgula no final?

Aspas simples funcionam em JSON? E o dict do Python?

O que o modo Reparar faz e quais são os limites?

O que acontece quando o JSON tem a mesma chave duas vezes?

Por que um número grande muda depois de passar pelo JavaScript?

Ordenar as chaves ou minificar altera o significado do JSON?

Como validar um arquivo JSON Lines ou NDJSON?

Qual sintaxe de consulta é suportada?

Meu JSON é enviado a algum servidor? E arquivos grandes?

Perguntas frequentes

Qual é o maior inteiro seguro no JavaScript?

É 9007199254740991, ou 2^53 - 1, exposto como Number.MAX_SAFE_INTEGER. Até esse valor todo inteiro tem uma representação única; acima dele, números diferentes podem ser lidos como o mesmo.