Why is isNaN(null) == false in JS?

This code in JS gives me a popup saying "i think null is a number", which I find slightly disturbing. What am I missing?

if (isNaN(null)) {
  alert("null is not a number");
} else {
  alert("i think null is a number");
}

I'm using Firefox 3. Is that a browser bug?

Other tests:

console.log(null == NaN);   // false
console.log(isNaN("text")); // true
console.log(NaN == "text"); // false

So, the problem seems not to be an exact comparison with NaN?

Edit: Now the question has been answered, I have cleaned up my post to have a better version for the archive. However, this renders some comments and even some answers a little incomprehensible. Don't blame their authors. Among the things I changed was:

• Removed a note saying that I had screwed up the headline in the first place by reverting its meaning
• Earlier answers showed that I didn't state clearly enough why I thought the behaviour was weird, so I added the examples that check a string and do a manual comparison.

I believe the code is trying to ask, "is x numeric?" with the specific case here of x = null. The function isNaN() can be used to answer this question, but semantically it's referring specifically to the value NaN. From Wikipedia for NaN: > NaN (Not a Number) is a value of the numeric data type representing an undefined or unrepresentable value, especially in floating-point calculations.

In most cases we think the answer to "is null numeric?" should be no. However, isNaN(null) == false is semantically correct, because null is not NaN.

Here's the algorithmic explanation:

The function isNaN(x) attempts to convert the passed parameter to a number¹ (equivalent to Number(x)) and then tests if the value is NaN. If the parameter can't be converted to a number, Number(x) will return NaN². Therefore, if the conversion of parameter x to a number results in NaN, it returns true; otherwise, it returns false.

So in the specific case x = null, null is converted to the number 0, (try evaluating Number(null) and see that it returns 0,) and isNaN(0) returns false. A string that is only digits can be converted to a number and isNaN also returns false. A string (e.g. 'abcd') that cannot be converted to a number will cause isNaN('abcd') to return true, specifically because Number('abcd') returns NaN.

In addition to these apparent edge cases are the standard numerical reasons for returning NaN like 0/0.

As for the seemingly inconsistent tests for equality shown in the question, the behavior of NaN is specified such that any comparison x == NaN is false, regardless of the other operand, including NaN itself¹.

I just ran into this issue myself.

For me, the best way to use isNaN is like so

isNaN(parseInt(myInt))

taking phyzome's example from above,

var x = [undefined, NaN,     'blah', 0/0,  null, 0,     '0',   1,     1/0, -1/0,  Number(5)]
x.map( function(n){ return isNaN(parseInt(n))})
        [true,      true,    true,   true, true, false, false, false, true, true, false]

( I aligned the result according to the input, hope it makes it easier to read. )

This seems better to me.

This is indeed disturbing. Here is an array of values that I tested:

var x = [undefined, NaN, 'blah', 0/0, null, 0, '0', 1, 1/0, -1/0, Number(5)]

It evaluates (in the Firebug console) to:

,NaN,blah,NaN,,0,0,1,Infinity,-Infinity,5

When I call x.map(isNaN) (to call isNaN on each value), I get:

true,true,true,true,false,false,false,false,false,false,false

In conclusion, isNaN looks pretty useless! (Edit: Except it turns out isNaN is only defined over Number, in which case it works just fine -- just with a misleading name.)

Incidentally, here are the types of those values:

x.map(function(n){return typeof n})
-> undefined,number,string,number,object,number,string,number,number,number,number

(My other comment takes a practical approach. Here's the theoretical side.)

I looked up the ECMA 262 standard, which is what Javascript implements. Their specification for isNan:

> Applies ToNumber to its argument, then returns true if the result is NaN, and otherwise returns false.

Section 9.3 specifies the behavior of ToNumber (which is not a callable function, but rather a component of the type conversion system). To summarize the table, certain input types can produce a NaN. These are type undefined, type number (but only the value NaN), any object whose primitive representation is NaN, and any string that cannot be parsed. This leaves undefined, NaN, new Number(NaN), and most strings.

Any such input that produces NaN as an output when passed to ToNumber will produce a true when fed to isNaN. Since null can successfully be converted to a number, it does not produce true.

And that is why.

Null is not NaN, as well as a string is not NaN. isNaN() just test if you really have the NaN object.

In ES5, it defined as isNaN (number) returns true if the argument coerces to NaN, and otherwise returns false.

• If ToNumber(number) is NaN, return true.
• Otherwise, return false.

And see the The abstract operation ToNumber convertion table. So it internally js engine evaluate ToNumber(Null) is +0, then eventually isNaN(null) is false

I'm not exactly sure when it comes to JS but I've seen similar things in other languages and it's usually because the function is only checking whether null is exactly equal to NaN (i.e. null === NaN would be false). In other words it's not that it thinks that null is in fact a number, but it's rather that null is not NaN. This is probably because both are represented differently in JS so that they won't be exactly equal, in the same way that 9 !== '9'.

Note:

"1" == 1 // true
"1" === 1 // false

The == operator does type-conversion, while === does not.

http://crockford.com/">Douglas Crockford's website, a Yahoo! JavaScript evangelist, is a great resource for stuff like this.

(NaN == null) // false
(NaN != null) // true

Funny though:

(NaN == true)  // false
(NaN == false) // false
(NaN)          // false
(!NaN)         // true

Aren't (NaN == false) and (!NaN) identical?