If the last digit of an ID changes after you format JSON, stop before copying the result into another system. A document can have valid JSON syntax while a parser changes the value of a large number. Save the untouched input, identify the field’s required type, and compare its digits before accepting any formatted copy.
This guide demonstrates the issue with the JSON Formatter and Validator. Its current implementation parses input into JavaScript values and then serializes those values again. The example below uses fictional data.
Reproduce a changed ID with a small sample
Paste this input into Paste your JSON. Choose 2 spaces from Indent, leave Minify and Sort keys alphabetically unchecked, and click Format JSON.
{"invoice_id":9007199254740993,"copies":2}The output is:
{
"invoice_id": 9007199254740992,
"copies": 2
}The ID now ends in 992 instead of 993. The formatter still reports valid JSON because the input obeys JSON syntax. Its success message does not certify that every original numeric value survived parsing unchanged.
Keep this short failing sample when reporting the problem to an integration owner. It shows the original value, the resulting value, and the operation that connects them without requiring a full production response.
Understand the safe integer boundary
JavaScript’s ordinary Number type cannot distinguish every integer at arbitrarily large magnitudes. Its safe integer range runs from -9007199254740991 to 9007199254740991, inclusive. MDN explains this boundary in its Number.MAX_SAFE_INTEGER reference.
Some integers outside that range can still be represented exactly. That does not make the whole surrounding range safe: adjacent integers may map to the same JavaScript number. Counting digits alone is also insufficient; compare the actual value with the boundary.
In this tool, the loss occurs when JSON.parse converts the numeric token into a JavaScript number. Adding indentation afterward cannot restore the discarded distinction. MDN’s JSON.parse documentation describes this precision risk. Selecting a different indent or enabling minification does not change the underlying parsing step.
Preserve an identifier as a string when the schema permits
An identifier labels a record; it is often not a quantity you intend to add or average. If the receiving schema defines invoice_id as a string, represent it with double quotation marks in the original JSON:
{"invoice_id":"9007199254740993","copies":2}Run the formatter with the same settings. The output retains the ID:
{
"invoice_id": "9007199254740993",
"copies": 2
}The quotation marks change the field’s type. They protect this sequence of digits from numeric conversion during this workflow, while copies remains a number. Check both the exact ID and its required type before using Copy.
Return to the original before making a correction
Do not add quotes around the already rounded output and assume you recovered the ID. Quoting 9007199254740992 preserves the wrong digits. Retrieve the authoritative original value and correct its representation at the producer when that matches the agreed schema.
Avoid a blanket search-and-replace that quotes every number. It could turn quantities or unrelated numeric fields into strings that the application rejects. A targeted change still needs a schema check and a test with the receiving application.
Use a precision-aware workflow for required numeric fields
If a contract requires an exact large numeric value, changing it to a string is not a compatible repair. Keep the source intact and use a parser and serializer designed to preserve that number’s required precision. Confirm their behavior with a failing fixture before processing the full document.
JavaScript BigInt can represent large integers, but adding an n suffix produces JavaScript syntax, not valid JSON. Ordinary JSON.stringify also throws on a BigInt unless explicit serialization handling is provided, as described in MDN’s JSON.stringify reference. This formatter does not expose such a conversion option.
For punctuation failures, follow the guide to common JSON syntax errors. Once precision and field types are settled, the API example formatting checklist covers preparing the reviewed payload for documentation. A readable layout is useful only when the values still mean what the source intended.