Why the API Viewer Rounds Large Integers
If you've ever pasted an API response into the API Response Viewer and noticed that the last few digits of a post ID or user ID came out different from the original, the tool isn't malfunctioning. This happens because of a fundamental limit in how JavaScript's JSON.parse() represents numbers — and once you understand why, it also explains why API specs so often recommend sending large integers as strings.
1. Checking the code first: this tool uses plain JSON.parse
The tool's parsing logic lives inside the viewResponse() function, and the actual code is a single line: _parsed=JSON.parse(raw);. There's no reviver callback, no preprocessing step that preserves large integers as strings, and no BigInt conversion — it's plain, unmodified JSON.parse. In other words, this tool isn't uniquely inaccurate; it's simply using a standard JavaScript API in the standard way, and the rounding comes directly from that standard behavior.
2. How JSON.parse stores numbers: IEEE 754 double precision
JavaScript has no dedicated integer type. 1, 3.14, and 9007199254740993 are all stored in the exact same numeric format: IEEE 754 double-precision floating point. This format consists of 1 sign bit, 11 exponent bits, and 52 mantissa (significand) bits, and the range within which an integer can be represented with zero error is bound by what those 52 mantissa bits can hold. That boundary is exactly Number.MAX_SAFE_INTEGER — 253-1 = 9,007,199,254,740,991.
Once an integer exceeds this value, the gap between representable double values (the precision) grows larger than 1, which means multiple distinct integers can collapse onto the same floating-point value. Because JSON.parse() always converts number literals in JSON text into this double format with no exceptions, a source text that reads 9,007,199,254,740,993 ends up stored in the parsed object as the nearest representable double value instead (e.g., 9,007,199,254,740,992). When that value is later turned back into a string — via JSON.stringify or simply displayed on screen — the number that comes out no longer matches the original.
JSON.parse directly in a browser console) and the last digit of the id field changes.
| Original JSON text | Result of JSON.parse |
|---|---|
{"id": 9223372036854775807} | Rounded to 9223372036854775808 (last digit 7→8) |
{"id": 123456789012345678} | Rounded to 123456789012345680 (last 3 digits 678→680) |
Values like these show up all the time in practice — Twitter's (X's) and Discord's Snowflake IDs, and 64-bit database primary keys at large-scale services, are common examples. A 64-bit integer can go as high as 263-1 ≈ 9.2×1018, which is over 1,000 times larger than the safe-integer limit of roughly 9.0×1015.
3. Not this tool's problem — it's how the JS language standard works
This isn't a bug in any particular library; it's exactly what JSON.parse is specified to do under ECMA-262, the JavaScript language standard. Any JavaScript code — a Node.js backend, a browser, any other JSON parser — will produce the same rounding if it calls JSON.parse without extra handling. That means other tools on this site, like the JSON Formatter or the JSON Validator, share the same limitation if they also rely on JSON.parse internally. On the other hand, languages that treat integers with arbitrary precision — Python's json module, for instance — never round at all, which is why you might get the impression that "it worked fine everywhere else but broke here." In reality, it's a difference in how each language designs its number types.
4. The API-spec convention: send large integers as strings from the start
The real fix isn't patching the viewer's parsing — it's designing the API response so that values beyond the safe-integer range are sent as JSON strings instead of number literals in the first place. A string is preserved character-for-character by JSON.parse with no numeric conversion involved.
- Twitter (X) API: post
idis still sent as a large integer, but the API also provides a separate string version in theid_strfield. - Discord API: Snowflake IDs are sent entirely as string types.
- Many large payment/fintech APIs: spec guidance explicitly recommends wrapping large integer identifiers for amounts or accounts as strings.
If you're designing an API yourself, the safe, language-agnostic convention is to wrap 64-bit integer (BIGINT) values as strings rather than exposing them directly as JSON numbers.
5. So how do you check whether rounding has happened?
This tool's Info tab shows line count, size, top-level key count, and nesting depth, but it doesn't automatically flag rounded numbers. If you suspect a field has been affected, the safest approach is to manually copy the number from the original text and compare digit-by-digit, or — if you know in advance that an API returns large integer fields — write a separate parser that uses a reviver function to keep that specific field as a string, or convert it to a BigInt, rather than relying on plain JSON.parse. This tool is built for quickly scanning response structure without that kind of custom parsing, so treat it as a reference-only view whenever integer precision on a field actually matters.
Frequently Asked Questions
Q. Is there an option in this tool to prevent rounding?
A. No. The code uses only JSON.parse(raw), with no precision-preserving handling like BigInt conversion or a reviver option. Any response containing an integer larger than 253-1 (9,007,199,254,740,991) can always have its last digits rounded.
Q. At what point does rounding start to happen?
A. It can occur once an integer exceeds 9,007,199,254,740,991 (roughly 9 quadrillion). Integers smaller than that are represented exactly by double-precision floating point, so no rounding occurs.
Q. Would parsing the same JSON in a different programming language avoid this?
A. It depends on the language. Python's standard json module treats integers with arbitrary precision, so no rounding occurs there. JavaScript, however — along with any other language's library that relies on the same JSON.parse-style behavior — treats every number as a double-precision float and will round the same way.
Q. If I'm building my own API, how should I design it?
A. The standard convention is to send any ID or amount field that might exceed the safe-integer range as a JSON string rather than a number type. Twitter's (X's) id_str field and Discord's string-typed Snowflake IDs are good examples to follow.