JavaScript NaN Type
This is a daily Javascript challenge from the CodeShot archive. Practice your knowledge of Type Of Nan and improve your technical interview readiness.
console.log(typeof NaN)Detailed Explanation
Why This Question Matters
If you’ve spent any time debugging JavaScript, you’ve probably run into NaN. It usually pops up when a mathematical operation fails—like trying to divide a string by a number or parsing a malformed date.
The confusion starts when you try to figure out what NaN actually *is*. If it stands for "Not a Number," why on earth would the language treat it as one? It feels like a contradiction. This isn't just a trivia question for interviews; it's a window into how JavaScript handles floating-point numbers and the IEEE 754 standard. Understanding this prevents those "silent failures" where your app doesn't crash, but your calculations suddenly turn into a mess of NaN values.
Understanding the Code
The snippet is dead simple:
On the surface, you're asking JavaScript to tell you the data type of the value NaN.
Internally, JavaScript doesn't have a specific "NaN type." Instead, NaN is a special value defined by the IEEE 754 floating-point specification. In this spec, NaN is a state that represents an "undefined or unrepresentable value."
Because the spec dictates that NaN is a member of the double-precision 64-bit binary format, JavaScript classifies it as a number. It’s not a number in the sense that you can do math with it, but it is a "numeric type" in the sense of how it's stored in memory.
Finding the Correct Answer
The correct answer is Option C: "number".
If you run typeof NaN in your console, you'll see "number". Here is why the other common guesses are wrong:
NaN is not wrapped in quotes and isn't a sequence of characters. While you can convert it to a string using .toString(), its native type is numeric.undefined means a variable has been declared but not assigned a value. NaN is a very specific value assigned to a variable after a failed numeric operation.NaN isn't true or false, though it is "falsy" when evaluated in an if statement.Essentially, JavaScript is saying: *"This value is the result of a numeric operation that failed, so it still belongs in the number category."*
Common Mistakes Developers Make
The biggest trap is assuming NaN behaves like any other number. The most famous quirk in the language is this:
NaN is the only value in JavaScript that is not equal to itself.
Beginners often try to check for NaN using a simple equality check:
Because NaN === NaN is false, this check is useless. If you want to know if a value is NaN, you have two real options:
1. isNaN(): The global function. Be careful here; it coerces the value to a number first, which can lead to weird results (e.g., isNaN("hello") is true).
2. Number.isNaN(): The ES6 method. This is the gold standard because it doesn't do type coercion. It only returns true if the value is actually NaN.
Real-World Usage
In production, NaN usually sneaks in through API responses or user input. Imagine you're building an e-commerce checkout. You fetch a price from an API, but for some reason, the API returns null or a string like "Price TBD".
If you do something like:
And
apiPrice is "Price TBD", parseFloat returns NaN. Once a single NaN enters your math pipeline, it acts like a virus—any further operation involving that NaN will also result in NaN.
This is why senior devs don't just rely on typeof. We use "guard clauses" or validation libraries (like Zod or Joi) to ensure data is actually a valid number before performing calculations. Checking typeof value === 'number' isn't enough, because as we've seen, NaN passes that test perfectly.
Key Takeaways
typeof NaN returns "number" because it follows the IEEE 754 floating-point standard.NaN is the only value in JS that is not equal to itself.== or === to check for NaN.Number.isNaN() for reliable type checking.NaN is "contagious"—once it hits your math, the rest of your calculations will likely fail too.Why this matters
Understanding Type Of Nan is crucial for passing technical interviews. In real-world applications, this concept often leads to subtle bugs if not handled correctly. For more details, you can always refer to the official MDN Documentation.