How Does Type Coercion Work?

Type coercion is the engine converting a value from one type to another on its own. JavaScript is dynamically typed, so it will do this whenever an operator receives a type it cannot work with. The rule of thumb is that coercion happens with the arithmetic and string operators, and it does not happen with the strict equality operator.

console.log("5" + 3);      // "53" - one operand is a string, so both become strings
console.log("5" - 3);      // 2 - the minus sign only works on numbers
console.log("5" * "2");    // 10 - both operands are converted to numbers
console.log(true + 1);    // 2 - true becomes 1
console.log(null + 1);    // 1 - null becomes 0
console.log([] + {});     // "[object Object]" - both become strings

The reason this surprises people is that the plus sign is doing double duty. The specification defines addition with a string operand as string concatenation, and addition with two non-string operands as numeric addition. Every other arithmetic operator is numeric only, so it converts its operands first.

Objects are harder. Before an operator runs, the engine converts its operands to primitives using the standard conversion protocol, which looks for a valueOf method first and then a toString method. Arrays inherit a toString that joins their elements with commas, which is why an empty array becomes an empty string and an array of numbers becomes a comma separated list.

Coercion is not a bug in the language so much as a consequence of a permissive design, but it is the single biggest source of surprising JavaScript bugs. The practical rule is to convert explicitly at the boundaries of your program, where data arrives from a form field, a query string or an API response, and trust the types everywhere else.

Because coercion is where intent and behaviour drift apart. The language never guesses something ambiguous, but it does choose a conversion you may not have meant, and it does so silently, with no error and no warning. A value that arrives as the string "false" is truthy, so a naive guard lets it through. A price of "" passes an arithmetic check that expected a number and quietly becomes zero.

The cost is not that coercion is dangerous in isolation. It is that it makes code depend on the types involved, and those types are rarely stated. A reviewer reading value == "1" cannot tell whether the author knew about the conversion rules or got lucky. A reviewer reading Number(value) === 1 knows exactly what happens.

There is also a testing angle. Code that relies on coercion behaves differently depending on whether the input is a number or a string, so a unit test that passes a number can hide a production bug where the same field arrives as text from an API. Explicit conversion pushes that difference to a single place where it can be tested once.

The counterargument, which is fair, is that coercion in the right place is concise and idiomatic. Converting a query parameter with Number is one character shorter than validating it first, and using the double-bar operator to supply a fallback is cleaner than an if statement. The point is not to ban coercion. It is to make it deliberate: convert where data enters the system, and be explicit about the conversion you rely on.

The plus operator has two completely separate behaviours, and which one you get depends on the types of the operands. The specification first converts both operands to primitives. If either primitive is a string, the operation is string concatenation: the second operand is converted to a string and the two are joined. If neither is a string, the operation is numeric addition and both operands are converted to numbers.

console.log(1 + "2");        // "12" - string wins because one operand is a string
console.log("3" - 1);        // 2 - minus has no string mode
console.log(1 + null);       // 1 - null converts to 0
console.log(1 + undefined);  // NaN
console.log([] + []);        // "" - both arrays become empty strings
console.log(1n + 2n);        // 3n - two bigints add fine

try {
  console.log(1n + 2);
} catch (err) {
  console.log("mixed bigint:", err.name);   // "TypeError"
}

Two details are worth calling out. An empty array converts to an empty string, which is why an empty array concatenated with an object produces the string representation of the object rather than anything numeric. And a BigInt cannot be mixed with a Number in arithmetic, because converting between them is ambiguous for values beyond the safe integer range, so the engine throws a TypeError instead of guessing.

There is a related trap in the string concatenation path. The conversion to a string for a symbol throws a TypeError, so concatenating a symbol with a string is an error rather than a quiet text conversion. The engine refuses rather than producing something meaningless.

Finally, remember that the conversion order matters. Objects are converted to primitives first, using valueOf and then toString. An object with a custom valueOf that returns a number will be added numerically, while an object with only a toString will be concatenated as text. That is why an object that overrides toString behaves differently under plus and minus.