Integer too large for a JSON parser's number type
JSON's grammar permits arbitrary-precision numbers, but most parsers map them onto an IEEE 754 double, which holds integers exactly only up to 2^53−1. Snowflake IDs, Twitter/X IDs and database bigints all exceed that. There is no parse error — the value is silently rounded.
The input
{"id": 9223372036854775807}{"id": "9223372036854775807"}How to fix it
Transport large identifiers as strings. If you cannot change the producer, use a parser that preserves precision: `json-bigint` in JavaScript, `parse_int=` in Python's `json.loads`, or `json.Number` in Go.
The failure mode is the worst kind: everything parses, and the last few digits of your ID are wrong. Test with a value above 9007199254740991.
What each parser reports
Every message below was captured by running this exact input through the parser named. 0 of 21 parsers rejected it; 21 accepted it.
| Parser | Exact message |
|---|---|
| CPython json.loads CPython 3.12.3 | accepted — no error |
| encoding/json Unmarshal Go go1.22.2 | accepted — no error |
| Gson Java 21.0.12 | accepted — no error |
| Gson JsonParser (lenient off) Java 21.0.12 | accepted — no error |
| hjson Node.js 22.22.2 | accepted — no error |
| Jackson ObjectMapper Java 21.0.12 | accepted — no error |
| JavaScriptCore JSON.parse JavaScriptCore (Bun 1.4.1) | accepted — no error |
| json-bigint Node.js 22.22.2 | accepted — no error |
| JSON5 Node.js 22.22.2 | accepted — no error |
| JSON::PP Perl 5.038002 | accepted — no error |
| json_decode PHP 8.3.6 | accepted — no error |
| Newtonsoft.Json JsonConvert Newtonsoft.Json 13.0.3 on .NET 8.0.30 | accepted — no error |
| Newtonsoft.Json JsonTextReader Newtonsoft.Json 13.0.3 on .NET 8.0.30 | accepted — no error |
| orjson CPython 3.12.3 | accepted — no error |
| Ruby JSON.parse Ruby 3.2.3 | accepted — no error |
| serde_json::from_str Rust (serde_json 1.x) | accepted — no error |
| SpiderMonkey JSON.parse SpiderMonkey 115 | accepted — no error |
| System.Text.Json Deserialize .NET 8.0.30 | accepted — no error |
| System.Text.Json JsonDocument .NET 8.0.30 | accepted — no error |
| ujson CPython 3.12.3 | accepted — no error |
| V8 JSON.parse Node.js 22.22.2 | accepted — no error |
What the specification says
The exact sections that govern this error. Descriptions are our paraphrase; follow the links for the normative text.
| Body | Section |
|---|---|
| IETF | A number is base 10, optionally signed with a minus, with an optional fraction and exponent. The section states that leading zeros are not allowed, and that values which cannot be represented in its grammar — Infinity and NaN among them — are not permitted. |
| IETF | The same section notes that integers in the range −(2⁵³)+1 to 2⁵³−1 are interoperable, and gives 1E400 and 3.141592653589793238462643383279 as examples of numbers that signal interoperability problems. |
| Ecma International | A number is decimal digits with no superfluous leading zero. Values such as Infinity and NaN are not permitted. |
| IEEE | Referenced by RFC 8259 §6 as the basis for its interoperability guidance on numbers. |
Peer-reviewed literature
- D. Goldberg, “What every computer scientist should know about floating-point arithmetic”, ACM Computing Surveys, vol. 23, no. 1, pp. 5–48, 1991. doi:10.1145/103162.103163
- W. D. Clinger, “How to read floating point numbers accurately”, Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI ’90), 1990. doi:10.1145/93542.93557
- G. L. Steele Jr. and J. L. White, “How to print floating-point numbers accurately”, Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI ’90), 1990. doi:10.1145/93542.93559
- D. Lemire, “Number parsing at a gigabyte per second”, Software: Practice and Experience, vol. 51, no. 8, pp. 1700–1727, 2021. doi:10.1002/spe.2984
Other errors in this category
Duplicate keys in a JSON object
The same key appears twice. The JSON specification does not forbid this, and it does not define which value wins — so every parser…