IsNumeric in JavaScript: 5 Fatal Errors in Number Validation

Validating Decimal Numbers in JavaScript: Why IsNumeric() Breaks Code and How to Fix It

Every developer who has written JavaScript for at least a week has, sooner or later, faced the task: "Check if a string is a number." It seems simple enough, right? The built-in isNaN() or parseFloat() function — and you're done. But it's not that simple. The question "Validate decimal numbers in JavaScript — IsNumeric()" on Stack Overflow has gathered hundreds of thousands of views and dozens of conflicting answers. Why? Because JavaScript is a language where typeof NaN === 'number', and an empty string is considered zero.

In this article, we won't just give you a ready-made isNumeric() function. We'll break down the 5 most common and dangerous mistakes that even experienced programmers make, and show you how to avoid them. You'll learn why isNaN is a trap, how type coercion works, and which number validation method in JS is actually suitable for production.

Why isNaN() is Evil (And When It Works)

Let's start with the obvious. Many beginners write code like this:

function isNumeric(n) {\n  return !isNaN(n);\n}\n

At first glance, it's logical: if it's not NaN, it's a number. But let's test it:

console.log(isNumeric('123'));    // true — ok\nconsole.log(isNumeric('12.3'));   // true — ok\nconsole.log(isNumeric(''));       // true — OOPS! Is an empty string a number?\nconsole.log(isNumeric(' '));      // true — Is a space a number too?\nconsole.log(isNumeric(null));     // true — Is null a number?\nconsole.log(isNumeric(true));     // true — true is 1\n

Mistake #1: isNaN() first converts the argument to a number, then checks. The empty string '' converts to 0, null converts to 0, true converts to 1. As a result, the function considers things that are not numbers as numbers.

There is a strict version — Number.isNaN() (ES6), but it only checks if the value is exactly NaN, without conversion. It's also not suitable for number validation.

parseFloat: Hero or Villain?

The second popular approach is to use parseFloat():

function isNumeric(n) {\n  return !isNaN(parseFloat(n)) && isFinite(n);\n}\n

This version is better, but it has another problem:

console.log(isNumeric('123abc')); // true — parseFloat will take '123', ignoring 'abc'\nconsole.log(isNumeric('12.3.4')); // true — parseFloat simply won't notice the second dot\nconsole.log(isNumeric('Infinity')); // true — Is infinity a number?\n

Mistake #2: parseFloat() parses the string up to the first invalid character. The string '123abc' is 123 for it. But the user might have accidentally pressed an extra key, and we must catch that.

Mistake #3: isFinite() filters out Infinity and -Infinity, but lets NaN and undefined through. The problem is that isFinite(null) returns true, because null converts to 0.

Mistake #4: Regular Expressions — A Panacea or a New Hell?

When developers realize that built-in functions are unreliable, they often swing to the other extreme — regular expressions. And that's where the real chaos begins.

Here's a typical but dangerous regex:

function isNumeric(n) {\n  return /^\\d+$/.test(n);\n}\n

Problems:

\n
• Doesn't allow decimal points ('12.3' — false)
\n
• Doesn't allow negative numbers ('-5' — false)
\n
• Doesn't allow scientific notation ('1e5' — false)
\n

Here's a "u