JavaScript Data Types and Coercion: ==, ===, Truthiness, and NaN Explained

JavaScript’s type system has a terrible reputation, mostly earned from conference-talk screenshots: [] + {} is "[object Object]", "5" - 1 is 4, NaN !== NaN. It looks lawless.

It isn’t. Coercion follows a small, fixed rulebook — weird in places, but mechanical. This guide teaches the rulebook: the eight types, the null/undefined split, truthiness, why === is the default and == is legacy, and the handful of coercion rules that let you predict the screenshots instead of being ambushed by them.

The Eight Types

JavaScript has exactly seven primitive types plus objects:

Primitives are immutable values compared by value; objects are mutable and compared by reference:

"abc" === "abc"          // true  — same value
{ a: 1 } === { a: 1 }    // false — two different objects!
const x = { a: 1 }, y = x;
x === y                   // true  — same reference

That object-equality behavior surprises everyone once: there is no built-in deep equality for objects. Two structurally identical objects are not ===. Comparing contents means comparing fields yourself, using a library, or (crudely) JSON.stringify both — with its ordering caveats.

Notable details in the table: numbers are all doubles — there is no int type. Integer math is exact up to Number.MAX_SAFE_INTEGER (2⁵³ − 1 ≈ 9 quadrillion); beyond that you need BigInt (this bites real systems that put database IDs through JS math). And yes, 0.1 + 0.2 === 0.30000000000000004 — that’s IEEE 754 floating point, identical in Java and Python; it’s not a JS quirk, just the one JS gets screenshot-blamed for. Money: work in integer minor units (paise/cents).

typeof is your runtime type probe, with two famous outputs to memorize:

typeof 42          // "number"
typeof "hi"        // "string"
typeof undefined   // "undefined"
typeof null        // "object"    ← the unfixable 1995 bug — null is NOT an object
typeof []          // "object"    ← arrays are objects; use Array.isArray(x)
typeof (() => {})  // "function"  ← the one non-primitive typeof distinguishes

null vs. undefined: One Distinction, Actually Useful

Two empty values, one convention that makes them coexist sanely:

• undefined — the system’s “nothing here”: unset variables, missing properties, missing function arguments, functions that return nothing.
• null — the programmer’s “deliberately nothing”: you assign it to say “checked, and the answer is no value.”

let pending;                 // undefined — never set
const user = { name: "Ada" };
user.email                   // undefined — no such property
const match = s.match(/x/);  // null — the API says "searched, found nothing"

In your own code: read undefined as “nobody set this,” write null when you mean “explicitly empty.” And when checking for either, modern JS gives you precision tools:

value ?? fallback        // nullish coalescing: fallback ONLY for null/undefined
user?.address?.city      // optional chaining: short-circuits to undefined at first null/undefined
count ?? 10              // 0 stays 0!  (count || 10 would wrongly replace 0)

That last line is the practical difference between ?? and ||: || replaces any falsy value (including 0, "", false — often legitimate data); ?? replaces only true absence. Since ES2020, ?? + ?. have quietly eliminated an entire genre of defensive-checking boilerplate. Use them.

Truthiness: The Whole List

Conditions in JS accept any value, coercing it to boolean. The falsy list is short enough to memorize completely — everything not on this list is truthy:

false   0  -0  0n   ""   null   undefined   NaN

Which means these are all truthy, and each has caught someone:

if ("false") { }     // truthy — non-empty string
if ([]) { }          // truthy — empty array is an object
if ({}) { }          // truthy — empty object too
if ("0") { }         // truthy — non-empty string!

Truthiness is genuinely convenient — if (items.length), if (errorMessage) — but it has a classic failure mode: treating legitimate falsy data (0, empty string) as absence. A quantity of 0 or a middle name of "" is data, not nothing:

// bug: user typed 0, code thinks "not provided"
const qty = input || 1;
// fix:
const qty = input ?? 1;

The rule of thumb: truthiness for “does this collection/string have anything” checks; explicit comparisons (=== null, !== undefined, ??) whenever 0/""/false are valid values in your domain.

Coercion: The Rulebook Behind the Screenshots

Implicit conversion happens in three contexts, each with fixed rules:

To string — the + operator, when either side is a string:

"5" + 1        // "51"   — + prefers concatenation
1 + 2 + "3"    // "33"   — left-to-right: 3, then "33"
"" + 42        // "42"   — old-school number→string trick

To number — every other arithmetic operator, comparisons with </>, and unary +:

"5" - 1        // 4      — minus has no string meaning, so both sides → number
"5" * "2"      // 10
+"42"          // 42     — unary plus: terse string→number conversion
"abc" - 1      // NaN    — "abc" can't become a number
true + 1       // 2      — true → 1, false → 0

So the infamous asymmetry — "5" + 1 vs "5" - 1 — reduces to one sentence: + means concat if any string is present; every other math operator means numbers. Most viral “JS is broken” examples are this rule plus the object-to-primitive rule (objects become strings like "[object Object]", arrays join their elements: [1,2] + "" is "1,2"), applied consistently.

Explicit conversion — prefer it in real code; it documents intent:

Number("42")       // 42
Number("")         // 0        ← surprise worth knowing
Number(null)       // 0        ← and this
Number(undefined)  // NaN
parseInt("42px")   // 42       — parses a leading number, ignores the rest
parseFloat("3.9m") // 3.9
String(42)         // "42"
Boolean(x)         // truthiness, made explicit (same as !!x)

Number converts the whole string strictly; parseInt/parseFloat scavenge a leading number — pick by whether trailing junk should fail or be ignored. For user input, remember both accept garbage differently: validate before trusting.

NaN: The Value That Isn’t Equal to Itself

NaN (“not a number” — which is, of course, of type number) results from failed numeric operations: Number("abc"), 0/0, Math.sqrt(-1). Its defining property comes from the IEEE floating-point standard:

NaN === NaN            // false — NaN is not equal to ANYTHING, including itself
Number.isNaN(NaN)      // true  — the correct test
Number.isNaN("abc")    // false — checks "is this actually the NaN value"
isNaN("abc")           // true  — legacy global: coerces first, misleading; avoid

The practical hazards: NaN silently propagates (any arithmetic touching NaN yields NaN), so one bad parse can turn an entire calculation chain into NaN by the time you notice — and since NaN is falsy and unequal to everything, it slips through naive checks. Defenses: validate inputs at the boundary (Number.isFinite(x) is often the right gate — it rejects NaN and Infinity and non-numbers), and when a NaN appears, trace backwards to the earliest operation that could have produced it.

== vs ===: End of Debate

=== (strict equality) compares without coercion: different types → false, done. == (loose equality) coerces first, following an arcane table:

1 === "1"        // false
1 == "1"         // true  — string coerced to number
0 == false       // true
"" == 0          // true
null == undefined  // true  — and == with null matches ONLY undefined
null == 0        // false ← inconsistent with the previous lines' logic
NaN == NaN       // false — nothing helps NaN

The verdict, shared by every style guide, linter default, and this series: always === and !==. The single defensible use of == you’ll meet in the wild is x == null as an intentional shorthand for “null or undefined” — recognize it in code review, and prefer x === null || x === undefined or restructuring with ?? when writing.

Comparison has one more trap worth flagging: relational operators on mixed types. "10" < "9" is true (string comparison is lexicographic), while "10" < 9 is false (number coercion). If either side might be a string — user input, URL params, form fields — convert explicitly before comparing. Sorting has the same disease: [10, 9, 1].sort() gives [1, 10, 9] because default sort is stringwise; you want sort((a, b) => a - b), detailed in array methods.

Frequently Asked Questions

Why does JavaScript even have coercion? The 1995 design goal: scripts embedded in pages, written by non-programmers, should limp onward rather than crash. Form fields deliver strings; coercion made "5" * quantity work. In 2026 we have better tools (explicit conversion, TypeScript), but the don’t-break-the-web rule means the behavior is permanent — hence the strategy of knowing it while avoiding relying on it.

Does TypeScript fix all of this? Much of it: TS flags mixed-type comparisons and arithmetic at compile time, which is a big part of its value. But TS types vanish at runtime — data arriving from APIs, JSON, and users is whatever it is, so boundary validation (and understanding these rules) remains your job.

How do I check types reliably? typeof for primitives (minus the null bug), Array.isArray for arrays, x === null for null, Number.isFinite/Number.isNaN for numeric health, instanceof for class instances (with caveats across frames/realms). There is no one universal type check — that’s honest, if annoying.

What’s the deal with Object.is? A third equality: like === except Object.is(NaN, NaN) is true and it distinguishes +0/-0. Rarely needed directly, but it’s what Array.prototype.includes uses — which is why [NaN].includes(NaN) is true while [NaN].indexOf(NaN) is -1. Good trivia; better reason to use includes.

A Boundary-Validation Habit That Replaces Half of This Chapter

The deepest defense against coercion bugs isn’t memorizing rules — it’s ensuring types are known everywhere except the edges. Data enters JS programs from exactly a few doors: user input (always strings), URL params (strings), JSON APIs (whatever the server sent), storage (strings via localStorage). Convert and validate at the door, once:

function parseQuantity(raw) {
  const n = Number(raw);
  if (!Number.isInteger(n) || n < 1 || n > 999) {
    throw new RangeError(`Quantity must be 1-999, got "${raw}"`);
  }
  return n;
}

Past that function, quantity is a trustworthy integer — no downstream parseInt sprinkles, no || 1 guards, no wondering whether qty + 1 will concatenate. Every conversion rule in this chapter still applies inside the boundary function; it just applies in one place instead of fifty. This is the pattern TypeScript formalizes (types trusted inside, validation at the perimeter), and adopting it in plain JS makes the eventual TS migration nearly mechanical.

Self-Check

Predict each — the rulebook covers all of them:

1.  "10" - 5
2.  "10" + 5
3.  [] + ""
4.  0 ?? 7
5.  0 || 7
6.  Number("")
7.  "b" + "a" + +"a" + "s"     // a classic — hint: unary plus
8.  [3, 20, 100].sort()[0]
9.  NaN === NaN
10. typeof null

Answers: (1) 5 — minus means numbers. (2) "105" — plus with a string concatenates. (3) "" — array coerces to empty string. (4) 0 — nullish keeps falsy-but-present values. (5) 7 — || discards 0. (6) 0 — empty string → 0. (7) "baNaNs" — +"a" is NaN, concatenated. (8) 100 — stringwise sort puts “100” first. (9) false. (10) "object".

Score eight or more and coercion no longer owns you. Next: Functions — declarations vs arrows, parameters and defaults, and functions-as-values, the idea the entire rest of the language is built on.