parseInt()

parseInt(string, radix)

Returns number· Added in vES1· Updated June 2, 2026· Global Functions

javascriptparseintglobalconversionparsing

The parseInt() function parses a string argument and returns an integer of the specified radix (base). It is commonly used to convert string representations of numbers into actual numeric values.

Syntax

parseInt(string)
parseInt(string, radix)

Parameters

Parameter	Type	Description
`string`	string	The value to parse. If not a string, it is converted to one first. Leading whitespace is ignored.
`radix`	number	An integer between 2 and 36 representing the base of the number system. Default is 10.

Return Value

The parsed integer. If the first character cannot be converted, NaN is returned.

Examples

Basic integer parsing

parseInt("42");
// 42

parseInt("  123  ");
// 123

parseInt("42px");
// 42 (parses until invalid character)

The examples above all use the default decimal radix, which is the most common case. But parseInt() can also interpret strings in binary, octal, and hexadecimal by passing a second argument. This is essential when reading data from sources that store numbers in non-decimal formats, such as file headers, color codes, or hardware registers.

Parsing with different radices

// Binary (base 2)
parseInt("1010", 2);
// 10

// Octal (base 8)
parseInt("777", 8);
// 511

// Hexadecimal (base 16)
parseInt("ff", 16);
// 255

Radix parsing is straightforward when you know the input format, but several edge cases trip up developers who are used to how other languages handle numeric literals. The next example covers leading zeros, explicit octal radix, and floating-point truncation---each a situation where the parser’s behavior can differ from what you might expect.

Common Pitfalls

// Leading zeros do not mean octal in modern JS (unless radix is 8)
parseInt("010");
// 10

// But with explicit radix 8:
parseInt("010", 8);
// 8

// Floating-point numbers are truncated
parseInt("3.14");
// 3

The pitfall examples show what happens with leading zeros and decimals, but parseInt() has a clear failure mode too: when the string does not start with a valid digit, the function returns NaN. The next snippet confirms this behavior and contrasts it with Number(), which handles the empty string differently.

Invalid Input

parseInt("hello");
// NaN

parseInt("");
// NaN (unlike Number() which returns 0)

When to Use parseInt()

This function is useful when you need to:

Convert user input strings to numbers
Parse CSS pixel values (e.g., “100px”)
Read numeric data from external sources that use specific radix formats

Differences from Number()

Unlike the Number() constructor, parseInt() has distinct behavior:

Number("42px");
// NaN (the entire string must be a valid number)

parseInt("42px");
// 42 (parses until it hits an invalid character)

Number("010");
// 10 (leading zeros are ignored)

parseInt("010");
// 10 (same, but radix matters)

Unlike the Number() constructor, parseInt() has distinct behavior that matters in practice: Number() demands a valid numeric string in its entirety, while parseInt() reads digits until it hits a non-numeric character. This means parseInt("42px") succeeds where Number("42px") fails. The trade-off is that parseInt() can silently produce partial results from malformed input, so if you need strict validation you should pair it with a check that the entire string was consumed.

Radix best practices

Always specify the radix when parsing. Explicit radix prevents unexpected behavior and is widely recommended by linters including ESLint’s radix rule.

// Explicit radix prevents unexpected behavior
parseInt("10", 10);
// 10

// Without radix, some implementations may guess incorrectly
parseInt("010");
// 10 (but could be 8 in older environments)

The radix argument is the single most important defensive practice with parseint. Without it, the function can behave differently across environments, and linters will flag every call. Once you are in the habit of always passing the radix, the next thing to watch for is what happens when the input is not a string at all---the function converts it silently before parsing, and that conversion step hides several edge cases worth knowing about.

How parseInt() handles non-string input

The radix rule is essential for strings, but a separate pitfall arises when the first argument is not a string at all. In that case it is converted to a string using the String function before parsing begins. This implicit conversion can produce surprising results, especially with very small floats.

parseInt(0.000005);   // 5 (0.000005 → "5e-6" → parseInt reads "5")
parseInt(0.0000005);  // 5 (5e-7 → parseInt reads "5")
parseInt(null);       // NaN (null → "null", no leading digit)
parseInt([10]);       // 10 (array → "10", parses as 10)

The scientific notation case is a known gotcha: very small floats convert to exponential string notation, and parseInt() then reads only the mantissa.

Always specify the radix

Although modern engines default to base 10 for strings without a 0x prefix, always pass 10 as the second argument. This makes intent clear, prevents bugs in code that processes user input, and avoids any edge case with older environments.

// Defensive coding
const n = parseInt(userInput, 10);
if (Number.isNaN(n)) {
  throw new Error("invalid number");
}

parseInt() vs Math.trunc() and Math.floor()

parseInt() is not the right tool for truncating a floating-point number to an integer — use Math.trunc() for that. parseInt() converts via string, which is slower and breaks for exponential notation. Math.floor() rounds toward negative infinity (so Math.floor(-3.5) is -4), while Math.trunc() removes the decimal part toward zero (so Math.trunc(-3.5) is -3). Use parseInt() only when parsing strings, not for truncating numbers.

Why radix matters

The radix tells parseInt() how to interpret the digits it sees. Without it, the function can be harder to reason about, especially in code that handles user input or legacy formats. Writing the radix explicitly makes the intent obvious and avoids any dependency on environment quirks. In practice, 10 is the most common choice, but binary, octal, and hexadecimal parsing are all valid when the input format calls for them.