The Case of the Misidentified null

Most developers eventually encounter this line of code:

typeof null // "object"

And the reaction is usually immediate:

“Wait… what?”

Because null is not an object.

It represents the intentional absence of a value.

So why does JavaScript identify it as one?

The Investigation Begins

Back in the 1990s, JavaScript engines were designed for speed and memory efficiency.

Values were stored inside tiny 32-bit memory containers.

To quickly identify what kind of value was being stored, the engine used hidden binary markers called type tags.

Think of them like internal evidence labels.

Something similar to:

(Simplified conceptual representation)

The Critical Mistake

Objects were associated with a zero-based type pattern internally.

But null had a problem.

Its internal representation was essentially all zeroes:

00000000000000000000000000000000

So when JavaScript checked the value’s type…

it accidentally matched the object tag.

The engine effectively interpreted:

“all zeroes”

as:

“object”

And just like that…

null was misidentified.

Why Wasn’t the Bug Fixed?

Because the mistake spread everywhere.

By the time developers realized the issue, websites and applications across the internet already depended on this behavior.

Changing it would break massive amounts of existing code.

So the bug became permanent.

The Developer Workaround

Instead of writing:

typeof value === "object"

Developers learned to safely check:

value !== null && typeof value === "object"

That extra condition prevents null from slipping through.

Closing the Case

What makes this bug fascinating isn’t just the incorrect output.

It’s the fact that a tiny implementation detail from the early days of JavaScript…

still survives in modern applications decades later.

One small mistake.

One massive legacy.

One very strange crime scene.

📹 Surveillance Footage

The full investigation is available on TikTok:

View the Evidence

What’s the weirdest JavaScript behavior you’ve encountered?