In JavaScript, why does the expression 9007199254740993 === 9007199254740992 evaluate to true, and what does Number.MAX_SAFE_INTEGER have to do with it?

## The value is wrong before any code runs The usual first instinct is that `===` did something clever. It did not. The rounding happens when the *literal* is turned into a value. There is no integer type in ordinary JavaScript arithmetic; every numeric literal without an `n` suffix becomes a `number`, which is a 64-bit IEEE-754 double. If the mathematical value of the literal is not representable as a double, the closest representable double is used. ```js console.log(9007199254740993); // 9007199254740992 console.log(9007199254740993 === 9007199254740992); // true ``` So the engine is comparing one value with itself. ## Where 2^53 comes from A double splits its 64 bits into a sign bit, 11 exponent bits and 52 stored significand bits. For normal values there is an implicit leading 1 bit, giving 53 bits of precision. An integer needs at most 53 significant bits to be written exactly. - Integers with magnitude up to 2^53 need at most 53 bits and are all exact. - 2^53 + 1 needs 54 bits, so it has no representation. - Between 2^53 and 2^54 only even integers are representable — the spacing is 2. - Between 2^54 and 2^55 the spacing is 4, and it keeps doubling. That is why the failure is silent and progressive rather than a clean overflow: nothing throws, nothing becomes `Infinity`, the value simply snaps to a neighbour. ## Why the constant is 2^53 - 1 and not 2^53 `Number.MAX_SAFE_INTEGER` is `9007199254740991`. The value 2^53 itself *is* exactly representable, so the constant is not "the last representable integer". "Safe" is defined as: `n` is safe when `n` and every integer between it and zero has exactly one double representation — practically, when `n` and `n + 1` are distinguishable. At 2^53 that fails, because 2^53 + 1 rounds back down onto 2^53. Hence the largest safe integer is one below. ```js Number.MAX_SAFE_INTEGER; // 9007199254740991 Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2; // true Number.isSafeInteger(2 ** 53); // false ``` That second line is the demonstration to reach for in an interview: two mathematically different expressions producing the same value is exactly what breaks counters, cursors and identifiers. ## What actually breaks in production Three recurring shapes: 1. **Identifiers.** A 64-bit database or platform ID exceeds 2^53 long before it exceeds its own type. Once it becomes a JavaScript number, the low digits are gone: lookups miss, and two genuinely different records can collapse onto one value and be deduplicated together. 2. **Monotonic counters and cursors.** An `id + 1` pagination cursor stops advancing once increments are being rounded away, producing an infinite loop that fetches the same page forever. 3. **Nanosecond or microsecond timestamps.** Millisecond epoch values are safe for centuries, but nanosecond timestamps pass 2^53 immediately and lose their low-order digits. Note that the loss is unrecoverable at the point of detection. `Number.isSafeInteger(v)` tells you the value cannot be trusted; it cannot tell you what the digits were. ## What to do instead The options are all about keeping such values out of the `number` type in the first place: - Carry the value as a **string** when you only need to store, compare for equality and echo it back. This is the common answer for opaque identifiers, because it needs no arithmetic. - Use **`BigInt`** (`9007199254740993n`) when you genuinely need exact arithmetic beyond the safe range. BigInt is arbitrary precision, so no boundary applies — at the cost of not mixing with `number` in arithmetic. - Keep the value **below the boundary by design**, for example by using milliseconds rather than nanoseconds, or by splitting a composite key into fields. ```js const exact = 9007199254740993n; console.log(exact === 9007199254740992n); // false — BigInt keeps the digits console.log(Number(exact)); // 9007199254740992 — converting back loses them again ``` ## The sentence that answers the question "Numbers are doubles with 53 bits of precision, so 2^53 + 1 has no representation and the literal is rounded at parse time; `MAX_SAFE_INTEGER` is 2^53 - 1 because that is the last integer whose successor is still a different value."