Which equals operator (== vs ===) should be used in JavaScript comparisons?
Solution 1
The strict equality operator (===) behaves identically to the abstract equality operator (==) except no type conversion is done, and the types must be the same to be considered equal.
Reference: JavaScript Tutorial: Comparison Operators
The == operator will compare for equality after doing any necessary type conversions. The === operator will not do the conversion, so if two values are not the same type === will simply return false. Both are equally quick.
To quote Douglas Crockford's excellent JavaScript: The Good Parts,
JavaScript has two sets of equality operators:
===and!==, and their evil twins==and!=. The good ones work the way you would expect. If the two operands are of the same type and have the same value, then===producestrueand!==producesfalse. The evil twins do the right thing when the operands are of the same type, but if they are of different types, they attempt to coerce the values. The rules by which they do that are complicated and unmemorable. These are some of the interesting cases:
'' == '0' // false 0 == '' // true 0 == '0' // true
false == 'false' // false false == '0' // true
false == undefined // false false == null // false null == undefined // true
' \t\r\n ' == 0 // true
The lack of transitivity is alarming. My advice is to never use the evil twins. Instead, always use
===and!==. All of the comparisons just shown producefalsewith the===operator.
Update
A good point was brought up by @Casebash in the comments and in @Phillipe Laybaert's answer concerning objects. For objects, == and === act consistently with one another (except in a special case).
var a = [1,2,3]; var b = [1,2,3];var c = { x: 1, y: 2 }; var d = { x: 1, y: 2 };
var e = “text”; var f = “te” + “xt”;
a == b // false a === b // false
c == d // false c === d // false
e == f // true e === f // true
The special case is when you compare a primitive with an object that evaluates to the same primitive, due to its toString or valueOf method. For example, consider the comparison of a string primitive with a string object created using the String constructor.
"abc" == new String("abc") // true
"abc" === new String("abc") // false
Here the == operator is checking the values of the two objects and returning true, but the === is seeing that they're not the same type and returning false. Which one is correct? That really depends on what you're trying to compare. My advice is to bypass the question entirely and just don't use the String constructor to create string objects from string literals.
Reference
https://262.ecma-international.org/5.1/#sec-11.9.3
Solution 2
Using the == operator (Equality)
true == 1; //true, because 'true' is converted to 1 and then compared
"2" == 2; //true, because "2" is converted to 2 and then compared
Using the === operator (Identity)
true === 1; //false
"2" === 2; //false
This is because the equality operator == does type coercion, meaning that the interpreter implicitly tries to convert the values before comparing.
On the other hand, the identity operator === does not do type coercion, and thus does not convert the values when comparing.
Solution 3
Here's an interesting visualisation of the equality comparison between == and ===.
Source: https://github.com/dorey/JavaScript-Equality-Table (demo, unified demo)
var1 === var2
When using === for JavaScript equality testing, everything is as is.
Nothing gets converted before being evaluated.
var1 == var2
When using == for JavaScript equality testing, some funky conversions take place.
Summary of equality in Javascript
Conclusion:
Always use ===, unless you fully understand the funky conversions that take place with ==.
Solution 4
In the answers here, I didn't read anything about what equal means. Some will say that === means equal and of the same type, but that's not really true. It actually means that both operands reference the same object, or in case of value types, have the same value.
So, let's take the following code:
var a = [1,2,3]; var b = [1,2,3]; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true
The same here:
var a = { x: 1, y: 2 }; var b = { x: 1, y: 2 }; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true
Or even:
var a = { }; var b = { }; var c = a;
var ab_eq = (a === b); // false (even though a and b are the same type) var ac_eq = (a === c); // true
This behavior is not always obvious. There's more to the story than being equal and being of the same type.
The rule is:
For value types (numbers):
a === b returns true if a and b have the same value and are of the same type
For reference types:
a === b returns true if a and b reference the exact same object
For strings:
a === b returns true if a and b are both strings and contain the exact same characters
Strings: the special case...
Strings are not value types, but in Javascript they behave like value types, so they will be "equal" when the characters in the string are the same and when they are of the same length (as explained in the third rule)
Now it becomes interesting:
var a = "12" + "3"; var b = "123";
alert(a === b); // returns true, because strings behave like value types
But how about this?:
var a = new String("123"); var b = "123";
alert(a === b); // returns false !! (but they are equal and of the same type)
I thought strings behave like value types? Well, it depends who you ask... In this case a and b are not the same type. a is of type Object, while b is of type string. Just remember that creating a string object using the String constructor creates something of type Object that behaves as a string most of the time.
Solution 5
Let me add this counsel:
If in doubt, read the specification!
ECMA-262 is the specification for a scripting language of which JavaScript is a dialect. Of course in practice it matters more how the most important browsers behave than an esoteric definition of how something is supposed to be handled. But it is helpful to understand why new String("a") !== "a".
Please let me explain how to read the specification to clarify this question. I see that in this very old topic nobody had an answer for the very strange effect. So, if you can read a specification, this will help you in your profession tremendously. It is an acquired skill. So, let's continue.
Searching the PDF file for === brings me to page 56 of the specification: 11.9.4. The Strict Equals Operator ( === ), and after wading through the specificationalese I find:
11.9.6 The Strict Equality Comparison Algorithm
The comparison x === y, where x and y are values, produces true or false. Such a comparison is performed as follows:
1. If Type(x) is different from Type(y), return false.
2. If Type(x) is Undefined, return true.
3. If Type(x) is Null, return true.
4. If Type(x) is not Number, go to step 11.
5. If x is NaN, return false.
6. If y is NaN, return false.
7. If x is the same number value as y, return true.
8. If x is +0 and y is −0, return true.
9. If x is −0 and y is +0, return true.
10. Return false.
11. If Type(x) is String, then return true if x and y are exactly the same sequence of characters (same length and same characters in corresponding positions); otherwise, return false.
12. If Type(x) is Boolean, return true if x and y are both true or both false; otherwise, return false.
13. Return true if x and y refer to the same object or if they refer to objects joined to each other (see 13.1.2). Otherwise, return false.
Interesting is step 11. Yes, strings are treated as value types. But this does not explain why new String("a") !== "a". Do we have a browser not conforming to ECMA-262?
Not so fast!
Let's check the types of the operands. Try it out for yourself by wrapping them in typeof(). I find that new String("a") is an object, and step 1 is used: return false if the types are different.
If you wonder why new String("a") does not return a string, how about some exercise reading a specification? Have fun!
Aidiakapi wrote this in a comment below:
From the specification
11.2.2 The new Operator:
If Type(constructor) is not Object, throw a TypeError exception.
With other words, if String wouldn't be of type Object it couldn't be used with the new operator.
new always returns an Object, even for String constructors, too. And alas! The value semantics for strings (see step 11) is lost.
And this finally means: new String("a") !== "a".