Data and structured data
Why did the last digits of a large JSON ID change?
Tools to use
An order ID is copied without arithmetic, yet another screen changes its final digit. Precision can be lost simply by parsing a value as a number. Preserve the distinction between digits in the original JSON and the parsed numeric value. Start with two fictional adjacent IDs and check whether they remain distinguishable.
Format two adjacent IDs together
{"first":9007199254740992,"second":9007199254740993}Paste this directly into JSON Formatter. Its precision-preserving parser keeps the final digits 2 and 3 distinct. The check is not merely that parsing succeeds: confirm both complete values in the output, rather than a shortened label or visually formatted number.
If another program returns second ending in 2, information was lost somewhere on that path. Correct formatting here does not guarantee precision elsewhere. Compare the received raw body, parsed value, displayed value and reloaded storage separately to locate the first change.
An identifier can be a string
{"first":"9007199254740992","second":"9007199254740993","code":"00123"}Here both long IDs and 00123 are strings. That can preserve digits and leading zeroes for identifiers rather than quantities. But changing only the producer can violate a numeric-only receiver contract. Agree on the API and storage types; describe a type change separately from formatting.
Writing 00123 as a JSON number is not a valid way to retain a padded identifier. Once converted to 123, its original width cannot be inferred. For fixed-width codes, width is part of the contract. Decide whether the field is a quantity or an exact-match identifier before choosing a type.
Separate digit changes from type changes
{"id":9007199254740993}
{"id":9007199254740992}Place one object in each JSON Diff pane, not both lines in one input. Confirm the changed ID, then replace one side with a quoted ID to inspect a type change. Precision-preserving internals may expose auxiliary paths such as value in detailed diffs; those are not necessarily fields in the original API.
Representations such as 1 and 1.0 can have equal mathematical value but different spelling. A structural diff's reporting depends on its comparison rules. If exact identifier text is the requirement, numeric equality is insufficient: check a fixed expected string and its JSON type.
Precision can be lost at the next conversion
A CSV can contain the correct digits while a spreadsheet interprets them as an imprecise number. Other format converters also have different supported ranges from JSON formatting. Test each boundary with fictional values rather than assuming one tool's precision guarantee extends through the whole workflow.
Converting an already rounded ordinary number to BigInt cannot recover lost digits. Once two source values collapse to one, the output alone cannot identify the original. Recovery requires the pre-rounding source; fix the ingestion boundary rather than manually correcting displayed IDs.
Test more than small normal values
Include adjacent large numbers, a quoted large ID and a leading-zero code as well as 123. Document limits and rejection behavior for numeric fields. Converting everything to strings is not universally correct: quantities used in arithmetic may require numeric types. Choose by field semantics.
Share the source JSON, operation, resulting value and expected type together. 'Lost precision' alone does not distinguish truncated display from changed stored data. If only the label is shortened, the fix belongs to presentation. Precise observations help identify the correct layer to repair.