The “triple equal”, “===”, is a strict comparison operator in JavaScript. It is used to compare two “things”, and returns either true or false.

The “double equal”, “==”, is an abstract comparison operator. It is also used to compare two “things”, and returns true or false.

They seem like the same thing! So, what’s the difference between “===” and “==” in JavaScript? And how do you remember which is which?

abstract comparison operator ==

When the “==” operator is used, the two operands – the things being compared – are converted to the same type1 by JavaScript before comparing.

This can be a source of some headaches! If you don’t realize that the two operands are actually being “messed with” before the “==” comparison occurs, you’re going to find this operator very confusing at some point!

You should mosey on over to the ECMAScript 5.1 specification, where the abstract equality comparison operator is explained2.

Go ahead, take a look! Notice that there are 10 logic steps that are considered in computing the result of this operator, and the first one has 6 different substeps. It starts to become clear why the “==” (double equal, abstract equality comparison operator) can lead to “gotcha” bugs in code!

I am not going to quote the ECMAScript spec here, nor am I going to explain it in detail. Instead, I will give a couple of examples:

var a = ("1" == 1); // a is the boolean true
var b = ("true" == true); // b is the boolean false

If you aren’t already familiar with this behavior, the fact that ("1" == 1) is true may come as a surprise. And given that ("1" == 1) is true, it seems non-intuitive that ("true" == true) is false! This is where bugs can creep into code. For example, suppose an object {"custom" : "true"} is sent from the server to your client in the web browser, and the code to check for this custom option reads:

if (obj["custom"] == true) {
    doSomething();
}

The bug report says that when some custom option is checked, the doSomething method is not called, but it should be. So you start by printing out the value of obj["custom"], and you see true in the JavaScript console… how is that possible? Pain ensues!

strict comparison operator ===

In contrast, let’s take a look at what the spec says about the strict equals operator3. There are 6 logic steps for this operator, and no substeps. It’s still not 100% straightforward (what’s that stuff about <a href="https://www.ecma-international.org/ecma-262/5.1/#sec-8.7.1">GetValue</a>)? However, it’s definitely a bit less confusing.

Let’s look at how the triple equal plays out in the above code snippets:

var a = ("1" === 1); // a is the boolean false
var b = ("true" === true); // b is the boolean false

At least to me, these results seem much more obvious than the ones using “==“.

a mnemonic for remembering the difference

It’s difficult to get a truly intuitive feeling for what values will be returned by these two operators. However, I have a mnemonic that I use to help me. The three equal signs in the strict equals operator make me think “really, really, really!”. As in, the two operands are really, really, really equal. In particular, there’s no type conversion before the comparison. So if one operand is a string and the other is a number, you will always get false. On the other hand, the == operator will return true even if the two operands are “sort of” equal. That’s the way I think of it.

I almost never use the double equal, abstract comparison operator. In fact, I cannot think of the last time I used it! It strikes me as a source of hard-to-uncover bugs. And it’s hard to remember all the rules when using ==. However, I do know that there’s a difference between the two different operators. I think that’s the most important thing: experienced JavaScript developers should be aware that there’s a difference, and have a pretty good idea of what that difference is, even if they can’t quote the spec on it. If you’re a person who has expertise in several different languages, it gets hard to keep track of the finer details of a language. But you can still be very productive as long as you keep in mind some fundamental principles. In this case, make sure you notice when == is used and when === is used, be careful about which way you use them, and if you’re looking for a bug, keep in mind that the comparison operator is a place to check for the problem.