== vs === in JavaScript: What's the Difference and How Not to Break Your Code

Introduction: Why This Question Haunts Thousands of Developers

If you've ever written in JavaScript, you've likely encountered a situation where your code didn't work as expected, and the culprit was the comparison operators == and ===. The question "Which equals operator (== vs ===) should be used in JavaScript comparisons?" is among the top most popular on Stack Overflow — it has been viewed by millions of developers. And this is no coincidence.

The difference between loose (==) and strict (===) equality is one of the first pitfalls that beginners fall into. But even experienced programmers sometimes forget the nuances. In this article, we will break down all the pitfalls, show real-world examples of how to avoid common mistakes, and give clear rules on when to use what.

Ready? Let's go!

1. Basics: What are == and === in JavaScript

Both operators are used to compare values. But there is a key difference:

\n
• == (loose equality) — compares values with type coercion. If the types are different, JavaScript will try to convert one value to the type of the other, and then compare.
\n
• === (strict equality) — compares both the value and the data type without any conversion. If the types are different — immediately false.
\n

Sounds simple? But the devil, as always, is in the details.

Warm-up Example

console.log(5 == "5");   // true (number 5 is coerced to string "5")\nconsole.log(5 === "5");  // false (different types: number vs string)

The first case is a classic trap: you expect false, but you get true. And that's just the beginning.

2. How JavaScript Coerces Types: Non-Obvious Moments

When using ==, the interpreter performs complex coercion algorithms. Here are a few examples that might surprise you:

Strings and Numbers

console.log(0 == false);   // true (false → 0)\nconsole.log("" == false);  // true ("" → 0)\nconsole.log(null == undefined); // true (special rule)\nconsole.log(null === undefined); // false

null and undefined are especially dangerous: with == they are equal to each other, but not equal to anything else (not even false or 0).

Arrays and Objects

console.log([] == false);   // true (empty array → "" → 0)\nconsole.log([1] == true);   // true ([1] → "1" → 1)\nconsole.log([1,2] == "1,2"); // true (array → string)

At this point, you can lose the thread of logic. It's precisely because of such "surprises" that many developers categorically refuse to use ==.

3. Real-World Mistakes from Practice: When == Breaks Logic

Let's break down a few situations that can lead to bugs in production.

Mistake 1: Checking for Emptiness

function isEmpty(value) {\n    return value == false; // bad!\n}\n\nconsole.log(isEmpty(0));      // true\nconsole.log(isEmpty(""));     // true\nconsole.log(isEmpty(null));   // true? No, null == false → false\nconsole.log(isEmpty([]));     // true? No, [] == false → true\nconsole.log(isEmpty("text")); // false\n

It seems to work, but in reality null is not equal to false with == — it's false. And an empty array is considered true? No, it is coerced to 0. Total confusion. The correct approach is to use strict checking or explicit conditions.

Mistake 2: Comparing with undefined

let user = { name: "Alice" };\nif (user.age == undefined) { // ok, but better ===\n    console.log("Age not specified");\n}\n// But if age = null?\nuser.age = null;\nconsole.log(user.age == undefined); // true! But it should be false