The 19-digit order ID in an API response ends in different digits after formatting. How do I keep it intact?
Because JavaScript, which your browser runs, keeps integers exact only up to 9007199254740991, and any longer number is rounded when the JSON is written back. The JSON formatter lists every such number in a warning so you notice before copying. The lasting fix is for the system to send IDs as strings in quotes.
What exactly happened
An API response from a platform or payment gateway with a long order ID:
{"order_id":1234567890123456789}
After minifying in the tool:
{"order_id":1234567890123456800}
The last three digits changed from 789 to 800. The length is 32 bytes both times, so nothing about the size draws your eye. But under the result the tool shows a warning, 'Integers too large for JavaScript to keep exactly; they changed in the output', followed by the original number 1234567890123456789.
Why 9007199254740991 in particular
JavaScript stores every number the same way, and that way keeps every integer exact up to this limit, which is 2 to the power 53 minus 1. Beyond it gaps appear: it cannot tell every pair of neighbouring integers apart, so it picks the nearest one it can hold. A small example shows the edge: 9007199254740991 stays as it is with no warning, while 9007199254740993, just two higher, becomes 9007199254740992 with a warning.
Because the tool uses the browser's real parser, it behaves exactly like any JavaScript code reading the response would. The warning is its value here: it exposes the problem before a wrong order number reaches a spreadsheet or a message to a customer.
How to keep the number intact
- Do not copy the output if the large-number warning appears. Go back to the original text; the number is correct there.
- If you only need to read the response, read the ID from the original text, not the output.
- The lasting fix is at the source: ask the system's developer, or search the API documentation, for a way to return IDs as strings. Some APIs offer a string field alongside the numeric ID, so check theirs.
- Once the ID is a string, such as "order_id":"1234567890123456789", the tool keeps it exactly, because it never touches strings.
Where the same problem shows up
Not only in this tool. Any program that reads JSON with ordinary JavaScript numbers rounds the ID the same way: a web-based dashboard, a spreadsheet add-on, a converter. That makes the tool a quick test: paste a response from the API, and if the warning appears, you know its IDs will be damaged anywhere that reads them the same way.
If you are going to turn the response into a table with the CSV and JSON converter, check the order numbers in the result before relying on it, or make them strings at the source first. You can check the response in the JSON formatter and validator beforehand.
Common questions
Are decimal prices affected by this?
No. The warning is about long integers, 16 digits or more, that cross the limit. Ordinary prices come nowhere near it.
How many numbers does the warning list?
Up to 20 per result, which is enough to tell you the problem is there.
Can the tool keep the long number as a number without rounding?
No. It uses the browser's standard parser and repairs nothing; the fix is for the ID to be a string.
