JavaScript Best Practices

Why Should We Be Careful of JavaScript Type Coercion?

Spread the love

Type coercion can be a convenience feature or a trap in JavaScript. Learn why here.

Since JavaScript is a dynamically typed programming language, data types of objects and variables can change on the fly. This a problem that we’ll face often as we write more and more JavaScript programs. There’re a few things to be aware of with type coercion, which is the conversion of data types on the fly during program execution.

Type Coercion

As we mentioned, type coercion is the changing of data types on the fly. It happens when data doesn’t match the expected type. For example, if we want to manipulate numbers and string with numbers, we can write:


and we get back 10.

This may seem like a great convenience feature, but it also sets up lots of traps we can fall into. For example, if we have:

1 +'1'

We get:


which isn’t what we want.

JavaScript has type coercion also because the language originally didn’t have exceptions, so it returns some values for doing invalid operations. Examples of these values include Infinity or NaN , which are return when we divide a number by 0 or try to convert something that doesn’t have numerical content to a number respectively.

NaN stands for not a number.

For example, we get that:


if NaN since it tries to convert the string 'abc' into a number unsuccessfully, so instead of throwing an exception, it returns NaN .

More modern parts of JavaScript do throw exceptions. For example, if we try to run:

Then we get ‘Uncaught TypeError: Cannot read property ‘foo’ of undefined.’

Another example would be mixing number and BigInt operands in arithmetic operations:

6 / 1n

Then we get ‘Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions.’

How Does JavaScript Type Coercion Work?

Type coercion is done within the JavaScript interpreter. There’re functions built into almost all browsers to do this. We have the Boolean for converting values to boolean, Number to convert values to numbers and so on.

Avoiding Type Coercion Traps

To avoid falling into traps caused by type coercion, we should check the type of the object and convert it to the same type before operating on them.


For example, we use the Number function to convert anything into numbers. For example, we can use it as follows:

Number(1) // 1
Number('a') // NaN
Number('1') // 1
Number(false) // 0

The Number function takes an object of any type as the argument and tries to convert it to a number. If it can’t, then it’ll return NaN .

We can also use the + operator in front of a variable or a value to try to convert it to a number. For example, we can write:


Then we get NaN . If we write:


Then we get 1.


To convert objects to a string, we can use the String function. It also takes an object and tries to convert it into a string.

If we pass in an object, we get back:

"[object Object]"

For example, writing:


will get us that.

Primitive values will get us the string with the same content as the primitive value. For example, if we write:


We get “123” .

All Objects other than ones we specifically remove the prototype from will have a toString method.

For example, if we write:


We get “[object Object]” back.

If we write:


Then we get back “2” . Note that we have 2 dots since the first dot designates the number as a number object and then the second dot lets us call methods on the number object.

Other weird conversions involving strings that can’t be explained with reason include:

`"number" + 1 + 3        // 'number13'
1 + 3 + "number"        // '4number'
"foo" + + "bar"         // 'fooNaN'
`{}+[]+{} // '[object Object][object Object]'
`!+[]+[]+![]             // '`truefalse'
`[] + null + 2           // 'null2'`


Objects also have the Symbol.toPrimitve method that converts an object to a corresponding primitive value. It’s called when the + unary operator is used or converting an object to a primitive string. For example, we can write our own Symbol.toPrimitive method to convert various values to a primitive value:

let obj = {
    [Symbol.toPrimitive](hint) {
        if (hint == 'number') {
            return 10;
        if (hint == 'string') {
            return 'hello';
        if (hint == 'true') {
            return true;
        if (hint == 'false') {
            return false;
        return true;

Then we get:


from the console.log statements at the bottom of our code.

Avoid Loose Equality

Loose equality comparison is done by the == operator. It compares the content of its 2 operands for equality by converting to the same type before comparison. For example,

1 == '1'

will evaluate to true .

A more confusing example would be something like:

1 == true

Since true is truthy, it’ll be converted to a number first before comparing them. So true will be converted to 1 before comparing, which makes the expression true.

To avoid a confusing situation like this, we use the === comparison operator instead.


1 === '1'


1 === true

will both be false , which makes more sense since their types are different. No type coercion will be done by the === operator on the operands. Both the type and content are compared.

Comparison issues we mentioned above apply to primitive values. Object are compared by their reference so if the operands have a different reference then it evaluates to false no matter which operator we use.

With these functions, we converted our variables and values to the type we explicitly have written. It makes the code much more clear and we don’t have to worry about the JavaScript interpreter trying to convert things into a type that we don’t want. Also, we should use the === operator instead of the == operator to compare primitive values.

By John Au-Yeung

Web developer specializing in React, Vue, and front end development.

Leave a Reply

Your email address will not be published. Required fields are marked *