How to convert a string to a number in JavaScript

1Number() and unary +Recommended

Number(text) converts the entire string. Surrounding whitespace is ignored, a leading sign, decimals and exponents are fine, and anything else makes the result NaN. The unary plus operator, +text, runs exactly the same conversion and is common in compact code. Call Number without new: new Number() creates a wrapper object, not a number.

const text = "42";
const n = Number(text);

console.log(n, typeof n);
console.log(n + 8);        // real arithmetic
console.log(text + 8);     // string + number concatenates

console.log(Number("3.14"), Number("-7"), Number("1e3"), Number("  12  "));
console.log(Number("42px"), Number("abc"));

// Unary plus applies exactly the same rules, in one character
console.log(+"42", +"3.14", +"42px");

Prints 42 number, then 50, then 428. That third line is the bug this conversion exists to prevent: + with a string on either side concatenates, so form values and query parameters that were never converted turn sums into glued-together text. The next lines print 3.14 -7 1000 12 and NaN NaN, and unary plus gives the same answers, 42 3.14 NaN. Pick whichever reads better to your team; Number(text) is easier to spot in a review.

2parseInt() and parseFloat(): read the number at the start

parseInt and parseFloat are the older functions, and they work differently. They skip leading whitespace, read as many characters as make a number, and stop at the first one that doesn't fit, returning what they have. They only return NaN when there is nothing to read at all. That makes them right for text like "42px" and wrong for validation. Always pass parseInt its second argument, the radix: without it, a 0x prefix silently switches to hex.

// parseInt and parseFloat read from the start and stop at the first bad character
console.log(parseInt("42px", 10));
console.log(parseFloat("3.99 USD"));
console.log(parseInt("3.99", 10));       // stops at the dot
console.log(parseInt("abc", 10));        // nothing to read at all

// Always pass the radix
console.log(parseInt("0x1F"));           // no radix: "0x" switches to hex
console.log(parseInt("0x1F", 10));       // radix 10: stops at the "x"
console.log(parseInt("ff", 16), parseInt("1010", 2));

// parseInt turns its argument into a string first
console.log(parseInt(0.0000005));
console.log(String(0.0000005));

// ...and map passes the index as the second argument (the radix)
console.log(["10", "10", "10"].map(parseInt));
console.log(["10", "10", "10"].map(Number));

The partial reads print 42, 3.99, 3 and NaN: parseInt("3.99", 10) doesn't round, it just stops at the dot. Without a radix "0x1F" is 31, with radix 10 it is 0, and radix 16 and 2 give 255 10. parseInt(0.0000005) is 5 because the number becomes the string 5e-7 before parsing, so never use parseInt to drop the decimals of a number; use Math.trunc. Finally, .map(parseInt) prints [ 10, NaN, 2 ]: map calls it with (value, index), so the index lands in the radix slot. .map(Number) gives [ 10, 10, 10 ].

3The traps: empty strings, whitespace and partial text

The biggest surprise in Number() is that an empty or all-whitespace string converts to 0, not NaN. An empty form field is therefore a valid zero unless you check for it. The grid below runs the same inputs through all three functions so you can see exactly where they disagree.

const inputs = ["42", " 42 ", "", "   ", "\n", "42px", "3.99", "0x1F", "1e3", "1,234", "1_000", "Infinity"];

console.log("input       Number    parseInt  parseFloat");
for (const s of inputs) {
  console.log(
    JSON.stringify(s).padEnd(11),
    String(Number(s)).padEnd(9),
    String(parseInt(s, 10)).padEnd(9),
    parseFloat(s),
  );
}

// Not strings, but they reach Number() from forms and APIs all the time
console.log(Number(null), Number(undefined), Number(true));

Read the rows for "", " " and "\n": Number says 0 while both parse functions say NaN. The other rows show each function's own rules. Number accepts "0x1F" as 31 and "1e3" as 1000, where parseInt reads 0 and 1. Thousands separators and numeric-literal underscores are not part of the string format, so "1,234" and "1_000" are NaN for Number and a misleading 1 for the parse functions. The text "Infinity" converts to Infinity. The last line, 0 NaN 1, is null, undefined and true: a missing value can become a zero too.

4Check that a string is a valid number

Since nothing throws, validation means checking the result. Use the Number. versions: Number.isNaN(x) and Number.isFinite(x) only return true for actual numbers. The older global isNaN() and isFinite() convert their argument with Number() first, so they inherit every trap from section 3. A reliable check is three steps: make sure it's a non-blank string, convert with Number(), and accept only a finite result.

// The global isNaN converts first; Number.isNaN does not
console.log(isNaN("abc"), Number.isNaN("abc"));
console.log(isNaN(""), isNaN("   "));           // blank strings convert to 0
console.log(isFinite("42"), Number.isFinite("42"));

// A strict converter: a finite number, or null
function toNumber(value) {
  if (typeof value !== "string" || value.trim() === "") return null;
  const n = Number(value);
  return Number.isFinite(n) ? n : null;
}

// The classic Stack Overflow isNumeric check, for comparison
const isNumeric = (n) => !isNaN(parseFloat(n)) && isFinite(n);

for (const s of ["42", "-3.5", " 7 ", "1e3", "", "   ", "12px", "Infinity", "0x1F"]) {
  console.log(JSON.stringify(s).padEnd(10), String(toNumber(s)).padEnd(5), isNumeric(s));
}

// Whole numbers only
const qty = toNumber("2.5");
console.log(qty, Number.isInteger(qty));

The first three lines are true false, false false and true false. So the global isNaN calls a blank string a number, and Number.isFinite("42") is false because a string is not a number yet: convert first, then check. toNumber returns 42, -3.5, 7 and 1000 for the good inputs and null for the blank ones, "12px" and "Infinity". The classic isNumeric agrees on every row, which is why it earned its votes. Both accept "0x1F" (31), since Number reads hex; add a regex such as /^[+-]?(\d+\.?\d*|\.\d+)(e[+-]?\d+)?$/i if you need plain decimal only. For whole numbers add Number.isInteger, which prints 2.5 false here.

5Huge integers: BigInt

A JavaScript number is a 64-bit float, so it holds integers exactly only up to Number.MAX_SAFE_INTEGER, 2⁵³ − 1. Past that, Number() and parseInt still return a value, just not the one in the string, and no error tells you. Database IDs, snowflake IDs and 64-bit counters hit this all the time. BigInt(text) parses a whole-number string into an arbitrary-precision integer instead.

const id = "9007199254740993";       // MAX_SAFE_INTEGER + 2

console.log(Number.MAX_SAFE_INTEGER);
console.log(Number(id));             // silently rounded
console.log(Number.isSafeInteger(Number(id)));

const big = BigInt(id);
console.log(big, typeof big);
console.log(big + 1n);
console.log(String(big));

// BigInt accepts whole numbers only
for (const s of ["3.5", "12px"]) {
  try {
    BigInt(s);
  } catch (err) {
    console.log(err.name + ": " + err.message);
  }
}
console.log(BigInt(""), BigInt(" 12 "));  // the blank-string trap again

// ...and never mixes with Number in arithmetic
try {
  big + 1;
} catch (err) {
  console.log(err.name + ": " + err.message);
}

// Big IDs in JSON lose precision the same way; a reviver can read the raw text
const json = '{"id": 9007199254740993}';
console.log(JSON.parse(json).id);
console.log(JSON.parse(json, (key, value, ctx) => (key === "id" ? BigInt(ctx.source) : value)));

Number(id) prints 9007199254740992, one less than the string, and Number.isSafeInteger flags it with false. The BigInt is exact: 9007199254740993n bigint, and big + 1n is 9007199254740994n. Unlike Number(), BigInt() throws on bad text (SyntaxError: Cannot convert 3.5 to a BigInt) but shares the blank-string trap: 0n 12n. Mixing it with a regular number throws TypeError: Cannot mix BigInt and other types, use explicit conversions. The JSON lines print 9007199254740992, then { id: 9007199254740993n }: the reviver's third argument exposes the original source text, which is new enough that older runtimes don't pass it. The safest API design is still to send big IDs as strings.

6Which should you use?