Number
RFC 8259 §6[minus] integer [fraction] [exponent]
JSON has a single numeric type with no distinction between integers and floating-point. Numbers are IEEE 754 double-precision values. Integers are safe up to 2^53-1 (9,007,199,254,740,991). Beyond that, precision is lost. JSON has no NaN, Infinity, or -Infinity – these must use null or strings.
Description
JSON's number grammar allows integers, decimals, and exponents: [-] digits [. digits] [e|E [+|-] digits]. No leading zeros (except 0 itself). No trailing decimal point.
The critical constraint is that JSON numbers map to IEEE 754 double-precision floating-point in most parsers. This means integers beyond 2^53-1 cannot be represented exactly. JavaScript, Python's json module, and most default parsers silently round large integers.
Practical example: database IDs, snowflake IDs, and Unix microsecond timestamps often exceed 2^53. Twitter famously added string ID fields alongside integer ID fields to work around this limitation.
Examples
| Label | Value |
|---|---|
| Integer | 42 |
| Negative | -17 |
| Float | 3.14159 |
| Exponent | 1.5e10 |
| Zero | 0 |
| Safe max int | 9007199254740991 |
Common Gotchas
No integer vs float distinction – 1 and 1.0 are the same JSON value
Integers beyond 2^53-1 lose precision in IEEE 754 double – use strings for large IDs
NaN and Infinity are not valid JSON – use null or a string representation
Leading zeros not allowed: 0123 is invalid JSON (valid JavaScript octal)
No hex literals – 0xff is not valid JSON
Trailing decimal not allowed: 1. is invalid; use 1.0