Why Use the Triple-Equals Operator in JavaScript?

“Determining whether two variables are equivalent is one of the most important operations in programming.” That’s according to Nicholas Zakas in his book JavaScript for Web Developers.

In other words, throughout your scripts you’ll probably have lines resembling this:

if (x == y) {
  // do something here

Or, if you’re conforming to best practices, this:

if (x === y) {
  // do something here

The difference between those two examples is that the second example uses the triple-equals operator, also called “strict equals” or “identically equal”.

JavaScript beginners who try to adhere to best practices may be using triple-equals and not double-equals, but might not fully understand what the difference is or why it’s important to stick to triple-equals.

What’s the Difference?

In a comparison using the double-equals operator, the result will return true if the two things being compared are equal. But there’s one important catch: If the comparison being made is between two different “types” of values, type coercion will occur.

Each JavaScript value belongs to a specific “type”. These types are: Numbers, strings, Booleans, functions, and objects. So if you try comparing (for example) a string with a number, the browser will try to convert the string into a number before doing the comparison. Similarly, if you compare true or false with a number, the true or false value will be converted to 1 or 0, respectively.

This can bring unpredictable results. Here are a few examples:

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

Although this can initially feel like a good thing (because the browser seems to be doing you a favour), it can cause problems. For example:

console.log(' \n\n\n' == 0); // true
console.log(' ' == 0); // true

In light of this, most JavaScript experts recommend always using the triple-equals operator, and never using double-equals.

The triple-equals operator, as you’ve probably figured out by now, never does type coercion. So whenever you use triple-equals, you’re doing an exact comparison of the actual values. You’re ensuring the values are ‘strictly equal’ or ‘identically equal’.

This means that, using triple-equals, all the examples from above will produce the correct results:

console.log(99 === "99"); // false
console.log(0 === false); // false
console.log(' \n\n\n' === 0); // false
console.log(' ' === 0); // false

What About Inequality?

When doing a not-equals-to expression, the same rules apply. Except this time, instead of triple-equals vs. double-equals, you’re using double-equals vs. single.

Here are the same examples from above, this time expressed with the != operator:

console.log(99 != "99"); // false
console.log(0 != false); // false
console.log(' \n\n\n' != 0); // false
console.log(' ' != 0); // false

Notice now that the desired result in each case should be “true”. Instead, they’re false — because of type coercion.

If we change to double-equals, we get the correct results:

console.log(99 !== "99"); // true
console.log(0 !== false); // true
console.log(' \n\n\n' !== 0); // true
console.log(' ' !== 0); // true


As mentioned, you’ve probably already used triple-equals pretty exclusively. While researching this article, I learned a few things about this concept myself.

I think the best summary comes from Zakas again, where, after recommending always using strict equals, he says: “This helps to maintain data type integrity throughout your code.”

Advertise Here

31 Responses

  1. Really Good Article. Thanks Louis. Me too using === instead of == but don’t know what it actually do.

  2. One thing you need to look out for: when you retrieve data from a form it’s always a string. So if you ask a visitor to type a number in a text field (or select a number from a select menu) and then compare that value to a number in your programming, the strict equals will be false. You’ll need to manually cast that form value as a number. For example:

    var x = document.formName.fieldName.value; // for example then number 9
    console.log(x===9); // returns false, because x is a string ‘9’
    x = parseInt(x,10); // turn x into an int
    console.log(x===9); // returns true, because x is now an integer

  3. It is worthy to note that the triple equality works the same way in PHP – I don’t know who copied the concept from who though!

  4. Tumbleweed:

    Yes, different comparison operators based on type … in a loosely-typed language. Makes perfect sense.

  5. Job:

    I strongly disagree with the triple equal diktat.
    Both have their uses, and if you know JavaScript, using both will never ever be a problem.
    Please JS developers, stop supporting JSLint stupid and narrow vision of JavaScript.

    • Marrowmaw:

      I agree with you on this however I think unless you are 100% sure you know what you are doing with the language you are much safer to be using strict comparisons.

    • RM:

      Totally agree with Job:

      and would rephrase: “, and if you THINK you know JavaScript, and find yourself wondering which one to use…” do yourself a favor, step back, understand first what Object Oriented paradigm is all about (in any programming language) so you know when two variables are equal and when two objects state are equal. Otherwise you are “wrapping” your misunderstanding of OOP with a “==” vs “===” decision.

  6. Very useful idea, | always use double-equals in Javascript before but after reading your article, I’ll consider using triple equals instead.

    Thank you

    • Ryan:

      Dont consider it, just do it. The number off oddities you can get by using “==” is quite large and they can be next to impossible for a human to foresee in advance.

  7. Hector:

    Fantastic article thanks mate :)

  8. Everything clear.
    Helpful post.
    Thanks Lazaris.

  9. Thanks for the article.

    I agree with the other commenter saying both have it’s uses. If they didn’t, there would only be one way of checking equality of variables, not two.

    I recommend “horses for courses”. Use the equality operator you need for the purpose you need to use it for. For example, there are times when you want 0 to equal to false. If you use 0===false, you will never get true. While 0==false is true. See what I mean?


    • The only thing I would say to that is that, from a strictly JS perspective, 0 is not equal to “false”, so there should be no reason for you to want it to be. When you say you want zero to equal false, you’re speaking from a data perspective.

      So in that case, I would personally prefer to set up my logic to get the numeric value, then once I have that, I would set the value to “false” if it was 0. Or else run the false logic branch if you find 0. I think this is much easier to maintain/understand. But that’s just my view, other devs may find your suggestion more useful, so I can certainly see where you’re coming from.

      • Stephen:

        If I really wanted what Mirza is doing I would convert the int to a boolean via not-not …
        var n = 8;
        var boolOfN = !!n;
        …converts int zero to boolean false, any non-zero int becomes boolean true.

  10. manjunath:

    very good explanation

  11. Shaswati:

    compact and knowledgeable

  12. Simon:

    (This article) === (very complete and useful).

    THANKS !

  13. Neal R:

    In IE9 it seems === seems enforced. At least we ran into a bug on code that worked well in IE7 but failed in IE9 just because we used == for comparison. The exception seen with == IE9 was this: “Can’t execute freed script”. The forums mislead us gallantly for that exception, btw :). A team member luckily was familiar with === and we tried it and our app started working like in IE7. Could not find any “official” doc saying it is enforced in IE9(More tidbits: we have win7 64 bit+IE9 running in IE7 compat mode and moved from win XP+IE7)

  14. sid:

    Thanks. Very helpful

  15. Niklas R.:

    I found this very helpful.
    This was exactly the type of explanation I was looking for.
    Job well done. :)

    Thanks a lot.

  16. Jon Skeet:

    Performance test in article http://conceptf1.blogspot.com/2014/01/javascript-triple-equals-vs-double-equals-operators.html is showing == in same type is faster. So any benefit to use it?

  17. If you look up the specifications, the behavior of the == operator is completely predictable. If you know how JavaScript’s loose-typed equality operator works, it can even be useful in some cases.

  18. Nice information about equality signs. I had a question since I don’t have very much experience in Javascript.

    Does javascript shows error when you do something wrong or it just stays quiet like HTML and CSS ?

  19. Sanjay Andole:

    Really a good one! Thanks for sharing the info.

  20. Great article!
    Definitely will reconsider my usage on the equality operators.
    Anyone interested can check this article http://rainsoft.io/the-legend-of-javascript-equality-operator/ for detailed explanation on how the equality works.

  21. ColeySauce:

    As others have said, both operators have their uses. A developer SHOULD understand the given language. By blindly using one or the other you fall into the same traps, granted triple equals is safer in that regard. However, I still think it’s a bad idea to tell someone, “stop thinking, just use triple equals”.

  22. Luis:

    I love the examples of unexpected results you get when you use double equals ==. Really scares you into using triple equals : ) Found a bunch of other scary examples on Stack Overflow: http://stackoverflow.com/a/38856418/984780

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address. No foul language, please. Thank you for cooperating.

Instructions for code snippets: Wrap inline code in <code> tags; wrap blocks of code in <pre> and <code> tags. When you want your HTML to display on the page in a code snippet inside of <code> tags, make sure you use &lt; and &gt; instead of < and >, otherwise your code will be eaten by pink unicorns.