Why === Beats == in JavaScript — Always

Loose equality (==) converts values before it compares them. Strict equality (===) compares type and value. I use strict equality in every new file. The conversion, if I want it, is a line I can read.

If you have not read the companion piece, start with type coercion. Equality bugs are coercion bugs wearing a comparison operator.

Examples that fail review

selectedId == product.id
// selectedId came from a query string: "42"
// product.id came from the database: 42
// == is true. A later .includes or Map lookup with === is false.

status == 0
// status is "0" from a checkbox value attribute
// == is true, so "pending" and "done" logic both misfire

user.role == false
// never means what the author thought

The fix is boring. Convert once, then compare strictly.

const selectedId = Number(searchParams.get("id"));
if (!Number.isFinite(selectedId)) return notFound();
const active = products.find((p) => p.id === selectedId);

The null and undefined exception people quote

null == undefined is true. Some codebases still write value == null to catch both. I do not. Two explicit checks are easier to search:

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

TypeScript's value == null narrows both, which is why the shortcut survives in typed code. If your team uses it, keep it in one helper so the rest of the repo stays on ===.

The rule

1. Compare with === and !==.
2. Convert types in a named step before the comparison.
3. Reject NaN with Number.isFinite, not with ==.
4. Do not "fix" a failing === by switching to ==. The types disagree for a reason.