JavaScript null vs undefined: Difference, Checks, and When to Use Which

Two Ways to Say "Nothing"

Most languages have one value for absent. JavaScript has two: null and undefined. They behave similarly enough to confuse beginners and differently enough to bite experienced developers. Understanding the split is worth ten minutes of your time.

The short version:

• undefined is what JavaScript gives you when something is missing.
• null is what you write when you want to say "intentionally empty."

Notice the pattern: every undefined above happened because JavaScript couldn't find a value. The null happened because someone typed it.

Where undefined Comes From

undefined shows up in a handful of specific situations, all variations on "no value available":

In every case, JavaScript reached for a value and found nothing there. undefined is the engine's way of saying "I looked, there was no value."

You can assign undefined yourself (let x = undefined;), but you shouldn't. Let it stay the signal for "JavaScript didn't find anything." Use null when you're the one making the decision.

Where null Comes From

null only appears when someone wrote it. That's the whole point — it's an intentional marker.

DOM APIs use null a lot: document.getElementById("missing") returns null, not undefined, because the browser is explicitly telling you "I searched, and the answer is no element." JSON.parse("null") also gives you null — JSON has no undefined.

The mental model: undefined is the default absence, null is a chosen absence.

The typeof Quirk

Here's the famous one:

typeof null returning "object" is a bug from 1995 that couldn't be fixed without breaking existing websites, so it's been preserved forever. null is not an object — it's a primitive, same as undefined, numbers, strings, and booleans. The typeof result just lies about it.

Practical consequence: typeof is useless for detecting null. Use direct comparison:

Or, more often, check for either at once — the next section.

Checking for Either: the == null Idiom

Most of the time you don't care which absent value you have — you just want to know if something is missing before using it. The idiomatic check is loose equality with null:

value == null is true for exactly null and undefined and false for everything else — including 0, "", and false, which is usually what you want. This is the one situation where == is preferred over ===. Linters know this and allow it.

If you want to be explicit, value === null || value === undefined means the same thing and reads clearly.

Nullish Operators: ?? and ?.

Two operators were added specifically to make working with null and undefined easier. Both treat the two values identically and leave everything else alone.

Nullish coalescing (??) supplies a fallback only when the left side is null or undefined:

Compare with ||, which would replace 0 with 3 because 0 is falsy. ?? is stricter: it only fires for the two nullish values.

Optional chaining (?.) stops evaluating a chain and returns undefined when it hits null or undefined:

Both operators exist because "is this value nullish?" is such a common question. They're covered in depth later in the curriculum.

Default Parameters Only Fire for undefined

A subtle but important rule: default parameter values kick in for undefined only, not for null.

Passing null is treated as "I explicitly chose no value" and respected as-is. If you want null to trigger a fallback too, use ?? inside the function:

This distinction trips people up regularly. Defaults handle missing arguments; ?? handles nullish arguments.

JSON and the Missing undefined

JSON has null but no undefined. That leads to silent surprises when you serialize:

The age field disappeared entirely — JSON.stringify drops properties with undefined values. null survives because JSON supports it. Round-tripping an object through JSON is a common way for undefined properties to quietly vanish.

In arrays, undefined becomes null:

If you're designing an API payload, prefer null over undefined for "no value" fields. It survives the trip.

When to Use Which

A reasonable convention for your own code:

• Let undefined mean "not provided" — missing arguments, unset variables, absent properties. Don't assign undefined manually.
• Use null when you want to explicitly communicate "this is intentionally empty" — a logged-out user, an unselected option, a cleared form field.
• Accept both at API boundaries (use == null or ??), but be consistent about which one you produce.

Some style guides (including TypeScript's) skip null entirely and use only undefined. That's defensible — one value is simpler than two. Pick a rule per project and apply it everywhere.

Next: Type Coercion

null and undefined behave in specific ways when JavaScript converts them to numbers, strings, or booleans — Number(null) is 0, but Number(undefined) is NaN, and that kind of asymmetry causes real bugs. Type coercion is up next, and once you see the full rules, a lot of JavaScript's quirks stop being mysterious.