Why Do We Need to Use Radix Parameter When Calling Parseint

Why do we need to use radix parameter when calling parseInt?

You might not always want to parse the integer into a base 10 number, so supplying the radix allows you to specify other number systems.

The radix is the number of values for a single digit. Hexidecimal would be 16. Octal would be 8, Binary would be 2, and so on...

In the parseInt() function, there are several things you can do to hint at the radix without supplying it. These can also work against you if the user is entering a string that matches one of the rules but doesn't expressly mean to. For example:

// Numbers with a leading 0 used a radix of 8 (octal) before ECMAScript 5.
// These days, browsers will treat '0101' as decimal.
var result = parseInt('0101');

// Numbers that start with 0x use a radix of 16 (hexidecimal)
var result = parseInt('0x0101');

// Numbers starting with anything else assumes a radix of 10
var result = parseInt('101');

// Or you can specify the radix, in this case 2 (binary)
var result = parseInt('0101', 2);

Why is it recommended to provide optional radix parameter to parseInt()?

In older versions of the language, parseInt() would cause the function to obey the normal JavaScript numeric constant syntax rules, including the recognition of a leading zero to denote octal constants, and a leading 0x to denote hex constants. Thus, if your code didn't explicitly insist on base 10, stray (possibly user-supplied) numbers with leading zeros would be interpreted as base-8 values, and leading 0x as hex.

The base-8 behavior is gone since ES5.1 (I think; might have been earlier), but the base 16 behavior is still there. (Probably a leading 0x is a little more rare as an accidental prefix than a simple leading 0.)

My experience looking at code here on Stack Overflow is that parseInt() is overused anyway. It's usually cleaner to convert strings (often, strings taken from DOM element .value properties) to numbers with the unary + operator:

var count = +document.getElementById("count").value;

That won't necessarily give you an integer, of course. However, what it will do is notice that the input string has trailing non-numeric garbage. The parseInt() function will simply stop parsing a string like "123abc" and give you 123 as the numeric value. The leading + will however give you a NaN.

If you need integers, you can always use Math.floor() or Math.round().

edit — a comment notes that ES2015 requires a leading 0o or 0O in "strict" mode for octal literals, but that doesn't apply to parseInt() which (in ES2015) only overrides the default radix for hex strings.

Using the parseInt() function and the radix parameter with ternary operators

The radix is another name for base, i.e. 2 for binary, 10 for decimal, 16 for hexadecimal, explained in more detail on the Mozilla Developer Network site.

In your example there is no radix parameter, so the interpreter will fall back to the default behaviour, which typically treats numbers as decimal, unless they start with a zero (octal) or 0x (hexadecimal).

JSLint says missing radix parameter

It always a good practice to pass radix with parseInt -

parseInt(string, radix)

For decimal -

parseInt(id.substring(id.length - 1), 10)

If the radix parameter is omitted, JavaScript assumes the following:

• If the string begins with "0x", the radix is 16 (hexadecimal)
• If the string begins with "0", the radix is 8 (octal). This feature is deprecated
• If the string begins with any other value, the radix is 10 (decimal)

(Reference)

Why is it recommended to provide optional radix parameter to parseInt()?

In older versions of the language, parseInt() would cause the function to obey the normal JavaScript numeric constant syntax rules, including the recognition of a leading zero to denote octal constants, and a leading 0x to denote hex constants. Thus, if your code didn't explicitly insist on base 10, stray (possibly user-supplied) numbers with leading zeros would be interpreted as base-8 values, and leading 0x as hex.

The base-8 behavior is gone since ES5.1 (I think; might have been earlier), but the base 16 behavior is still there. (Probably a leading 0x is a little more rare as an accidental prefix than a simple leading 0.)

My experience looking at code here on Stack Overflow is that parseInt() is overused anyway. It's usually cleaner to convert strings (often, strings taken from DOM element .value properties) to numbers with the unary + operator:

var count = +document.getElementById("count").value;

That won't necessarily give you an integer, of course. However, what it will do is notice that the input string has trailing non-numeric garbage. The parseInt() function will simply stop parsing a string like "123abc" and give you 123 as the numeric value. The leading + will however give you a NaN.

If you need integers, you can always use Math.floor() or Math.round().

edit — a comment notes that ES2015 requires a leading 0o or 0O in "strict" mode for octal literals, but that doesn't apply to parseInt() which (in ES2015) only overrides the default radix for hex strings.

Why does the radix for JavaScript's parseInt default to 8?

It only "defaults" to 8 if the input string starts with 0. This is an unfortunate carryover from C and C++.

You can use Number('0123') instead, or, as you said in the question, parseInt('0123', 10).

How do I work around JavaScript's parseInt octal behavior?

---

Can you tell me more about this carryover?

• Javascript eval function returning Octal value
• Octal number literals: When? Why? Ever?

---

Note: ECMAScript strict mode removes octal syntax.

Default parseInt radix to 10

If you store a reference to the original parseInt function, you can overwrite it with your own implementation;

(function () {
    var origParseInt = window.parseInt;

    window.parseInt = function (val, radix) {
        if (arguments.length === 1) {
            radix = 10;
        }

        return origParseInt.call(this, val, radix);
    };

}());

However, I strongly recommend you don't do this. It is bad practise to modify objects you don't own, let alone change the signature of objects you don't own. What happens if other code you have relies on octal being the default?

It will be much better to define your own function as a shortcut;

function myParseInt(val, radix) {
    if (typeof radix === "undefined") {
        radix = 10;
    }

    return parseInt(val, radix);
}

---

Related Topics