Is it specified anywhere how big JSON integers can be? I'm guessing that they're limited to normal (32 bit) ints, but I can't find anywhere that that's written down. I need to encode identifiers that are longs in Java, so I presume I need to store those as strings in JSON so as not to risk overflow.
3 Answers
A JSON number is not limited by the spec.
Since JSON is an abstract format that is not exclusively targeted at JavaScript, the actual target environment determines the boundaries of what can be interpreted.
It's also worth noting that there are no "JSON Integers", they are a sub-set of the "Number" datatype.

- 332,285
- 67
- 532
- 628
-
13As a practical matter, Javascript integers are limited to about 2^53 (there are no integers; just IEEE floats). But the JSON spec is quite clear that JSON numbers are unlimited size. – Nelson Dec 06 '13 at 18:24
-
17Although the answer remains technically correct, it'd be worth updating, since RFC 7159 helps clarify on what range of integers should be considered as interoperable. (ie `[-(2**53)+1, (2**53)-1]`.) If you're working outside that range then either use string encoded integers, or expect implementations to lose precision. – Tom Christie Oct 06 '17 at 10:53
-
@TomChristie The JSON spec does not make any mention of RFC7159. – Tomalak Oct 06 '17 at 11:37
-
4@Tomalak - Sure - RFC7159 came along later (2014). Clarifies some of the previously existing inconsistencies/edge cases etc. (Such as lack of any mention about workable numeric ranges) – Tom Christie Oct 06 '17 at 13:41
-
4Hm, upon reading the RFC in detail, it does still not limit numbers. It merely hints that many systems use IEEE754 internally and that this fact can put practical limitations on what can be interpreted by the receiver, which is what the answer said all-along. – Tomalak Oct 06 '17 at 15:40
RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
-
'widely available' is some vague language, IMO. Meanwhile, some implementations (like Python's standard `json` module) do parse arbitrary integers, even beyond 64 bit (built-in bignums). – Tomasz Gandor Oct 28 '19 at 17:17
-
'widely available' is not so vague when it was previously stated that IEEE754 is 'widely used'. – Jason Warner Dec 17 '20 at 16:36
I just did the following empirical test using Chrome (v.23 on Mac) Console:
> var j = JSON.parse("[999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999]")
undefined
> j[0]
1e+228
If JSON is passed through HTTP then the number will be converted in String from Java in any case and then the issue could be only in Javascript.
From ECMAScript Language Specification 4.3.19:
4.3.19 Number value
primitive value corresponding to a double-precision 64-bit binary format IEEE 754 value
NOTE A Number value is a member of the Number type and is a direct representation of a number.
Which is what defined in wikipedia Double-precision floating-point format.

- 2,479
- 20
- 32
-
2Thanks. This particular JSON structure is being handed out by back-end web service in Java, so, following @Tomalak's answer I guess I need to check what my server-side JSON library is actually doing. – Ian Dickinson Nov 21 '12 at 21:48
-
5And, for the record, [Jackson](http://jackson.codehaus.org/) does parse long integers in JSON input correctly in to Java longs. – Ian Dickinson Nov 21 '12 at 22:04
-
And also for the record, Jackson emits Java longs correctly, but at least Chrome-based browsers set the last 3 decimals to zero, i.e. length of the number is correct, but the last 3 decimals always read 000 – Johannes Jander Nov 15 '18 at 12:30