JavaScript Null Type Inference

Why This Question Matters

If you've spent any time in a JavaScript interview or a technical quiz, you've probably run into this one. It’s a classic "gotcha" question. On the surface, console.log(typeof null) looks like a beginner-level query. You’d think, "I'm checking the type of null, so it should return 'null', right?"

Wrong.

This isn't just a trivia question to trip you up. It highlights a fundamental quirk in how JavaScript was built and how it handles types. Understanding this helps you avoid subtle bugs when you're checking for empty values or trying to validate data coming from an API. If you assume typeof is always reliable, you're going to hit a wall eventually.

Understanding the Code

Let's look at the snippet:

console.log(typeof null);

The typeof operator is designed to tell us what "kind" of value a variable holds. For a string, it returns "string". For a number, it returns "number".

When we pass null into it, we expect it to behave logically. In most languages, null represents the intentional absence of any object value. It's a primitive. So, logically, typeof null should return "null".

But when you run this in Chrome DevTools or Node.js, you get:
"object"

Wait, what? null is not an object. It's a primitive. So why is JavaScript lying to us?

The answer is a legacy bug. Back in the first version of JavaScript, values were stored in 32-bit units. These units consisted of a type tag (a few bits) and the actual value. The type tag for objects was 000.

As it turns out, the value null was represented as the null pointer (zero with all bits zero). Because its representation started with 000, the typeof operator saw those zeros and thought, "Yep, this is an object."

By the time developers realized this was a mistake, JavaScript was already widely used. Fixing it would have broken millions of websites across the web. So, the bug became a feature. It's stayed in the language for decades for the sake of backward compatibility.

Finding the Correct Answer

In a multiple-choice scenario, you'll likely see options like:
A) "null"
B) "object"
C) "undefined"
D) "string"

The correct answer is Option B.

Here is why the others are wrong:
- "null": While this is what we *want* it to be, the language doesn't actually return this string.
- "undefined": null and undefined are different. undefined means a variable has been declared but not assigned a value. null is an assigned value that represents "nothing." typeof undefined actually returns "undefined", but null doesn't follow that pattern.
- "string": null is clearly not a string.

Common Mistakes Developers Make

The biggest mistake is trusting typeof for null checks.

A lot of junior devs write code like this to see if a variable is an object:

if (typeof myVariable === 'object') {
  // Do object things
}

The problem? If myVariable happens to be null, this block will execute because typeof null is "object". If you then try to access a property on that variable (like myVariable.name), your app will crash with the dreaded TypeError: Cannot read property 'name' of null.

Another common point of confusion is the difference between null and undefined. Remember: undefined is the default state of "not set," while null is a deliberate choice by the developer to say "this is empty."

Real-World Usage

In a production environment, you can't rely on typeof to verify if something is actually an object. To properly check if a value is a "real" object (and not null), you have to combine checks.

The most reliable way to check for a non-null object is:

if (myVariable !== null && typeof myVariable === 'object') {
  // Now we know it's actually an object
}

Alternatively, if you want to check if a value is "falsy" (which covers both null and undefined), you can just do:

if (!myVariable) {
  // Handles null, undefined, 0, false, and empty strings
}

In modern TypeScript projects, this is less of a headache because the type system catches these mismatches during development. But in vanilla JS, being mindful of this bug is the difference between a stable app and one that crashes randomly when an API returns a null field.

Key Takeaways

- typeof null returning "object" is a historical bug from the early days of JS.
- It was never fixed to avoid breaking the internet.
- null is a primitive, not an object, despite what typeof claims.
- Never use typeof alone to validate that a value is an object; always check for null first.
- Understanding the difference between null and undefined is crucial for writing bug-free logic.