DEV Community: sharpenlee

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

sharpenlee — Fri, 02 Oct 2026 14:09:44 +0000

Here is one line of JSON, parsed and re-serialised, changing a digit on the way through. No error, no warning, nothing to catch:

in:  {"id": 9007199254740993}
out: {"id": 9007199254740992}

It is tempting to conclude that JSON is lossy. It is not. Run the same document through Python or Ruby and the ID survives intact — which means the damage was done by a choice the JavaScript engine made, and that the standard explicitly permitted.

One document, three answers

Every result below was produced by running the code, not by reading documentation. Three commands, one payload:

node    -p 'JSON.parse("{\"id\":9007199254740993}").id'
python3 -c 'import json;print(json.loads("{\"id\":9007199254740993}")["id"])'
ruby    -rjson -e 'p JSON.parse("{\"id\":9007199254740993}")["id"]'

Runtime	What you get back	Type
Node v24.18.0 (V8 15.0)	`9007199254740992`	`number`
CPython 3.10.11	`9007199254740993`	`int`
Ruby 2.6.10	`9007199254740993`	`Integer`

Two of the three are exact. The odd one out is the language most JSON is written in, and it is the only one of the three whose integers are not arbitrary-precision: JavaScript has one numeric type, a 64-bit float, so anything above 2**53 - 1 is rounded on the way in. A 19-digit snowflake ID, a nanosecond timestamp, an Ethereum amount — all of them sit well past that line.

The damage can happen before JSON is involved

In JavaScript the rounding is not a property of the parser. It is a property of the number, and it applies to literals in your source too:

9007199254740993 === 9007199254740992   // true
1.0000000000000000001                   // 1

So by the time JSON.parse is called, a numeric ID may already have been corrupted by the code that built the value. This is why "just use a bigger type" does not work in JavaScript: the bigger type does not exist, and the literal syntax will not warn you.

What the standard actually promises

RFC 8259 does not require a lossy parser. It permits one. It allows implementations to set their own limits on range and precision, and the only numbers it promises will interoperate are those inside the window [-(2**53)+1, (2**53)-1]. It names the smell itself: "A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems".

That, in one sentence, is the whole problem. JSON defines a grammar for numbers, not a numeric type. The grammar says a number is an optional minus sign, digits, an optional fraction and an optional exponent. It says nothing about how many digits matter or what they mean once decoded. Every implementation then binds that grammar to whatever number type it already had, and the binding is where your ID dies.

It applies to keys as well

The same laissez-faire applies to object keys. RFC 8259 says "The names within an object SHOULD be unique", and then concedes what happens when they are not: "the behavior of software that receives such an object is unpredictable". All three runtimes I tested take the last value, but nothing in the standard requires that, which is why a duplicated key is a live security question rather than a style question — a proxy and the service behind it can disagree about which value the document means.

Reading is only half of it

The write side is worse, because it destroys information that was never in doubt. These are measured, not theoretical:

Value	JavaScript	Python	Ruby
`1.0`	`1`	`1.0`	`1.0`
`1.10`	`1.1`	`1.1`	`1.1`
`NaN`	`null`	`NaN` — invalid JSON	raises `GeneratorError`
`Infinity`	`null`	`Infinity` — invalid JSON	raises `GeneratorError`
`-0.0`	`0`	`-0.0`	`-0.0`
`2**53 + 1`	`9007199254740992`	`9007199254740993`	`9007199254740993`

Three things are worth pulling out of that table.

JavaScript turns NaN and Infinity into null. Not an error, not a string — null, which is indistinguishable from a genuine absent value. Python takes the opposite risk and writes NaN into the output, producing a document that is not valid JSON and that a strict reader will reject. Ruby refuses to write it at all, which is the correct behaviour and the least popular one.

1.10 loses its trailing zero everywhere. Not because a parser is lazy, but because 1.10 and 1.1 are the same IEEE 754 double — the trailing zero was never a value, only spelling. Only a reader that declines to convert to a double keeps it. That is the real dividing line in this whole subject: did the parser commit to a floating-point type, or did it keep the text?

The round trip is not a function. If you cannot recover your input from parse(stringify(x)), then comparing serialised JSON as text for equality is a bug waiting to happen. 1.0 becomes 1, -0.0 becomes 0, and 2**53 + 1 becomes 2**53 — all before you look at it.

The sign of zero shows how per-language this gets. Given the source text -0, JavaScript keeps the negative zero when parsing and then writes it back as 0; Python reads the very same token as the integer 0, losing the sign on the way in rather than on the way out. Identical bytes, two languages, two different places to drop the same bit.

And it silently discards non-numbers too

While we are on the write side, JSON.stringify in JavaScript does the following without complaint:

Input	Output
`{ a: undefined, b: 1 }`	`{"b":1}` — the key disappears
`[undefined]`	`[null]` — in an array the slot survives as null
`new Map([[1, 2]])`	`{}` — every entry gone, no error
`new Set([1])`	`{}`
`1n` (BigInt)	throws `TypeError`
`new Date(0)`	`"1970-01-01T00:00:00.000Z"`, and parsing it back gives a string, not a Date

Note the inconsistency between the first two rows: the same undefined is dropped from an object and replaced with null in an array. Neither is wrong per the standard — an array cannot have a hole, so something has to go there — but a reader who assumes symmetry will be surprised.

The 1e21 cliff

One more JavaScript-only oddity, because it breaks text diffs rather than values:

JSON.stringify(1e20)   // "100000000000000000000"
JSON.stringify(1e21)   // "1e+21"

Below 1e21 a number prints in full; at and above it, exponential notation. The value is identical, the bytes are not. Any tool that compares two payloads by their text — a cache key, a deduplication hash, a diff — will declare these different while any parser will say they are the same.

The escape hatch almost nobody knows

There is now a way to make JSON.parse and JSON.stringify round-trip byte-for-byte in JavaScript, and it is barely two years old. It comes from the TC39 JSON.parse source text access proposal, which is at stage 4, and it does two things: it gives the reviver a third argument carrying the original source text of each value, and it adds JSON.rawJSON for writing that text back out untouched.

That is enough to preserve a number exactly:

const keep = (key, value, ctx) =>
    ctx && 'source' in ctx ? JSON.rawJSON(ctx.source) : value;

const src  = '{"id":9007199254740993,"amount":1.10,"tag":"x"}';
const back = JSON.stringify(JSON.parse(src, keep));

// back === src  ->  true

Without the reviver the same transform silently rewrites the document — a changed digit and a reformatted decimal:

plain:  {"id":9007199254740992,"amount":1.1,"tag":"x"}
kept:   {"id":9007199254740993,"amount":1.10,"tag":"x"}

It works inside arrays too, and JSON.isRawJSON tells you when you are holding one of these wrappers. Two things to know before reaching for it. It is not a number — you cannot do arithmetic on it, so it belongs in pass-through code (a proxy, a logger, a formatter) and not in business logic. And the argument must be valid JSON on its own: JSON.rawJSON('01') throws immediately rather than corrupting anything downstream, which is a good failure to have.

Availability is the real limit. It is present in the runtime I tested, Node v24.18.0 on V8 15.0, and absent from older ones — check with typeof JSON.rawJSON before relying on it. On an engine without it, no reviver will help you, because the digits were gone before your callback ran.

What to do instead

Send identifiers as strings. This is what every large API eventually does, and it is the only fix that holds across languages, proxies and databases simultaneously. "9007199254740993" is exact everywhere; 9007199254740993 is exact in two of the three runtimes above and wrong in the third. A string is also self-documenting: nobody will accidentally sum it.
If you must keep numbers, parse with a reader that does not commit to a double. Python's default already keeps integers exact, and parse_float=decimal.Decimal keeps decimals exact too. Go's json.Decoder.UseNumber() and Jackson's USE_BIG_DECIMAL_FOR_FLOATS are the equivalent switches elsewhere; neither was executed here, so treat their exact semantics as documented rather than measured. In JavaScript, the reviver above is the option that exists today.
Refuse to write NaN and Infinity. Python needs json.dumps(..., allow_nan=False) to stop producing invalid JSON; Ruby does it already. In JavaScript there is nothing to enable — they are silently null, so the check has to be yours.
Never compare serialised JSON as text. 1.0 versus 1 and 1e20 versus 100000000000000000000 are the same values in different spelling. Compare parsed structures, and if you need a stable hash, canonicalise first — which means deciding what "equal" means for numbers before you hash, not after.

Where this bites in practice

The failure is concentrated in identifiers, and identifiers are exactly the values people are most reluctant to make strings because of how much legacy code compares them. Snowflake IDs from Twitter, Discord and the like; nanosecond timestamps at 19 digits; Ethereum amounts in wei, up to 78 digits; 64-bit hashes used as keys. Every one of them is past 2**53, and every one of them fails quietly — you get a valid-looking number that is off by a little, and the error surfaces three services later as "record not found".

Check your own payload

Paste the document into the JSON formatter to see the structure, and be aware of what you are looking at: this tool parses with your browser's engine, which is a V8-family parser, so a 19-digit ID will already be rounded when it appears on screen. That is not a limitation to hide — it is the same thing JSON.parse will do to that data in your application, demonstrated before you ship it. If the number looks wrong in the formatter, it is wrong in your code.

For documents that will not parse at all, the validator reports the line and column, and the syntax cheat sheet covers what the grammar allows.

Provenance

Every result in this article was produced by executing the code shown, on Node v24.18.0 (V8 15.0.245.15), CPython 3.10.11 and Ruby 2.6.10. The quoted sentences are from RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format, sections 4 and 6; the proposal status is from the TC39 JSON.parse source text access repository. Where a claim was not executed here — the Go and Jackson settings — it is labelled as documented behaviour rather than measured, because the difference between those two things is the entire subject of this article.

Why "Unexpected token <" means your API returned HTML

sharpenlee — Thu, 01 Oct 2026 14:15:17 +0000

You called an endpoint, expected data, and the parser stopped on the very first character. The message is not about your payload — it is about the shape of the response, and the response was a web page.

Uncaught SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

Older engines report the same failure with different wording, and a search for any of these strings means the same thing:

SyntaxError: Unexpected token < in JSON at position 0

What the parser is telling you

A JSON document may begin with {, [, ", a digit, a minus sign, or one of the literals true, false and null. Leading whitespace is allowed. Nothing else is. A < is not in that set, so a body that starts with <!DOCTYPE html> fails at offset zero.

Newer V8 builds — Chrome, Edge and Node 20 and later — make the message far more useful by quoting the beginning of what they actually received. Those five characters, "<!DOCTYPE ", are the whole diagnosis: something gave you a hypertext document where you expected a data envelope.

The five things that actually happened

The endpoint returned an error page. A 404, a 500, or a framework's HTML error renderer answered instead of the route you meant. A path segment is missing, the route only exists for a different HTTP method, or the resource genuinely is not there.
A single-page app fallback answered instead of the API. Dev servers and static hosts commonly serve index.html for any unmatched path, so a request to a typo such as /api/uers returns the application shell — status 200, content type text/html. This is the most frequent cause in local development, and it looks exactly like a successful request.
You were redirected to sign-in. An expired session or a missing token turns the API call into a redirect to a login page, and fetch follows redirects silently. The parser then receives the sign-in form.
Something in front of the API blocked the request. A WAF, a corporate proxy, a CDN security rule or a captive portal serves an HTML interstitial, frequently with a status that does not read like a failure.
The base URL points at the marketing site. A missing /api prefix, an environment variable still set to the root domain, or a trailing-slash difference lands the request on a page that is perfectly valid HTML — just not the one you wanted.

Confirm it in one request

Print the status, the content type and the first bytes before parsing. This is the step that turns the error from a puzzle into a fact:

const res = await fetch(url, {
    headers: { Accept: 'application/json' }
});

const body = await res.text();

console.log(res.status, res.headers.get('content-type'));
console.log(body.slice(0, 120));

if (!res.ok) {
    throw new Error(`HTTP ${res.status} from ${res.url}: ${body.slice(0, 200)}`);
}
if (!res.headers.get('content-type')?.includes('json')) {
    throw new Error(`Expected JSON, got ${res.headers.get('content-type')}`);
}

const data = JSON.parse(body);

Reading with text() and parsing it yourself is what makes this work. Calling res.json() directly throws the same unhelpful syntax error and discards the body, which is why the cause stays hidden.

From a shell, the headers and the first line are enough:

curl -sS -i -H 'Accept: application/json' https://api.example.com/v1/users | head -n 20

The first line gives the status and content-type gives the type. If the body begins with <!DOCTYPE, you have your answer. Run it again without -L: curl will then print the redirect and its location header instead of following it, which is how you catch the login bounce that fetch hid from you.

Why sending `Accept: application/json` does not prevent this

It is a request header, not a contract. Servers are free to ignore it, and error paths in particular tend to bypass content negotiation altogether. It is still worth sending — some gateways route on it — but the reliable check is the status and the content type above, not the header you hoped would be honoured.

It works in Postman but fails in the browser

Two explanations cover nearly every case. Either Postman sends an API key or bearer token while the browser sends session cookies, so only the browser gets redirected to sign-in; or the server chooses its response format based on X-Requested-With, which fetch does not set by default. Compare the raw response rather than the Pretty view — Postman renders HTML without complaint.

Do not fix this by stripping the HTML

It is tempting to add a repair step that slices everything before the first { and parses the remainder. That converts a loud failure into a quiet one. The request is still wrong, and once the error page changes shape you will be debugging a half-parsed object instead of a 404. Fix the path, the authentication or the routing, and keep the guard from the snippet above so the next occurrence fails where you can see it.

Wording across engines

The same defect is reported differently depending on what parsed it. If your message is not the one at the top of this post, it is probably in this table:

Engine	Message
Chrome, Edge, Node 20+	`Unexpected token '<', "<!DOCTYPE "... is not valid JSON`
Chrome, Node before v20	`Unexpected token < in JSON at position 0`
Firefox	`JSON.parse: unexpected character at line 1 column 1 of the JSON data`
Safari, JavaScriptCore	`JSON Parse error: Unexpected identifier "<!DOCTYPE"`
Python `json.loads`	`json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)`

Check whether a body is JSON at all

Once the endpoint returns data, paste it into the JSON formatter to read the structure. If you are not yet sure whether a body is JSON at all, paste it in as it arrived: a < reported at position 0 is a definitive answer that the content type was lying, and the validator gives you the line and column rather than a bare offset.

DEV Community: sharpenlee

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

One document, three answers

The damage can happen before JSON is involved

What the standard actually promises

It applies to keys as well

Reading is only half of it

And it silently discards non-numbers too

The 1e21 cliff

The escape hatch almost nobody knows

What to do instead

Where this bites in practice

Check your own payload

Provenance

Related reading

Why "Unexpected token <" means your API returned HTML

What the parser is telling you

The five things that actually happened

Confirm it in one request

Why sending `Accept: application/json` does not prevent this

It works in Postman but fails in the browser

Do not fix this by stripping the HTML

Wording across engines

Check whether a body is JSON at all

Related reading

DEV Community: sharpenlee

JSON Number Precision — Why 19-Digit IDs Come Back Wrong

One document, three answers

The damage can happen before JSON is involved

What the standard actually promises

It applies to keys as well

Reading is only half of it

And it silently discards non-numbers too

The 1e21 cliff

The escape hatch almost nobody knows

What to do instead

Where this bites in practice

Check your own payload

Provenance

Related reading

Why "Unexpected token <" means your API returned HTML

What the parser is telling you

The five things that actually happened

Confirm it in one request

Why sending Accept: application/json does not prevent this

It works in Postman but fails in the browser

Do not fix this by stripping the HTML

Wording across engines

Check whether a body is JSON at all

Related reading

Why sending `Accept: application/json` does not prevent this