By bcasp

2008-12-11 14:19:49 8 Comments

I'm using JSLint to go through JavaScript, and it's returning many suggestions to replace == (two equals signs) with === (three equals signs) when doing things like comparing idSele_UNVEHtype.value.length == 0 inside of an if statement.

Is there a performance benefit to replacing == with ===?

Any performance improvement would be welcomed as many comparison operators exist.

If no type conversion takes place, would there be a performance gain over ==?


@vsync 2010-05-12 12:58:12

It checks if same sides are equal in type as well as value.


'1' === 1 // will return "false" because `string` is not a `number`

Common example:

0 == ''  // will be "true", but it's very common to want this check to be "false"

Another common example:

null == undefined // returns "true", but in most cases a distinction is necessary

@Homer 2012-01-06 19:34:54

also, 'string' !== 'number'

@SNag 2014-05-05 05:21:25

An interesting pictorial representation of the equality comparison between == and ===.


var1 === var2

When using === for JavaScript equality testing, everything is as is. Nothing gets converted before being evaluated.

Equality evaluation of === in JS

var1 == var2

When using == for JavaScript equality testing, some funky conversions take place.

Equality evaluation of == in JS

Moral of the story:

Use === unless you fully understand the conversions that take place with ==.

@mfeineis 2015-05-08 11:11:03

I would go even further with the moral: always use ===/!=== but understand the conversion for being able to cope with other people's code

@Zo72 2015-06-14 20:25:11

the running implementation of this table is here:

@katalin_2003 2016-06-23 14:04:34

@mfeineis you mean === or !== instead of == or != . Don't want to confuse new coders ;)

@vsync 2017-02-12 08:47:06

from my experience using three equals can cause problems and should be avoided unless fully understood. two equals produces much better results because 99% of the time I really don't want types to be equal.

@SNag 2017-04-24 05:19:24

@vsync: If you really don't want types to be equal, you should use three equals!

@Andy 2018-09-12 15:40:08

The one exception: you can safely use x == null to check if x is null or undefined.

@John Coleman 2019-02-05 19:12:31

Cool pictures. The bottom one reminds me of Conway's game of life.

@user648026 2019-03-06 14:18:38

pictures lack the comparison of upper and lower case

@SNag 2019-03-06 20:33:25

@user648026: The question is about equality comparison with == vs ===. Upper and lower cases are unequal anyway, and will return false with both == and === operators. Also, keywords true, false, undefined, null, Infinity exist in JS in only one case, and cannot be used in upper or mixed cases.

@Sharad Kale 2017-04-28 04:55:20

== operator just compares the values not datatype

=== operator compare the values with comparison of its datatype


1 == "1" //true

1 === "1" //false

"===" operator used in languages which performs automatic type cast eg. PHP, Javascript. "===" operator helps to prevent unexpected comparison caused by automatic typecast.

@mrmr68 2017-05-25 12:04:43

for '==' dataType is not important

@Luis Perez 2016-08-09 16:50:12

Why == is so unpredictable?

What do you get when you compare an empty string "" with the number zero 0?


Yep, that's right according to == an empty string and the number zero are the same time.

And it doesn't end there, here's another one:

'0' == false // true

Things get really weird with arrays.

[1] == true // true
[] == false // true
[[]] == false // true
[0] == false // true

Then weirder with strings

[1,2,3] == '1,2,3' // true - REALLY?!
'\r\n\t' == 0 // true - Come on!

It get's worse:

When is equal not equal?

let A = ''  // empty string
let B = 0   // zero
let C = '0' // zero string

A == B // true - ok... 
B == C // true - so far so good...
A == C // **FALSE** - Plot twist!

Let me say that again:

(A == B) && (B == C) // true
(A == C) // **FALSE**

And this is just the crazy stuff you get with primitives.

It's a whole new level of crazy when you use == with objects.

At this point your probably wondering...

Why does this happen?

Well it's because unlike "triple equals" (===) which just checks if two values are the same.

== does a whole bunch of other stuff.

It has special handling for functions, special handling for nulls, undefined, strings, you name it.

It get's pretty wacky.

In fact, if you tried to write a function that does what == does it would look something like this:

function isEqual(x, y) { // if `==` were a function
    if(typeof y === typeof x) return y === x;
    // treat null and undefined the same
    var xIsNothing = (y === undefined) || (y === null);
    var yIsNothing = (x === undefined) || (x === null);

    if(xIsNothing || yIsNothing) return (xIsNothing && yIsNothing);

    if(typeof y === "function" || typeof x === "function") {
        // if either value is a string 
        // convert the function into a string and compare
        if(typeof x === "string") {
            return x === y.toString();
        } else if(typeof y === "string") {
            return x.toString() === y;
        return false;

    if(typeof x === "object") x = toPrimitive(x);
    if(typeof y === "object") y = toPrimitive(y);
    if(typeof y === typeof x) return y === x;

    // convert x and y into numbers if they are not already use the "+" trick
    if(typeof x !== "number") x = +x;
    if(typeof y !== "number") y = +y;
    // actually the real `==` is even more complicated than this, especially in ES6
    return x === y;

function toPrimitive(obj) {
    var value = obj.valueOf();
    if(obj !== value) return value;
    return obj.toString();

So what does this mean?

It means == is complicated.

Because it's complicated it's hard to know what's going to happen when you use it.

Which means you could end up with bugs.

So the moral of the story is...

Make your life less complicated.

Use === instead of ==.

The End.

@Oriol 2016-09-07 22:16:44

Your looseEqual is wrong. Function == Function.toString() is true, but looseEqual(Function, Function.toString()) is false. Not sure why you filter out functions at the beginning.

@Luis Perez 2016-09-08 22:43:51

@Oriol you were right, I updated the code to account for that, FYI based on my tests it wasn't enough to remove the filter for "functions", instead "functions" had to be handled differently altogether.

@Oriol 2016-09-08 23:25:01

Be aware the spec doesn't treat functions differently, they are just objects. The problem seems that you rely on typeof x === "object" to check if it's an object, but `typeof only works for non-null primitives. You might be interested in my list of proper ways to check if a value is an object

@Luis Perez 2016-09-10 16:22:22

I tried treating functions and objects the same but found he results were incorrect. For example if functions were treated like objects then comparing a function with an object that implements valueOf() or toString() function that matches the function would pass but in reality it doesn't. Example: (function blah() { console.log("test"); }) != {valueOf:function(){return "function blah() { console.log(\"test\"); }";}} - check out this JS Fiddle which runs all the tests: (there 1,225 test permutations)

@Oriol 2016-09-10 21:02:56

Interesting. But note your code fails with {toString:function(){return null;}}, and some ES6 thingies. See

@Luis Perez 2016-09-11 13:20:38

You're right, great observations, this emphasizes the main point that == does a lot of things making it very difficult to anticipate the results while === is much more straightforward and predictable which is one of the main reasons === is the recommended choice. (I'll add a note to the answer mentioning your point)

@Alireza 2017-05-07 12:10:32

Use === if you want to compare couple of things in JavaScript, it's called strict equality, it means this will return true if only both type and value are the same, so there wouldn't be any unwanted type correction for you, if you using ==, you basically don't care about the type and in many cases you could face issues with loose equality comparison.

Strict equality using ===

Strict equality compares two values for equality. Neither value is implicitly converted to some other value before being compared. If the values have different types, the values are considered unequal. Otherwise, if the values have the same type and are not numbers, they're considered equal if they have the same value. Finally, if both values are numbers, they're considered equal if they're both not NaN and are the same value, or if one is +0 and one is -0.

var num = 0;
var obj = new String('0');
var str = '0';

console.log(num === num); // true
console.log(obj === obj); // true
console.log(str === str); // true

console.log(num === obj); // false
console.log(num === str); // false
console.log(obj === str); // false
console.log(null === undefined); // false
console.log(obj === null); // false
console.log(obj === undefined); // false

Loose equality using ==

Loose equality compares two values for equality, after converting both values to a common type. After conversions (one or both sides may undergo conversions), the final equality comparison is performed exactly as === performs it. Loose equality is symmetric: A == B always has identical semantics to B == A for any values of A and B (except for the order of applied conversions).

var num = 0;
var obj = new String('0');
var str = '0';

console.log(num == num); // true
console.log(obj == obj); // true
console.log(str == str); // true

console.log(num == obj); // true
console.log(num == str); // true
console.log(obj == str); // true
console.log(null == undefined); // true

// both false, except in rare cases
console.log(obj == null);
console.log(obj == undefined);

@SeanRamzan 2017-05-18 15:45:51

I do believe it's subjective in regards to what you should/should not do, and misleading to tell someone to always use a particular action. While I agree than in most cases we care to use '===' vs. '==', there may be a particular case where you want the type conversion done. - Cannot think of an exact use case off the top of my head, but perhaps the design is to have a loose check. Regardless, if something is included in the language, it's there for a reason. We should try to avoid blanketing statements of 'always do x' in my opinion.

@Alireza 2017-05-18 17:41:35

I knid of agree with you, if you read my whole answer, you see I explain in more details later on, to be honest there are not many cases we use and need loose comparation in Javascript... I can say less than 5 percent, even much less, but I use ´always´ for those people with no js background, which think == check strict comparation in JavaScript, they learn to be catious and not using it at first place, but as they get more expert, they know in which rare cases they might use it. That's why I write my answer like that.

@Bekim Bacaj 2017-11-26 19:38:41

The dilemma of "Should I use == or === in JavaScript comparison" is equal or analogous to a question of: "Should I use a 'spoon' or a 'fork' for eating.

The only reasonable answer to this question is that

  1. You should use Dynamic Type comparison e.g.:== for loose Type comparisons.
  2. You should use Static Type comparison e.g.:=== for strong Type comparisons.

That's because they are not the same. They don't have the same purpose and are not meant to be used for the same purpose.

Of course both 'forks' and 'spoons' are meant for 'eating', but you will chose to use them accordingly to what you've been served to eat.

Meaning: you'll resolve to using a 'spoon' i.e.: == for having a 'soup', and / or the 'fork' i.e.: === for picking.

Asking if it is better to use a "fork" or a "spoon" for "eating" - is equall to asking if it is better to use a static [===] versus dynamic [==] eq., op. in JS. Both questions are equally wrong and reflect a very narrow or shallow understanding of the subject in question.

@Bekim Bacaj 2017-12-05 22:08:53

p.s.: JSLint (or Crockford ) is wrong for insisting, or asking you to use strict type comparison when dealing with values of the same type. The JavaScript length property is always of type: number. And therefore no room or a possibility for fake positives. Furthermore, there is no need for dSele_UNVEHtype.value.length === 0 when you can use a direct shorthand of !dSele_UNVEHtype.value.length instead.

@Jasper 2017-12-22 13:49:14

Why would you answer a 9 year old question, which already has 49 answers, which also has an accepted answer with over 5k upvotes, with an answer that contains a weird analogy and doesn't explain anything what has not been said already?

@Bekim Bacaj 2017-12-26 13:13:19

Because there are to many professional misuses of JavaScript no matter how old they are. And you for instance was unable to understand what's it all about and capture the essence of the difference Live Script makes in contrast to static type languages. And why do we need its intelligent dynamics. JavaScript was made for creative intelligent people not for dorks.

@Jasper 2017-12-27 08:22:29

Yes I agree there are many misuses of JavaScript. However I still think your analogy is weird as in it can be easily misunderstood, and it does not cover the core basics in a meaningful way.

@Bekim Bacaj 2017-12-28 17:14:36

The analogy given is the best ever illustration of their difference and the quality of use case. This is the best short essay to learn the absolute essence even if you are a complete newcomer to JS. And is equally good, probably better than my late answer on how to empty a JS array [for real].

@Amit 2015-03-20 05:05:48


== means comparison between operands with type conversion


=== means comparison between operands without type conversion

Type conversion in javaScript means javaScript automatically convert any other data types to string data types.

For example:

123=='123'   //will return true, because JS convert integer 123 to string '123'
             //as we used '==' operator 

123==='123' //will return false, because JS do not convert integer 123 to string 
            //'123' as we used '===' operator 

@garakchy 2014-08-08 16:52:43

JavaScript has both strict and type–converting comparisons. A strict comparison (e.g., ===) is only true if the operands are of the same type. The more commonly used abstract comparison (e.g. ==) converts the operands to the same Type before making the comparison.

  • The equality (==) operator converts the operands if they are not of the same type, then applies strict comparison. If either operand is a number or a boolean, the operands are converted to numbers if possible; else if either operand is a string, the string operand is converted to a number if possible. If both operands are objects, then JavaScript compares internal references which are equal when operands refer to the same object in memory.


    x == y


    3 == 3     // true
    "3" == 3   // true
    3 == '3'   // true
  • The identity/strict equality(===) operator returns true if the operands are strictly equal (see above) with no type conversion.


    x === y


    3 === 3 // true

For reference: Comparison operators (Mozilla Developer Network)

@ashes 2012-06-05 07:53:04

JSLint sometimes gives you unrealistic reasons to modify stuff. === has exactly the same performance as == if the types are already the same.

It is faster only when the types are not the same, in which case it does not try to convert types but directly returns a false.

So, IMHO, JSLint maybe used to write new code, but useless over-optimizing should be avoided at all costs.

Meaning, there is no reason to change == to === in a check like if (a == 'test') when you know it for a fact that a can only be a String.

Modifying a lot of code that way wastes developers' and reviewers' time and achieves nothing.

@Niraj CHoubey 2010-05-12 13:03:37

=== operator checks the values as well as the types of the variables for equality.

== operator just checks the value of the variables for equality.

@Neil Meyer 2017-11-16 10:56:45

Strict equality is for the most part better

The fact that Javascript is a loosely typed language needs to be in the front of your mind constantly as you work with it. As long as the data structure is the same there really is no reason as to not use strict equality, with regular equality you often have an implicit conversion of values that happens automatically, this can have far-reaching effects on your code. It is very easy to have problems with this conversion seeing as they happen automatically.

With strict equality there is no automatic implicit conversion as the values must already be of the correct data structure.

@Narendra Kalekar 2017-08-01 09:13:53

The reason it suggest to replace == with === is that the === operator is more reliable than ==. In our context reliable means === also goes for type checking. Considering the best programming practices we should always choose more reliable feature over less reliable one. Again whenever we think about exactly equal to operator most of the time, we are by default consider the type should be same. As === provides the same, we should go for it.

@Pop Catalin 2010-05-12 12:59:09

It means equality without type coercion type coercion means JavaScript do not automatically convert any other data types to string data types

0==false   // true,although they are different types

0===false  // false,as they are different types

2=='2'    //true,different types,one is string and another is integer but 
            javaScript convert 2 to string by using == operator 

2==='2'  //false because by using === operator ,javaScript do not convert 
           integer to string 

2===2   //true because both have same value and same types 

@RïshïKêsh Kümar 2017-06-25 10:21:33

Different's Between = , = = , = = =

  • = operator Used to just assign the value.
  • = = operator Used to just compares the values not datatype
  • = = = operator Used to Compare the values as well as datatype.

@Akintunde-Rotimi 2017-04-24 12:11:33

First, some terminology about Javascript string equals: Double equals is officially known as the abstract equality comparison operator while triple equals is termed the strict equality comparison operator. The difference between them can be summed up as follows: Abstract equality will attempt to resolve the data types via type coercion before making a comparison. Strict equality will return false if the types are different. Consider the following example:

console.log(3 == "3"); // true
console.log(3 === "3"); // false.
console.log(3 == "3"); // true
console.log(3 === "3"); // false.

Using two equal signs returns true because the string “3” is converted to the number 3 before the comparison is made. Three equal signs sees that the types are different and returns false. Here’s another:

console.log(true == '1'); // true
console.log(true === '1'); // false
console.log(true == '1'); // true
console.log(true === '1'); // false

Again, the abstract equality comparison performs a type conversion. In this case both the boolean true and the string ‘1’ are converted to the number 1 and the result is true. Strict equality returns false.

If you understand that you are well on your way to distinguishing between == and ===. However, there’s some scenarios where the behavior of these operators is non intuitive. Let’s take a look at some more examples:

console.log(undefined == null); // true
console.log(undefined === null); // false. Undefined and null are distinct types and are not interchangeable.
console.log(undefined == null); // true     
console.log(undefined === null); // false. Undefined and null are distinct types and are not interchangeable.

console.log(true == 'true'); // false. A string will not be converted to a boolean and vice versa.
console.log(true === 'true'); // false
console.log(true == 'true'); // false. A string will not be converted to a boolean and vice versa.
console.log(true === 'true'); // false

The example below is interesting because it illustrates that string literals are different from string objects.

console.log("This is a string." == new String("This is a string.")); // true
console.log("This is a string." === new String("This is a string.")); // false
console.log("This is a string." == new String("This is a string.")); // true
console.log("This is a string." === new String("This is a string.")); // false

@vikram mohod 2017-01-03 10:09:42

1 == "1"    =>    true(define)
true === "true"    => false(undefined compare the type of variable)
Case 1
if(true === "true"){
  echo 'true'
 echo 'false undefined'
Ans :- false undefined because case 1 is check data type also with ===  
Case 2
if(1 == "1"){
  echo 'true define'
 echo 'false undefined'
Ans :- true define undefined because case 2 is not check data type with ==

@Fayaz 2017-01-16 12:28:13

Please explain your answer.

@Andreas Grech 2008-12-11 14:33:58

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.

@Philippe Leybaert 2009-06-05 20:00:24

@Software Monkey: not for value types (number, boolean, ...)

@Adrien Be 2014-07-23 12:02:16

type coercion vs type casting vs type convertion:…

@blaze 2015-01-06 03:17:19

Since nobody has mentioned the Javascript Equality Table, here it is:

@Shadi Namrouti 2016-11-22 10:05:58

In the first statement, are you sure that 'true' is converted to 1 and not 1 converted to true?

@Ray Toal 2018-02-07 08:03:44

Where do the terms "equality" and "identity" come from? The standard does not use those terms. It calls == "abstract equality" and it calls === "strict equality". Granted calling == any kind of "equality" is IMHO awful, since it is not transitive, but why quibble? I take more issue with "identity" though; I think that term is pretty misleading, though it "works." But seriously, who coined the term "identity"? I search the standard and could not find it.

@Bill the Lizard 2008-12-11 14:25:06

The identity (===) operator behaves identically to the 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 === produces true and !== produces false. 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 produce false with the === operator.


A good point was brought up by @Casebash in the comments and in @Phillipe Laybaert's answer concerning reference types. For reference types == 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 literal with an object that evaluates to the same literal, due to its toString or valueOf method. For example, consider the comparison of a string literal with a string object created by 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.


@ibz 2008-12-26 09:40:47

So assuming types are the same - is === actually faster? :)

@Bill the Lizard 2008-12-31 03:02:11

=== is not quicker if the types are the same. If types are not the same, === will be quicker because it won't try to do the conversion.

@Ray Hidayat 2009-02-01 21:14:58

But presumably it's never slower, right?

@Bill the Lizard 2009-02-02 04:17:55

=== will never be slower than ==. They both do type checking, so === doesn't do anything extra compared to ==, but the type check may allow === to exit sooner when types are not the same.

@Marco Demaio 2010-03-31 09:22:07

Replacing all ==/!= with ===/!== increases the size of the js file, it will take then more time to load. :)

@Casebash 2010-06-14 04:59:58

Should we really never use ==? Have you seen this response

@Bill the Lizard 2010-06-14 14:37:53

@Casebash: Yes, I've seen that. That answer doesn't really compare == and ===, which is what this question is about. For every test I've run using reference types == and === act consistently with one another except for one. That's the case pointed out in the comments where new String("abc") == "abc" returns true, but new String("abc") === "abc" returns false. My advice in light of this is to not use the String constructor, and always use ===.

@Evan Plaice 2010-06-25 07:30:52

@Bill The update is technically the 'right' answer. === is reference equality, == is value equality.

@Thomas Eding 2011-03-30 05:15:23

The reason new String("xxx") == "xxx" is because of the toString method. Similar things happen with valueOf. new Number(7) == 7, ({ valueOf : function () { return 8; } }) == 8 both eval to true and eval to false if == is changed to ===

@Thomas Eding 2011-03-30 05:18:21

new Number() == "0". Also in Firefox: (function(){}) == "function () {\n}"

@Johan 2011-12-09 16:24:46

"...the rules by which they do that are complicated and unmemorable..." Now such statements make you feel so safe when programming...

@PointedEars 2012-05-29 21:25:50

@EvanPlaice Nonsense. References to objects (and there are no other references) are values in these languages. In fact, there is no such thing as a reference type where the implementation is concerned; that is purely a specification mechanism.

@Eric 2012-09-30 19:06:32

A good question of the performance differences:…

@Yawar 2012-11-08 04:06:58

Sometimes JavaScript's type system makes me want to run away screaming.

@Laurent S. 2013-04-02 15:34:03

Still I don't understand why {} === {} returns false. I totally understand these are not the same object in memory, but still this is of the same type and the same value...

@1nfiniti 2013-05-05 15:10:05

@Bartdude They aren't considered to be of the same value because they are not the same object. Objects could be so complicated, that it would be ridiculous to try and compare them for likeness of value. Consider 2 objects with many nested properties, some of which may be functions. How would you go about comparing the value of that?

@Amitābha 2013-08-22 15:03:19

=== type and value are same, == is evil, if they aren't same type,they will convert type before compare .so just use === ,and no need use ==

@Allan Chua 2013-10-21 15:14:37

@MarcoDemaio pal using !==/=== will save you more space than you think because if you don't use them you will be writing code like if(val != 0 && val != '') instead of if(val !=== 0).

@Brian M. Hunt 2014-02-21 13:41:11

It could be worth noting that "abc" === String("abc") is true. Oddly enough.

@lampwins 2014-04-05 02:45:42

Can you address why [1,2,3] < [1,2,4] //true and [1,2,3] <= [1,2,4] //true? I have never understood this.

@jinglesthula 2014-05-29 20:31:13

From Crockford: "The lack of transitivity is alarming." If you develop software and don't find lack of transitivity in a comparison operator alarming, or if speed comparison between == and === or file size/load time take precedence in your mind over transitive determinism of a comparison operator's behavior, you may need to go back and start over.

@Adrien Be 2014-07-23 12:05:09

note the difference between type "coercion" vs type "casting" vs type "convertion", javascript in this case uses type coercion:…

@Nipuna 2014-07-26 09:26:24

Found this good article from MDN. Should be useful‌​ss

@dylnmc 2015-10-16 14:22:35

@LaurentS. I know - you would think that var a = new Object(), b = new Object; a == b would work. But alas no as they have different attributes (even though they have the same values (in this case there are no attributes), but you catch my drift.

@Blauhirn 2015-12-30 19:08:14

"always use === and !==." - I like this approach, but what do I do if I want "1" and 1 to be considered equal somewhere in my code, for example after a JSON import? parseInt?

@Pauan 2016-01-17 23:01:16

@Blauhirn Yes, the recommended way is to do manual type coercions (either converting 1 to a string, or converting "1" to a number). The parseInt and parseFloat functions work fine, but you can also use +"1" or Number("1") to convert "1" to a number. Note: there is a big difference between Number("1") and new Number("1")! The first does type coercion, the second creates a new Number object.

@Константин Ван 2016-02-11 16:32:30

@T.J. Crowder 2016-02-22 16:57:44

"For reference types == and === act consistently with one another (except in a special case)." The "special case" isn't a special case. String literals create string primitives, not string objects, so when you're comparing "abc" with new String("abc"), you're doing a cross-type comparison (value type string primative with reference type object).

@Devsman 2016-05-04 14:01:06

== and != aren't evil. Their existence and functionality is perfectly inline with the overall concept and application of javascript to begin with. There is no guarantee that any browser, user or server will do anything the way you expect it to--especially considering browsers that don't exist yet--which is why javascript is so dynamic. Maybe browser A interprets the input of a textbox as the "best fit" type, but browser B always interprets as a string. Using === causes a compatibility problem between the two browsers.

@Rahly 2016-06-27 19:59:42

@Devsman yes they are evil, but what you are talking about is a function of the browser NOT of javascript. This is no different than Mozilla creating a function that returns a string, and webkit returns an object. In that case ==/!= doesn't work anyway. And there is a guarantee, anyone who creates a new browser now, HAS to accept the javascript currently being used, because if you can't even bring up the basic web pages like facebook, instagram, or someone's bank. No one is going to use the browser (outside of a niche).

@Brandon Boone 2016-07-29 02:19:40

To add to the discussion, Kyle Simpson makes a good case for type coercion via ==. Well worth the read or listen if you have time.

@Shanimal 2016-10-26 22:07:26

I just want to add that jquery will convert a string value in an attribute to a number, $('.foo').attr('data-id'), $('.foo').data('id'), $('.foo').prop('data-id') so if you insist on strict equality comparisons you have to be sure you "convert" the number first to an integer before doing the comparison. ALSO the argument that double equals is "EVIL" is evil.

@Shadi Namrouti 2016-11-22 09:55:28

I think === (on the long term) is slower because you have to add extra lines of codes to do possible explicit conversions. However, I love === when it comes to financial calculations because you must do strong-typed work and not leave numbers volatile with unknown conversions.

@sp00m 2017-11-23 15:31:23

Logic: if a == b and b == c, then a == c. JS: "0" == 0 and 0 == [], but "0" != [].

@ThaJay 2018-02-28 17:07:53

== does not use logic. try a === b and b === c, then a === c

@MattE 2018-04-24 23:34:46

The people who worry about which is faster in such a meaningless and inconsequential thing as this are the same people who have no issue writing crap code in quadratic big O complexity instead of writing good code. Anyone who knows anything about coding knows that worrying about whether === or == takes longer is complete nonsense.

@camjocotem 2018-05-01 12:16:44

What if for some reason (bad design?) via different API endpoints it would return the same results but as different types? And for some reason you didn't have access to change the API. Could return "2" or 2. You'd need == there :)

@Jack Giffin 2018-05-13 14:27:47

@MarcoDemaio All those evil constructors, non-numerical objects, jQuery and other libraries add a lot more onto the pay load. Also, using the === will likely take less time to process because the JIST compiler doesn't have to output extra type checking garbage there.

@Marco Demaio 2018-05-21 12:04:19

@AllanChua if you want to test if(val != 0 && val != '') , just do if(val).

@Dushyant Bangal 2018-06-06 10:27:37

== doesn't use logic. It uses the heart.

@Dushyant Bangal 2018-06-06 10:55:52

might as well stop using + because it does explicit coersion when you do 1+'1' and "...the rules by which they do that are complicated and unmemorable..."

@AleAssis 2018-08-17 20:19:21

From what I understand "abc" == new String("abc") // true because we are comparing the values while "abc" === new String("abc") // false because although the value is the same these are different objects. The "abc" constant is one object and the new String is a different object thus they are !== not the same

@Andy 2018-09-10 18:20:53

I'm disappointed that it's so hard to find actual advice is this thread, because this is one of the most helpful pieces of advice for new JS developers: Always use ===/!== to reduce the risk of unexpected bugs. The one exception is that you can safely use x == null to check if x is null or undefined (likewise for x != null).

@Andy 2018-09-10 18:25:08

@BrianM.Hunt I think you forgot to use new? 'abc' === new String('abc') is false. String('abc') does not construct a wrapper object, it just performs the default conversion to string on its argument, which is why 'abc' === String('abc').

@Andrew 2018-10-15 20:29:46

'' == undefined // false

@Orri Scott 2016-07-05 12:53:56

var a = new String("123");
var b = "123";

alert(a === b); // returns false !! (but they are equal and of the same type)

Saw this in one of the answers. a and b are not really the same type in this case, if you will check typeof(a) you will get 'object' and typeof(b) is 'string'.

@yanguya995 2016-07-01 17:00:02

Javascript is loosely typed just like php is,

var x = "20";
var y =20;

if (x===y) // false

This will always give you a false because even though the values of the variables are the same, the data types are not

One is string the the other is int


This however just checks if the content is the same, regardless of the data types...

I dont want to say the values are equal because a string value cannot be equal to an int value logically

@Alexandr 2016-07-01 13:29:08

always use '===' and you will avoid thousand of mistakes. nowadays using triple equality is more preferable by different style guides, because it compares taking into account type of operands.

@Alex Gray 2016-05-15 00:06:41

One unmentioned reason to use === - is in the case that you are co-existing with / cross-compiling to/from coffee-script. From The Little Book on CoffeeScript...

The weak equality comparison in JavaScript has some confusing behavior and is often the source of confusing bugs.

The solution is to instead use the strict equality operator, which consists of three equal signs: ===. It works exactly like the normal equality operator, but without any type coercion. It's recommended to always use the strict equality operator, and explicitly convert types if needs be.

If you are regularly converting to and from coffee-script, you should just use ===. In fact, the coffee-script compiler will force you to...

CoffeeScript solves this by simply replacing all weak comparisons with strict ones, in other words converting all == comparators into ===. You can't do a a weak equality comparison in CoffeeScript, and you should explicitly convert types before comparing them if necessary.

@Dmitri Pavlutin 2016-01-04 13:26:38

Yes, there is a big difference between equality == and identity === operators.
Usually the identity operator performs faster, because no types conversion is done. But if the values are of the same type, you'll see no difference.
Check my post The legend of JavaScript equality operator, which explains the details, including the types conversion & comparison algorithms, with a lot of examples.

@user2496033 2013-07-03 04:08:25

JavaScript === vs == .

0==false   // true
0===false  // false, because they are of a different type
1=="1"     // true, auto type coercion
1==="1"    // false, because they are of a different type

@Paul Butcher 2010-05-12 12:59:13

From the core javascript reference

=== Returns true if the operands are strictly equal (see above) with no type conversion.

@nalply 2009-11-28 18:18:00

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".

@Dfr 2012-11-15 18:35:49

Result of Type(x) is implied to be the same as typeof ?

@Andy 2018-09-10 18:28:06

@nalply I don't exactly understand the anxiety about the behavior with new String('x'), because I've never seen any code in the wild that uses primitive wrapper objects, and I don't think there's much good reason to, especially not these days. Have you ever encountered code that does?

@nalply 2018-09-11 09:46:36

@Andy the problem is malicious or just sloppy third-party code, then you can't assume that nobody uses new String().

@Andy 2018-09-12 15:34:23

If it's sloppy, === is how you will find out. If it's malicious, I think new String() is probably the least of your worries. I understand the concern in theory, but again, do you have any real-world examples? To me it's like the old anxiety that someone could set undefined to another value.

@Samar Panda 2015-09-05 13:53:16

Javascript execution flow diagram for strict equality / Comparison '==='

Javascript strict equality

Javascript execution flow diagram for non strict equality / comparison '=='

Javascript non equality

@vsync 2017-02-11 13:26:09

I don't understand why the string arrow is pointing to the big gray box, is it supposed to mean the interrupter is casting the string to a number?

@Samar Panda 2017-02-12 06:56:21

@vsync It points to the string option within the grey box i.e string -> # || NaN. Javascript is not a type-script language i.e basically it can have any type of variable. So, it is pointed to that grey box.

@vsync 2017-02-12 08:44:48

I simply asked if it is for casting purposes since the string is supposed to be compared to a type number, so the interrupter looks at what the string should be compared to and cast the string accordingly?

@user2033427 2018-03-07 05:54:22

The big gray box is what ToNumber would return when given different types, so if it is given a string it will only choose the last option (and convert it to a number). == uses ToNumber only in the cases string == number or boolean == anything above (and only on the string/boolean). This means == will never convert undefined or null even though they are in the gray box. (For any combination of either undefined or null or both, == will always return true. Also, whether a value is on the left or right side doesn't matter, == (and ===) will return the same result.)

@CodeFarmer 2015-08-06 05:44:24

My reasoning process using emacs org-mode and node.js to run a test.

| use =      | '' | '0' | false | 'false' | undefined | null | ' \t\r\n ' |
| ''         | x  | f   | t     | f       | f         | f    | f          |
| '0'        |    | x   | t     | f       | f         | f    | f          |
| false      |    |     | x     | f       | f         | f    | t          |
| 'false'    |    |     |       | x       | f         | f    | f          |
| undefined  |    |     |       |         | x         | t    | f          |
| null       |    |     |       |         |           | x    | f          |
| ' \t\r\n ' |    |     |       |         |           |      | x          | 

| use ===    | '' | '0' | false | 'false' | undefined | null | ' \t\r\n ' |
| ''         | x  | f   | f     | f       | f         | f    | f          |
| '0'        |    | x   | f     | f       | f         | f    | f          |
| false      |    |     | x     | f       | f         | f    | f          |
| 'false'    |    |     |       | x       | f         | f    | f          |
| undefined  |    |     |       |         | x         | f    | f          |
| null       |    |     |       |         |           | x    | f          |
| ' \t\r\n ' |    |     |       |         |           |      | x          |

My test script below: run > node xxx.js

var rowItems = ['', '0', false, 'false', undefined, null, ' \t\r\n ']
var colItems = rowItems

for(var i = 0; i < rowItems.length; i++) {
    for (var j = 0; j < colItems.length; j++) {
        var r = (rowItems[i] === colItems[j]) ? true : false;
        console.log(rowItems[i] + " = " + colItems[j] + " " + r + " [" + i + "] ==> [" + j + "]")

@le_m 2017-12-03 02:11:44

Shouldn't it be use == instead of use = in your first table?

@CodeFarmer 2017-12-04 04:29:16

@le_m === is more strict then =, therefore it is in right order not the other way around.

@le_m 2017-12-04 04:49:34

No, I meant the single = should be a double ==. The single = is the assignment operator.

@Akshay Khale 2015-07-22 13:28:42

The javascript is a weakly typed language i.e. without any data-types as there in C,c++ eg. int, boolean, float etc. thus a variable can hold any type of value, that why these special comparison operators are there


var i = 20;var j = "20";

if we apply comparison operators these variables result will be

i==j //result is true


j != i//result is false

for that we need a special comparison operators which checks for the value as well as for the data type of the variable

if we do

i===j //result is false

@Vikas 2015-05-14 14:45:00

A simple example is

2 == '2'  -> true, values are SAME because of type conversion.

2 === '2'  -> false, values are NOT SAME because of no type conversion.

Related Questions

Sponsored Content

35 Answered Questions

[SOLVED] What is the !! (not not) operator in JavaScript?

  • 2009-04-24 08:13:58
  • Hexagon Theory
  • 448960 View
  • 2636 Score
  • 35 Answer
  • Tags:   javascript operators

21 Answered Questions

[SOLVED] What is the "-->" operator in C++?

27 Answered Questions

86 Answered Questions

[SOLVED] How do JavaScript closures work?

76 Answered Questions

[SOLVED] How do I remove a particular element from an array in JavaScript?

  • 2011-04-23 22:17:18
  • Walker
  • 5582882 View
  • 6920 Score
  • 76 Answer
  • Tags:   javascript arrays

18 Answered Questions

[SOLVED] Reference — What does this symbol mean in PHP?

47 Answered Questions

51 Answered Questions

2 Answered Questions

7 Answered Questions

Sponsored Content