Why Does typeof null Return "object"?

The honest answer is that it is a bug from the very first implementation of JavaScript, and it was never fixed because fixing it would break working code all over the web. The language specification now requires the behaviour, so it is a quirk that is baked into the standard.

console.log(typeof null);          // 'object'
console.log(typeof {});             // 'object'
console.log(typeof []);             // 'object'
console.log(typeof function () {});  // 'function'

// The reliable check is a strict comparison.
function isNull(value) {
  return value === null;
}

console.log(isNull(null));          // true
console.log(isNull({}));            // false
console.log(isNull(undefined));     // false

The historical reason comes from how the first JavaScript engines stored values inside the computer. Every value carried a type tag, and an object was marked by setting one low bit in that tag, which said "this is an object and not a simple value". The null pointer was a special value that lived in the same part of memory, so it picked up the same object marker by accident. Arrays and functions later moved into their own categories, but null stayed exactly where it was.

The behaviour was noticed early and reported as a risk to compatibility. The response from the standards body was that the danger of breaking sites was bigger than the benefit of being correct, and that a future major revision might sort it out. That revision has never arrived.

The practical consequence is that typeof is useless as a way to detect null. Any code of the form if (typeof value === 'object') will treat null as an object, and then it will crash when it tries to read a property from it. Use a strict equality comparison instead, because it is exact and it never changes the type of what it compares.

Use a strict equality comparison against null. The expression value === null is true for exactly one value in the whole language, and it is false for everything else. That includes 0, the empty string, and false, which are all falsy but are perfectly good data.

That last point is why the loose alternatives are a problem. The double-equals comparison against null happens to work for the null value, but it also changes the type of the right-hand side, which makes it fragile and confusing to read. The truthiness check is worse. An empty string, 0, false, and an empty array are all falsy, so a naive if (value) test throws away real data along with the missing values.

You will also see people write the check the other way round, testing that a value is not null. That is fine, but if the same variable may also be missing, you need the nullish coalescing operator to give you a fallback. That operator only replaces the left side when it is null or a value that was never assigned, and it leaves every other falsy value alone. That is the difference between nullish coalescing and the double-bar fallback, which also replaces 0 and the empty string.

There are two extra notes that make a full answer. Optional chaining short-circuits on null, so optional?.access?.deep is safe even when a middle step is missing, and it gives back no value rather than throwing. And in TypeScript, a type that allows null is written with a question mark or with a union, and the compiler then forces you to handle that case at every place you use the value. That removes the need to remember the check at all.