Skip to content
escentmachine
← escentmachine field notes

The JSON number is valid. Is the value still exact?

escentmachine · accuracy first

A JSON document can be perfectly valid while its numbers cannot be represented exactly by your application. This distinction matters for event identifiers, money and counters. Formatting a document should not silently change the data you are trying to inspect.

First decision: a quantity or an identifier?

If a value identifies a record, treat it as a string at the schema boundary. You rarely need arithmetic on an event ID, and a decimal string crosses runtimes more reliably than a very large numeric token. If the value is a quantity, choose the numeric model intentionally: integer arithmetic, decimal arithmetic or an approximate floating-point number.

JavaScript’s largest safe integer is 9007199254740991. Above that boundary, adjacent integers are not all distinguishable as Number values. JSON itself does not impose this JavaScript limit. The loss happens when a runtime maps the JSON token into its own numeric type.

Run the boundary case

{"event_id":9007199254740993,"ratio":0.10000000000000001,"scale":1e400}

Expected Inspector output with two-space formatting:

{
  "event_id": 9007199254740993,
  "ratio": 0.10000000000000001,
  "scale": 1e400
}

Expected diagnostics: the event ID is outside JavaScript’s safe integer range; the scale is outside its finite Number range. Neither token changes. The decimal ratio also remains exactly as written. The Inspector builds a syntax tree with raw number tokens rather than converting those tokens to Number values.

Run the precision-boundary example →

Formatting is not a schema migration

The Inspector preserves numeric spelling, including exponents and negative zero. It does not quote large integers or convert exponents into expanded decimals. Those changes would alter the representation you supplied. Copy the formatted result only after checking the precision panel, and verify that the receiving application uses an appropriate numeric type.

Compare takes a different, explicit view: exact decimal values are compared using a coefficient and exponent, so 1e3 and 1000 count as equal. This does not require a floating-point conversion. It is a structural comparison, not a check that the source files are byte-for-byte identical.

What happens to duplicate keys?

{"region":"us-east","region":"us-west"}

Expected result: a duplicate-key error at line 1, column 21, at $["region"]. The first declaration is on line 1. No output is produced and no key is silently overwritten. Escaped spellings of the same key are also duplicates. Resolve the ambiguity in the source before you compare or format it.

Next note