JSON Formatter and Validator

Continue in the tool

More pages for this tool

json big number precision loss

Big numbers in JSON lose precision: the 2^53 limit and how to avoid it

Paste the JSON with the suspect id or decimal: every number that JavaScript cannot store exactly gets a warning with the value it would read, and the output text keeps the original digits. In the tree, the number gets a precision flag.

Why JavaScript changes the number and JSON does not

The JSON format puts no limit on the size of a number: 12345678901234567890 is valid text. The problem shows up in whoever reads it. JavaScript stores every number as a 64-bit IEEE 754 double, which has 53 bits of precision for the digits, and so represents every integer exactly only up to 9007199254740991, the value of Number.MAX_SAFE_INTEGER, or 2^53 - 1. Above that, doubles are spaced 2 apart, then 4, and so on, and several neighboring integers become the same number. RFC 8259 itself warns that interoperability is good when implementations expect no more precision or range than a double provides.
In practice, 9007199254740993 is read as 9007199254740992, and 12345678901234567890 is read as 12345678901234567168. The classic case is 64-bit ids, such as the "snowflake" ones from Twitter/X and Discord: that is why those APIs also return the id as a string. Decimals suffer in a similar way: a value with more than 15 to 17 significant digits, such as 0.1234567890123456789, is rounded to 0.12345678901234568. And an exponent that is too large, such as 1e999, becomes Infinity, which in turn cannot be written back to JSON. The formatter tells the cases apart: unsafe integer (saying whether the double still represents the exact value, as happens with 2^60), decimal with lost digits, and overflow.
Formatting here corrupts nothing, because the parser keeps the original text of each number and writes the same digits to the output; the loss only happens when another JavaScript program reads the text. To avoid the problem, carry long ids and values that need full exactness, such as card or document numbers, as strings; for money, use integer cents or decimal strings. In modern JavaScript the read can use BigInt through a parser that supports it, but the native JSON.parse always returns a double. If the value goes past 2^53 - 1, treat the field as text from the source.

Numbers tested in the formatter

2^53 + 1

Input: {"id": 9007199254740993}
Expected output: aviso na coluna 8: o JavaScript lê 9007199254740992

The output text keeps 9007199254740993.

20-digit id

Input: {"id": 12345678901234567890}
Expected output: aviso na coluna 8: o JavaScript lê 12345678901234567168

The last digits are lost on read.

Last safe integer

Input: {"id": 9007199254740991}
Expected output: sem aviso

Number.MAX_SAFE_INTEGER is exact.

19-digit decimal

Input: {"x": 0.1234567890123456789}
Expected output: aviso na coluna 7: o JavaScript lê 0.12345678901234568

Precision loss in a decimal.

Exponent too large

Input: {"x": 1e999}
Expected output: aviso na coluna 7: o JavaScript lê Infinity

Overflow of the largest double.

2^60, exact but unsafe

Input: {"id": 1152921504606846976}
Expected output: aviso na coluna 8: representado exatamente, mas vizinhos colidem

Powers of 2 fit in a double.

Full tool FAQ

Why does my JSON give "Unexpected token" and where is the error?

The most common causes are a comma after the last item, single quotes, an unquoted key, a comment, and a missing comma between two values. JSON.parse reports only the first problem and, in some browsers, only a character position. This formatter lists every error in the text, each with line and column, shows the snippet with an arrow under the exact spot, marks the line in the editor margin, and has a Go to the error button that selects the spot.

Can JSON have comments or a trailing comma?

Do single quotes work in JSON? What about a Python dict?

What does Repair mode do and what are its limits?

What happens when the JSON has the same key twice?

Why does a big number change after going through JavaScript?

Does sorting keys or minifying change what the JSON means?

How do I validate a JSON Lines or NDJSON file?

Which query syntax is supported?

Is my JSON sent to any server? What about large files?

Frequently asked questions

What is the largest safe integer in JavaScript?

It is 9007199254740991, or 2^53 - 1, exposed as Number.MAX_SAFE_INTEGER. Up to that value every integer has a unique representation; above it, different numbers can be read as the same one.

Does JSON itself limit the size of numbers?

No. The grammar accepts any number of digits. The limit comes from implementations, and RFC 8259 recommends not expecting more precision than an IEEE 754 double offers when interoperability matters.

How do I send a 64-bit id without losing digits?

Send it as a string: "id": "1234567890123456789". The JavaScript receiver keeps the text, and whoever needs arithmetic converts it to BigInt. That is why several APIs offer an id_str field next to the numeric one.

Does formatting or minifying here change those numbers?

No. The formatter keeps the original text of each number and writes the same digits, including trailing zeros as in 1.50. The warning exists so you know the next JavaScript program will round.

Next steps

Why JavaScript changes the number and JSON does not

The JSON format puts no limit on the size of a number: 12345678901234567890 is valid text. The problem shows up in whoever reads it. JavaScript stores every number as a 64-bit IEEE 754 double, which has 53 bits of precision for the digits, and so represents every integer exactly only up to 9007199254740991, the value of Number.MAX_SAFE_INTEGER, or 2^53 - 1. Above that, doubles are spaced 2 apart, then 4, and so on, and several neighboring integers become the same number. RFC 8259 itself warns that interoperability is good when implementations expect no more precision or range than a double provides.

In practice, 9007199254740993 is read as 9007199254740992, and 12345678901234567890 is read as 12345678901234567168. The classic case is 64-bit ids, such as the "snowflake" ones from Twitter/X and Discord: that is why those APIs also return the id as a string. Decimals suffer in a similar way: a value with more than 15 to 17 significant digits, such as 0.1234567890123456789, is rounded to 0.12345678901234568. And an exponent that is too large, such as 1e999, becomes Infinity, which in turn cannot be written back to JSON. The formatter tells the cases apart: unsafe integer (saying whether the double still represents the exact value, as happens with 2^60), decimal with lost digits, and overflow.

Formatting here corrupts nothing, because the parser keeps the original text of each number and writes the same digits to the output; the loss only happens when another JavaScript program reads the text. To avoid the problem, carry long ids and values that need full exactness, such as card or document numbers, as strings; for money, use integer cents or decimal strings. In modern JavaScript the read can use BigInt through a parser that supports it, but the native JSON.parse always returns a double. If the value goes past 2^53 - 1, treat the field as text from the source.

Numbers tested in the formatter

2^53 + 1

Input: {"id": 9007199254740993}
Expected output: aviso na coluna 8: o JavaScript lê 9007199254740992

The output text keeps 9007199254740993.

20-digit id

Input: {"id": 12345678901234567890}
Expected output: aviso na coluna 8: o JavaScript lê 12345678901234567168

The last digits are lost on read.

Last safe integer

Input: {"id": 9007199254740991}
Expected output: sem aviso

Number.MAX_SAFE_INTEGER is exact.

19-digit decimal

Input: {"x": 0.1234567890123456789}
Expected output: aviso na coluna 7: o JavaScript lê 0.12345678901234568

Precision loss in a decimal.

Exponent too large

Input: {"x": 1e999}
Expected output: aviso na coluna 7: o JavaScript lê Infinity

Overflow of the largest double.

2^60, exact but unsafe

Input: {"id": 1152921504606846976}
Expected output: aviso na coluna 8: representado exatamente, mas vizinhos colidem

Powers of 2 fit in a double.

Full tool FAQ

Why does my JSON give "Unexpected token" and where is the error?

Can JSON have comments or a trailing comma?

Do single quotes work in JSON? What about a Python dict?

What does Repair mode do and what are its limits?

What happens when the JSON has the same key twice?

Why does a big number change after going through JavaScript?

Does sorting keys or minifying change what the JSON means?

How do I validate a JSON Lines or NDJSON file?

Which query syntax is supported?

Is my JSON sent to any server? What about large files?

Frequently asked questions

What is the largest safe integer in JavaScript?

It is 9007199254740991, or 2^53 - 1, exposed as Number.MAX_SAFE_INTEGER. Up to that value every integer has a unique representation; above it, different numbers can be read as the same one.

Does JSON itself limit the size of numbers?

No. The grammar accepts any number of digits. The limit comes from implementations, and RFC 8259 recommends not expecting more precision than an IEEE 754 double offers when interoperability matters.

How do I send a 64-bit id without losing digits?

Does formatting or minifying here change those numbers?

No. The formatter keeps the original text of each number and writes the same digits, including trailing zeros as in 1.50. The warning exists so you know the next JavaScript program will round.