ProfileDima's FE Handbook

Type Coercion and Equality

"Just always use === and you'll be fine."

You've probably heard this advice a hundred times. It's decent advice for beginners, but it sidesteps a fundamental question: why does JavaScript have two equality operators in the first place? And what exactly is happening when you use ==?

Understanding type coercion isn't just about avoiding bugs — it's about truly knowing what your code is doing. Let's demystify one of JavaScript's most misunderstood features.

What is Type Coercion?

Type coercion is JavaScript's automatic conversion of values from one type to another. When you compare or combine values of different types, JavaScript doesn't throw an error — it tries to make the operation work by converting one or both values.

There are two kinds:

  • Implicit coercion — JavaScript does it automatically (like in "5" * 2)
  • Explicit coercion — You do it intentionally (like Number("5") * 2)

The == operator (loose equality) uses implicit coercion to compare values. The === operator (strict equality) does not — it requires both type and value to match.

Why Does This Exist?

JavaScript was designed in 10 days to be beginner-friendly and forgiving. Brendan Eich wanted a language where things "just worked" rather than crashing on type mismatches.

// In many languages, this would be an error
"5" + 3  // JavaScript: "53" (string concatenation)
"5" - 3  // JavaScript: 2 (numeric subtraction)

This flexibility was a feature, not a bug — it made the language approachable for web designers adding simple interactivity. But as applications grew complex, this "helpfulness" became a source of subtle bugs.

The === operator was added later to give developers a way to opt out of coercion when they needed predictable comparisons.

Let's See It in Action

Basic Example: The Two Equalities

// Strict equality (===): No coercion, types must match
5 === 5        // true
5 === "5"      // false — different types
null === undefined  // false — different types

// Loose equality (==): Coerces types before comparing
5 == "5"       // true — "5" converted to 5
1 == true      // true — true converted to 1
null == undefined  // true — special rule!

The key difference: === asks "Are these the exact same type AND value?" while == asks "Can these be made equal after conversion?"

The Coercion Algorithm

When you use ==, JavaScript follows a specific set of rules (defined in the ECMAScript spec). Here's the simplified version:

// Rule 1: If same type, just compare values (same as ===)
"hello" == "hello"  // true
42 == 42            // true

// Rule 2: null and undefined are only equal to each other
null == undefined   // true
null == 0           // false
undefined == false  // false

// Rule 3: Number vs String → convert string to number
42 == "42"          // true ("42" becomes 42)
0 == ""             // true ("" becomes 0)
0 == "0"            // true ("0" becomes 0)

// Rule 4: Boolean vs anything → convert boolean to number first
true == 1           // true (true becomes 1)
false == 0          // true (false becomes 0)
true == "1"         // true (true→1, then compare 1=="1"→true)
false == ""         // true (false→0, ""→0, 0===0)

// Rule 5: Object vs primitive → convert object using valueOf/toString
[1] == 1            // true ([1].toString() is "1", then "1"→1)
["a"] == "a"        // true (["a"].toString() is "a")

Real-World Usage: When Loose Equality Makes Sense

There's one case where == is genuinely useful:

// Checking for null OR undefined in one comparison
function processValue(value) {
  // Using ==, null and undefined are treated as equal
  if (value == null) {
    return "No value provided";
  }
  return value.toUpperCase();
}

processValue(null);      // "No value provided"
processValue(undefined); // "No value provided"
processValue("hello");   // "HELLO"

// The strict equivalent requires two checks
if (value === null || value === undefined) { ... }
// Or use nullish check
if (value == null) { ... }  // Same thing, less typing

Many experienced developers use value == null intentionally — it's shorter and clearly signals "checking for null or undefined."

Watch Out: The Infamous Gotchas

// ❌ These all evaluate to true with ==
"0" == false    // true — "0"→0, false→0
"" == false     // true — ""→0, false→0
" \t\n" == 0    // true — whitespace string→0
[] == false     // true — []→""→0, false→0
[] == ![]       // true — wait, WHAT?!

// Let's break down that last one:
// ![] → false (arrays are truthy, so !truthy = false)
// [] == false
// [] → "" (array toString)
// "" → 0 (string to number)  
// false → 0
// 0 === 0 → true

And the classic that breaks beginners' brains:

// ❌ Transitivity doesn't work with ==
"0" == false   // true
0 == false     // true
"0" == 0       // true

// But...
"0" == ""      // false! (both are strings, no coercion)

Here's the fix — just be explicit:

// ✅ Use strict equality and explicit conversion
const input = "5";

// If you want numeric comparison
if (Number(input) === 5) {
  console.log("It's five!");
}

// If you want string comparison  
if (input === "5") {
  console.log("It's the string five!");
}

Advanced: How Objects Coerce

Objects follow a specific coercion path using Symbol.toPrimitive, valueOf(), and toString():

const weirdObject = {
  valueOf() {
    console.log("valueOf called");
    return 42;
  },
  toString() {
    console.log("toString called");
    return "hello";
  }
};

weirdObject == 42;      // valueOf called → true
weirdObject == "hello"; // valueOf called → false! (42 != "hello" after coercion)

// For string concatenation, toString is preferred
"Value: " + weirdObject;  // toString called → "Value: hello"

// You can control this with Symbol.toPrimitive
const smartObject = {
  [Symbol.toPrimitive](hint) {
    if (hint === "number") return 100;
    if (hint === "string") return "hundred";
    return true; // default
  }
};

Number(smartObject);  // 100
String(smartObject);  // "hundred"
smartObject + "";     // "hundred"

Interview Classic: What's the Output?

console.log([] + []);
console.log([] + {});
console.log({} + []);

Think about it before reading the answer...

console.log([] + []);   // "" (both become "", then concatenate)
console.log([] + {});   // "[object Object]" (""+"[object Object]")
console.log({} + []);   // "[object Object]" OR 0 depending on context!

// In most environments, {} + [] in a statement position
// treats {} as an empty block, so it's really just +[]
// +[] → +"" → 0

How to Think About This

Here's a mental model that helps: think of == as "try to find common ground" and === as "no compromises."

When you use ==, JavaScript asks: "If I squint hard enough and convert these values, can I make them equal?" Sometimes this squinting leads to absurd conclusions (like [] == ![]).

When you use ===, JavaScript asks: "Are these literally the same type and value? No conversions, no tricks?"

💡 The Practical Rule: Use === by default. Use == null when checking for null/undefined. Reach for == only when you explicitly want coercion and understand exactly what conversions will happen.

Here's a decision framework:

  1. Am I checking for null or undefined? → value == null is fine
  2. Am I comparing user input (strings) to numbers? → Convert explicitly, then use ===
  3. Everything else? → Use ===

Test Yourself

Before moving on, make sure you can answer:

  • What will "1" == true return, and what's the step-by-step coercion?
  • Why does [] == false return true but [] === false return false?
  • What's the only scenario where == is commonly preferred over ===?
  • What will null == 0 return? What about null >= 0?
  • How does an object get converted to a primitive when used with ==?

Related Topics

  • Truthy and Falsy Values — Understanding which values coerce to true or false in boolean contexts is essential for mastering coercion
  • Explicit Type Conversion — Number(), String(), Boolean() and other ways to convert types intentionally
  • Object.is() — A third equality comparison that handles edge cases like NaN === NaN (false) vs Object.is(NaN, NaN) (true)
  • The Abstract Equality Algorithm — The spec defines exactly how == works, step by step

Go Deeper