10

Why is this behavior difference between parseInt() and parseFloat()?

I have a string that contains 08 in it.

When I write this code:

alert(hfrom[0]);
alert(parseInt(hfrom[0]));
alert(parseFloat(hfrom[0]));

The following output is generated:

08
0
8

Why does parseInt and parseFloat return two different results in this case?

nnnnnn
  • 147,572
  • 30
  • 200
  • 241
Naveed Butt
  • 2,861
  • 6
  • 32
  • 55
  • 1
    Check this SO post: http://stackoverflow.com/questions/6900857/alertparseint09-shows-me-0-why It is because parseInt assume 08 to be parsed as Octal base as it starts with 0 – Chandu Mar 02 '12 at 05:30
  • Running on jsfilddle in chrome I get `8` for both functions: http://jsfiddle.net/nqNvw/ – gideon Mar 02 '12 at 05:31
  • 2
    @gideon, that's because you passed in numbers which were already converted to base-10 integers. If you pass in *strings* it behaves differently. See: http://jsfiddle.net/nqNvw/1/ (this is definitely a wtfjs kind of thing) – Ben Lee Mar 02 '12 at 05:33

2 Answers2

10

parseInt() assumes the base of your number according to the first characters in the string. If it begins with 0x it assumes base 16 (hexadecimal). Otherwise, if it begins with 0 it assumes base 8 (octal). Otherwise it assumes base 10.

You can specify the base as a second argument:

alert(parseInt(hfrom[0], 10)); // 8

From MDN (linked above):

If radix is undefined or 0, JavaScript assumes the following:

If the input string begins with "0x" or "0X", radix is 16 (hexadecimal). If the input string begins with "0", radix is eight (octal). This feature is non-standard, and some implementations deliberately do not support it (instead using the radix 10). For this reason always specify a radix when using parseInt. If the input string begins with any other value, the radix is 10 (decimal).

Paul
  • 139,544
  • 27
  • 275
  • 264
  • Also see the **Examples** section on that page. – Paul Mar 02 '12 at 05:33
  • Not anymore? They fixed it? parseInt('010') now prints 10 – Teddy Mar 28 '18 at 10:56
  • Looks like they fixed it to some extent. https://stackoverflow.com/a/22140772/1364747 – Teddy Mar 28 '18 at 11:07
  • 1
    @Teddy Correct. This answer from six years ago is no longer relevant, but the question doesn't make as much sense today either since nobody should see the behavior the OP did anymore. – Paul Mar 28 '18 at 15:10
  • True. I specifically Googled for parseInt vs parseFloat today and this question was in the top few links. – Teddy Mar 28 '18 at 15:13
  • @Teddy I think the title is an unfortunate choice, since it really has nothing to do with `parseFloat`. I closed it as a duplicate just now, but I'm not sure if that affects search rankings. Maybe the title should be edited too or something. – Paul Mar 28 '18 at 15:33
2

you should always include the radix param with parseInt() ex parseInt('013', 10) otherwise it can convert it to a different numeric base:

parseInt('013') === 11
parseInt('013', 10) === 13
parseInt('0x13') === 19
Charlie Pops
  • 78
  • 6