How does JavaScript's Object.is differ from the === operator, and for which values do the two disagree?

## What Object.is is `Object.is(a, b)` is a static method added in ES2015 that exposes the specification's *SameValue* algorithm. SameValue is defined almost identically to strict equality: same type or the answer is `false`, strings by contents, objects by reference, no conversion anywhere. It differs on exactly two number cases, and those two cases are the whole reason the method exists. ```js Object.is('a', 'a'); // true Object.is(1, '1'); // false — no conversion, just like === Object.is({}, {}); // false — still reference comparison Object.is(NaN, NaN); // true <-- differs from === Object.is(-0, 0); // false <-- differs from === ``` ## Divergence one: NaN `NaN` is the numeric result that has no meaningful value — `0/0`, `Number('abc')`, `parseInt('x')`. Floating-point arithmetic defines it as unequal to every value including itself, and `===` faithfully implements that, so `NaN === NaN` is `false`. That is correct as arithmetic and useless as an identity test: if you hold a value and want to know whether it is that same not-a-number, `===` cannot tell you. SameValue takes the identity view instead: two `NaN` values *are* the same value, so `Object.is(NaN, NaN)` is `true`. That gives you a one-call membership-style test, `Object.is(x, NaN)`, which is true for exactly the values `NaN === NaN`-style comparisons can never catch. ## Divergence two: negative zero JavaScript numbers carry a sign bit independent of magnitude, so `-0` and `0` are distinct values that arithmetic really produces: `-1 * 0`, `0 * -5`, `Math.round(-0.2)`. Strict equality ignores that distinction on purpose, because for ordinary numeric work `-0` and `0` should behave the same, and printing them mostly hides the difference (`String(-0)` is `"0"`). SameValue keeps them apart: `Object.is(-0, 0)` is `false` and `Object.is(-0, -0)` is `true`. That is the tool you want when the sign carries meaning — a direction, a delta, a formatted output where `-0` would look like a bug to a user. ## Writing it yourself A classic exercise is to implement `Object.is` with only `===` and arithmetic, which shows exactly where the two divergences live: ```js function sameValue(x, y) { if (x === y) { // === already said equal; the only false positive is +0 vs -0. // 1/0 is Infinity while 1/-0 is -Infinity, so division separates them. return x !== 0 || 1 / x === 1 / y; } // === said not equal; the only false negative is NaN vs NaN, // and NaN is the one value that is not equal to itself. return x !== x && y !== y; } ``` Read that as a two-line summary of the whole topic: strict equality is too generous about zeros and too strict about `NaN`, and SameValue corrects both. ## What Object.is is not It is not a deep or structural comparison. `Object.is([1], [1])` is `false`, exactly like `===`, because both are reference comparisons of two distinct arrays. Candidates who describe `Object.is` as "the thorough equality check" have generalised from the name; it is thorough only about primitive value identity. It is also not a replacement for `===` in normal code. It is a function call rather than an operator, it reads worse in a condition, and its two differences are surprises when you did not want them: comparing a computed delta to `0` with `Object.is` will report a difference for `-0`, which is almost never what a caller meant. The rule of thumb is: `===` by default; `Object.is` when the point of the line is `NaN` identity or the sign of zero. ## Where the language uses SameValue internally SameValue is not only exposed through `Object.is` — the specification uses it in property machinery. When you redefine a property with `Object.defineProperty`, a non-configurable, non-writable data property can only be "redefined" with a value that is the same value; otherwise the call throws. That check is SameValue, not strict equality, so redefining such a property from `0` to `-0` is rejected while a redefinition to the identical value is allowed. ## The bigger picture JavaScript ends up with four sameness comparisons: loose equality, strict equality, SameValue (`Object.is`) and SameValueZero (used by `Array.prototype.includes`, `Set` membership and `Map` keys). SameValue and SameValueZero differ only in the zero case — SameValueZero treats `-0` and `0` as the same while still matching `NaN` with `NaN`. Knowing that `Object.is` sits at the strictest end of that ladder is usually enough to answer any variant of the question.