Why can a decimal-looking number change when serialized and read back?

There are two things to compare: the number’s meaning and the exact characters used to write it. JSON has a number grammar, but the receiving system’s numeric type determines how precisely a parsed number can be represented. [S1] Once JavaScript has parsed a JSON number into a Number, its later text representation comes from that numeric value, not from a saved copy of the input spelling. [S2]

For example, the text 1.2300 may be represented and emitted as 1.23. Those spellings describe the same ordinary decimal quantity, but they are not identical text. If you need the original number of decimal places for display, a report, or another format-sensitive purpose, keep the original text separately or transmit the value as a string.

No. First check whether the numeric value changed or only its spelling. In JavaScript, converting a Number to text does not restore trailing zeros that were present in the input. [S2] A useful comparison is:

1. Original text: 1.2300
2. Parsed value: the numeric value represented by the receiving system
3. Re-serialized text: for example, 1.23

Here the visible difference is formatting, not evidence by itself that the intended quantity changed. Also check whether the application treats the number of decimal places as meaningful. If it does—for example, because the text is a fixed-scale record—do not rely on a numeric value alone to preserve that spelling. Store the required formatted text explicitly.

Not automatically. MDN’s JavaScript JSON reference gives an example where parsing 12345678901234567890 as a JavaScript Number yields the nearby value 12345678901234568000; the receiving numeric type cannot represent that input precisely. [S1] Serializing afterward cannot recover digits that were already lost during parsing.

If every digit must survive, represent the value as a string in the data format and keep it a string throughout the path. Turning that string into a Number can lose precision, so avoid that conversion when the recipient cannot preserve the required value. [S1] This example describes JavaScript behavior; it does not establish how every language, parser, or serializer handles numbers.

Use this comparison, and record both the text and value whenever both matter:

1. Input text: save the exact characters sent, including sign, decimal places, and exponent notation.
2. Expected meaning: write down the intended numeric value and whether trailing zeros or other formatting carry meaning.
3. After parsing: inspect the parsed value using the actual receiving system and numeric type.
4. After serialization: compare the new text with the original, checking both numeric equivalence and exact spelling as separate questions.
5. Precision requirement: test representative small decimals and large integers; if any digit must be preserved exactly, use a string representation end to end and confirm no step converts it to a number.

For JavaScript, a serialization that changes 1.2300 to 1.23 can reflect formatting, while a sufficiently large integer can already be rounded at parse time. [S1][S2] These checks help identify the difference, but the cited JavaScript references do not specify the behavior of every other system or prove how an untested application handles a value.