In JavaScript, what does the strict equality operator === compare, and how does it behave when its two operands have different types?

## The operator in one rule The strict equality operator `===` (the specification calls the operation *IsStrictlyEqual*) answers one question: are these two operands of the same type, and, given that, the same value? It never converts anything. That property is what makes it predictable — the result depends only on the two operands as written, not on a conversion you have to reconstruct in your head. The steps are short: 1. If the operands have different types, return `false`. Stop. 2. Numbers: if either side is `NaN`, return `false`; `+0` and `-0` are treated as equal; otherwise compare the numeric values. 3. Strings: equal when they have the same length and the same code units in the same order. 4. Booleans, `null`, `undefined`: equal when they are the same value (`null === null`, `undefined === undefined`). 5. Symbols: equal when they are the same symbol value. 6. Objects (including arrays and functions): equal only when both operands are the *same* object — the same reference. ## "Different types" is a hard stop This is the part interviewers actually probe. There is no leniency, no "but they look the same": ```js '1' === 1; // false — String vs Number 1n === 1; // false — BigInt vs Number null === undefined; // false — two distinct types, two distinct values true === 1; // false — Boolean vs Number ``` Each of those is `false` for one reason only: the types differ, so the operator returns without looking at the values. If you want the number five out of a string, you convert it yourself (`Number(input) === 5`), which puts the conversion in the source where a reader can see it. ## Objects compare by reference JavaScript has no built-in structural comparison. When both operands are objects, `===` asks whether they are the same object in memory: ```js const a = { v: 1 }; const b = a; // same object, second name const c = { v: 1 }; // a different object with equal contents a === b; // true a === c; // false a.v = 2; a === b; // still true — mutation does not change identity [] === []; // false — two fresh arrays ``` Beginners often expect `a === c` to be true because the contents match, and expect `a === b` to become false after mutating `a`. Both intuitions are wrong: contents are irrelevant, identity is everything. Comparing contents means writing it yourself — walk the keys, compare each value, and decide up front how you want to treat nested objects, missing keys and the two odd numbers below. ## The two number surprises Strict equality is exact for every value except two number cases, and they pull in opposite directions. `NaN === NaN` is `false`. `NaN` is the result of an arithmetic operation with no meaningful numeric answer (`0/0`, `Number('abc')`, `Math.sqrt(-1)`), and floating-point arithmetic defines it as unequal to everything, itself included. A useful side effect: `x !== x` is `true` for exactly one value, `NaN`, which is how hand-written checks detect it. `-0 === 0` is `true`. Negative zero is a real, distinct value that arithmetic can produce (`-1 * 0`, `Math.round(-0.2)`), but strict equality deliberately ignores the sign of zero so ordinary numeric code does not have to care. ```js NaN === NaN; // false -0 === 0; // true ``` Those two disagreements are the entire reason the language grew additional sameness comparisons: `Object.is`, which flips both answers, and the SameValueZero rule used by `Array.prototype.includes`, `Set` and `Map`, which flips only the `NaN` one. ## Places the language applies === for you You inherit strict-equality behaviour even when you do not type the operator: ```js switch (NaN) { case NaN: console.log('never runs'); default: console.log('this runs'); } [NaN].indexOf(NaN); // -1 — indexOf compares with strict equality [-0].indexOf(0); // 0 — because -0 === 0 ``` `switch` selects a clause with strict equality, so a `case NaN:` label is dead code and a `case -0:` label matches a plain `0`. `Array.prototype.indexOf` and `lastIndexOf` compare the same way, which is why they cannot find `NaN`. ## Practical guidance Default to `===` everywhere. It is the comparison whose result you can predict by reading the line, and linters flag its absence for that reason. Reach past it only for the two cases it is documented not to handle: use a `NaN`-aware comparison when a numeric pipeline can produce `NaN`, and use `Object.is` when the sign of zero genuinely carries meaning. And remember that no built-in comparison inspects object contents — structural comparison is something you write or import, not something an operator gives you.