Number.parseFloat
turns the leading decimal portion of a string into a JavaScript number. It understands an optional sign, a decimal point, and scientific notation, and it stops parsing at the first character that doesn’t belong to a decimal literal. If nothing valid appears at the start, the result is NaN
. Number.parseFloat
is the same function as the global parseFloat
, just namespaced under Number
.
Number.parseFloat("3.14159"); // 3.14159
Number.parseFloat(" -2.5e3 "); // -2500
Number.parseFloat("42px"); // 42
Number.parseFloat("px42"); // NaN
Number.parseFloat === parseFloat; // true
Signature, coercion, and whitespace
Call Number.parseFloat(input)
. Before parsing, the argument is coerced to a string. Leading whitespace is ignored, then an optional sign +
or -
is read, followed by the longest sequence that matches a decimal number literal (including an optional exponent like e-3
). Trailing garbage is ignored; parsing stops as soon as a non-literal character appears.
Number.parseFloat("\n\t +0.125 "); // 0.125
Number.parseFloat(true); // NaN ← parses "true"
Number.parseFloat(null); // NaN ← parses "null"
What counts as a “decimal literal” here
A valid prefix can be an integer like "12"
, a fraction like ".5"
or "12."
, or a combination like "12.34"
, optionally followed by an exponent part "e±digits"
. Hex, binary, and octal syntaxes aren’t recognized by parseFloat
. The decimal separator is always a dot, never a comma.
Number.parseFloat(".5"); // 0.5
Number.parseFloat("1."); // 1
Number.parseFloat("1.23e-2"); // 0.0123
Number.parseFloat("0xFF"); // 0 ← hex not recognized; parsing stops at 'x'
Number.parseFloat("1,23"); // 1 ← comma ends parsing (not locale-aware)
How parseFloat
differs from Number()
and Number.parseInt
Number()
is strict: the entire string must be a valid number literal or you get NaN
. Number.parseFloat()
is forgiving and returns the numeric prefix only. Number.parseInt()
produces an integer in a given radix and doesn’t understand decimal points or exponents. These differences matter in validation vs extraction scenarios.
Number("10.5 kg"); // NaN
Number.parseFloat("10.5 kg"); // 10.5
Number.parseInt("10.5", 10); // 10
Number.parseFloat("10.5"); // 10.5
Special values: Infinity
, NaN
, and signed zero
The tokens Infinity
and -Infinity
are accepted, producing the corresponding numeric infinities. NaN
parses to NaN
. Signed zero can appear when the sign is present but the magnitude rounds to zero; JavaScript preserves the sign bit.
Number.parseFloat("Infinity"); // Infinity
Number.parseFloat(" -Infinity"); // -Infinity
Number.parseFloat("NaN"); // NaN
Object.is(Number.parseFloat("-0"), -0); // true
Precision, safety, and large numbers
The return type is a JavaScript Number
(IEEE-754 double). That gives you about 15–17 significant decimal digits of precision. Very large or very precise inputs may be rounded, and integer-like values above Number.MAX_SAFE_INTEGER
won’t be exact. If you need exact big integers, parse the string yourself or use BigInt
(noting that parseFloat
can’t produce a BigInt).
Number.parseFloat("9007199254740993"); // 9007199254740992 (rounded)
BigInt("9007199254740993"); // 9007199254740993n (exact)
Locale isn’t involved
Number.parseFloat
ignores locale. It never treats commas as decimal points, it doesn’t use non-Latin numerals, and it doesn’t group thousands. If you must parse human-entered locale formats like "1 234,56"
, normalize the string first or use locale-aware parsing logic; don’t rely on parseFloat
.
Number.parseFloat("1.234,56"); // 1.234 ← stops at the comma
Number.parseFloat("١٢٣٫٤٥"); // NaN ← Arabic-Indic digits aren’t recognized
Common edge cases you should test
Exponent markers require digits; if the exponent is malformed, parsing typically stops before the e
. Numeric separators (_
) and BigInt suffixes (n
) aren’t valid and will terminate parsing. Objects are first stringified; most stringify to "[object Object]"
, which isn’t numeric.
Number.parseFloat("1.23e"); // 1.23
Number.parseFloat("1_000.5"); // 1 ← '_' is invalid in a string number
Number.parseFloat("123n"); // 123
Number.parseFloat({}); // NaN ← parses "[object Object]"
Practical recipes
When you want a tolerant extract-the-number-up-front behavior, Number.parseFloat
is ideal. Pair it with a postcheck if you require a complete match, or with a range/NaN check for input sanitation.
// Extract the leading decimal number; return null if there isn't one.
function readDecimalPrefix(s) {
const x = Number.parseFloat(String(s));
return Number.isNaN(x) ? null : x;
}
readDecimalPrefix(" 250.75kg"); // 250.75
readDecimalPrefix("kg250.75"); // null
If you need to verify that the whole string was a valid decimal number, compare back to a canonical re-encoding.
function isStrictDecimal(s) {
if (typeof s !== "string") return false;
const x = Number.parseFloat(s);
if (!Number.isFinite(x)) return false;
// Re-encode with toString() which uses a standard form for finite numbers.
return x.toString() === s.trim();
}
isStrictDecimal("12.5"); // true
isStrictDecimal("12.5kg"); // false
Under the hood
The specification defines parseFloat
as converting its argument to a string and parsing according to the StrDecimalLiteral grammar, which includes optional sign, decimal integer/fraction parts, and an optional exponent. Number.parseFloat
is specified to be the same intrinsic function as the global parseFloat
.
// Same intrinsic in all compliant engines:
Number.parseFloat === parseFloat; // true
References
Source | What it covers |
---|---|
MDN: Number.parseFloat() | Behavior of Number.parseFloat , coercion to string, handling of whitespace, Infinity /NaN , examples. |
MDN: parseFloat() | Global alias semantics, accepted number syntax, stopping at first invalid character, non-locale behavior. |
ECMAScript® Language Specification (latest snapshot) | Normative algorithms for parseFloat , relationship to the StrDecimalLiteral grammar, and numeric semantics of Number . |
MDN: Number | Precision characteristics of IEEE-754 Number , safe integer considerations, and contrasts with parseInt and Number() . |