In JavaScript, null == undefined is true, but null == 0 and null == false are both false. Which rule of the loose-equality algorithm explains this?

## The rule, stated exactly The abstract equality comparison checks, right after the same-type shortcut, whether one operand is `null` and the other is `undefined`. If so the answer is `true`. Nothing later in the algorithm ever converts `null` or `undefined` into another type — there is no "ToNumber(null)" branch in the comparison. That is the whole explanation, and it produces a clean, memorable result: **`null` and `undefined` are loosely equal to each other and to nothing else in the language.** ```js console.log(null == undefined); // true - the special rule console.log(null == null); // true - same type, strict console.log(undefined == undefined); // true console.log(null == 0); // false console.log(null == false); // false console.log(null == ''); // false console.log(null == NaN); // false console.log(undefined == 0); // false ``` (One host-provided legacy object in browsers, `document.all`, is deliberately specified to compare loosely equal to `null` and `undefined` as a web-compatibility quirk. It is trivia, not a rule you can build on.) ## Why people expect otherwise The usual wrong prediction is `null == 0` being true, and it comes from mixing up two different conversions. `Number(null)` really is `0` — explicit numeric conversion of `null` produces zero, which is why `null + 1` is `1`. But the loose-equality algorithm never performs that conversion; it short-circuits on the null/undefined step and then runs out of applicable rules. So explicit conversion and implicit comparison genuinely disagree here, and the candidate who says "but `Number(null)` is 0" is right about the conversion and wrong about the comparison. The same trap appears with relational operators, which use a *different* algorithm that does convert: `null >= 0` is `true` and `null > 0` is `false`, while `null == 0` is `false`. So `null` is simultaneously "not equal to 0" and "greater than or equal to 0". This is a good illustration that `==` is its own algorithm rather than a general coercion policy applied everywhere. ## null is falsy, but that is a separate system `null` and `undefined` are both falsy, and so are `0`, `''`, `NaN` and `false`. It is tempting to conclude that falsy values are loosely equal to one another. They are not. Falsiness is decided by a boolean conversion used in `if` and `!`; loose equality is decided by the algorithm above. The two overlap in some cases (`'' == 0` is true) and diverge sharply in others (`null == 0` is false; `'0' == false` is true even though `'0'` is truthy). Treat them as unrelated mechanisms that happen to share some inputs. ## The one useful idiom Because the rule is exact, `x == null` is a precise test for "x is null or undefined" and nothing else: ```js function has(value) { return value != null; // false only for null and undefined } console.log(has(0)); // true - zero is a real value console.log(has('')); // true - empty string is a real value console.log(has(NaN)); // true console.log(has(null)); // false console.log(has(undefined)); // false ``` This is the check you want when a parameter is optional and `0`, `''` or `false` are legitimate values — a quantity, a search term, a toggle. Writing `if (!value)` there is the classic bug: it rejects `0` and `''` along with the genuinely-missing cases. ## Distinguishing the two absent values when you must `x == null` deliberately blurs `null` and `undefined`. Sometimes that distinction matters: `undefined` typically means "never set / property absent / argument omitted", while `null` usually means "explicitly set to nothing", and some data sources use them differently. When the difference is meaningful, test strictly — `x === undefined` or `x === null` — and be explicit in the code about which case you are handling. A default parameter value, for example, is applied only for `undefined`, never for `null`, so a function that receives `null` will not get its default. ## What to say in the interview State the rule first: there is an explicit step for null-versus-undefined, and neither value is ever coerced. Then give the two consequences — `null == 0` is false despite `Number(null)` being `0`, and `x == null` is an exact nullish check. If you have room, mention that relational comparison uses a different algorithm and does convert, so `null >= 0` is true. That trio shows you are reading the algorithm rather than reciting habits.