Introduction

Even though the title is abbreviated, this question is almost always about the difference between == and === in JavaScript. The short answer is that == allows type coercion, while === requires both type and value to match exactly.

That sounds minor, but it changes the behavior of conditionals in ways that can be surprising. In modern JavaScript code, === is the safer default because it is much easier to reason about.

== Uses Type Coercion

Loose equality tries to make operands comparable by converting them first:

console.log(5 == "5");    // true
console.log(false == 0);  // true
console.log("" == 0);     // true

Those results are legal JavaScript, but they are not always obvious from a quick read. That is why == can create bugs when values come from forms, APIs, or loosely typed data sources.

=== Requires Type and Value to Match

Strict equality does not do the same coercion:

console.log(5 === "5");    // false
console.log(false === 0);  // false
console.log("" === 0);     // false

This is the reason most teams prefer ===. It makes comparison rules far more predictable and keeps type normalization explicit instead of implicit.

null and undefined Are a Special Case

One famous corner case is:

console.log(null == undefined);   // true
console.log(null === undefined);  // false

Because of this, some codebases intentionally allow value == null as a shorthand for "value is either null or undefined." That can be a legitimate pattern when used deliberately:

function isMissing(value) {
  return value == null;
}

Outside that specific case, strict equality is usually the better rule.

Objects Compare by Reference

For objects, both operators compare references rather than structure:

1const a = { id: 1 };
2const b = { id: 1 };
3const c = a;
4
5console.log(a == b);   // false
6console.log(a === b);  // false
7console.log(a === c);  // true

If you need deep equality, use a dedicated comparison function or a domain-specific validation strategy. Neither == nor === does structural comparison for you.

Normalize Input Instead of Relying on Coercion

If incoming values might be strings, booleans, or numbers, normalize them first:

1function isAllowedAge(value) {
2  const age = Number(value);
3  if (Number.isNaN(age)) return false;
4  return age >= 18;
5}
6
7console.log(isAllowedAge("20"));
8console.log(isAllowedAge("abc"));

This is better than writing comparison logic that depends on JavaScript's coercion rules to "help."

Team Conventions Matter

Many teams enforce strict equality with lint rules:

1{
2  "rules": {
3    "eqeqeq": ["error", "always", { "null": "ignore" }]
4  }
5}

That keeps equality behavior consistent across the codebase and prevents accidental drift into coercion-heavy logic.

Common Pitfalls

The biggest mistake is using == in important conditionals without understanding what conversions may happen first. Code may appear to work until one input arrives as a string instead of a number.

Another common issue is forgetting that object equality is reference equality. Two distinct objects with the same fields are still not equal under either operator.

Developers also mix == and === casually in the same module, which makes reasoning about input handling harder than it needs to be.

Finally, do not rely on coercion when explicit conversion would make the logic clearer. Normalizing input is usually the more maintainable approach.

Summary

• In JavaScript, == performs type coercion and === does not.
• '=== is the safer default because its behavior is easier to predict.'
• 'null == undefined is a special case that some codebases use intentionally.'
• Objects are compared by reference under both operators.
• Prefer explicit input normalization over depending on coercion side effects.