← Home

Interesting NumberFormat API behavior

The Intl.NumberFormat API behaves in an interesting way when fed with invalid input. Its format method takes one number argument, but it still “works” if it’s provided with a string argument.

(new Intl.NumberFormat("de")).format("0.1")
//> "0,1"

In essence, you can feed it with string values that look like JavaScript numbers (i.e. most values for which Number(value) would not return NaN though that isn’t exactly how this works under the hood). If you provide other values like letters, it returns “NaN”.

(new Intl.NumberFormat("en")).format("x")
//> "NaN"

Note that the return value isn’t the special value NaN but the string value "NaN". Annoyingly, you can’t reliably detect such a failure by checking for strict equality with the string literal "NaN" because, and that was quite surprising, the result is sometimes localized:

(new Intl.NumberFormat("ru")).format("x")
//> "не число"

For some locales (e.g. "ru", "tk"), the returned value isn’t “NaN” but rather the translation of the phrase “not a number” (that’s what “не число” translates to). I’ve tried this in the latest stable versions of Mozilla Firefox and Google Chrome.

I would’ve preferred for calls to format with “it doesn’t look like a number” values to either return null or "NaN" (consistently) or to throw an error. Then, one would be able to detect whether a string value looks like a JavaScript number. Not that this would be very useful. One can already perform this kind of check using !Number.isNaN(parseFloat(value)).