The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Use Number(value) when the whole value must be a valid JavaScript number; use parseInt() or parseFloat() when you deliberately want to extract a numeric prefix. For example, Number("12px") returns NaN, while both prefix parsers return 12. That makes Number() useful for rejecting trailing junk—but it is not complete input validation, because it also coerces values such as empty strings and null.
What is the difference between Number() and the prefix parsers?
Number(value) converts a string or another value to JavaScript’s ordinary Number type. When a string cannot be converted as a whole, the result is NaN. By contrast, parseInt() and parseFloat() convert their argument to a string, read from the beginning, and stop at the first character that is not part of the number syntax they accept. MDN documents these behaviors for Number, parseInt() and parseFloat().
The practical difference is whether the entire input matters. If a field is meant to contain only a number, rejecting extra characters can reveal malformed input. If the goal is to extract a number from a larger string, stopping at the first non-numeric character may be exactly what you want.
| Input or goal | Number(value) |
parseInt(text, radix) |
parseFloat(text) |
|---|---|---|---|
Decimal string "12.5" |
12.5 |
12 |
12.5 |
Text with a suffix: "12px" |
NaN |
12 with radix 10 |
12 |
Exponent notation: "1.25e2" |
125 |
1 |
125 |
Hexadecimal string: "0x10" |
16 |
16 when the radix is inferred or set to 16 |
0 |
Empty string: "" |
0 |
NaN |
NaN |
These are JavaScript behaviors documented by MDN. In the parseInt() decimal example, radix 10 is explicit.
#1 Best Overall
When should you use Number()?
Use Number(text) when a value is supposed to be a complete numeric string and any trailing text should make conversion fail. This is often the better conversion step for a form field or configuration value whose contract says “number only.” Then check that the result is finite if NaN and infinities are not allowed:
const value = Number(text);
if (!Number.isFinite(value)) {
throw new Error("Enter a finite number");
}Conversion is only one part of validation. Also decide whether the input was present, whether its original type is allowed, and whether the result falls within the application’s permitted range. For example, a valid finite number can still be an invalid age, quantity, or configuration setting.
Rank #2
When should you use parseInt() or parseFloat()?
Use parseInt() for an integer prefix
parseInt(text, radix) reads an integer prefix using the specified base, or radix. Supply the radix when you know the intended base so the code makes its meaning explicit:
const decimal = parseInt("42 items", 10); // 42
const binary = parseInt("1010", 2); // 10The radix can be from 2 through 36. parseInt() is a parsing choice, not a separate integer type: its result is still a JavaScript Number.
Recommended Free Tools
Use parseFloat() for a decimal prefix
parseFloat(text) reads the longest valid decimal-number prefix, including fractions and exponent notation. It is decimal-only, so it does not interpret a hexadecimal prefix as a base-16 number. It also does not parse units: parseFloat("12px") returns 12, not a value that retains or validates the px suffix. If a unit is required, parse and validate that unit separately.
What coercion traps should you check?
Number() accepts more than strings, and some conversions can be surprising if the input contract is not explicit:
Rank #4
Number("")andNumber(" ")return0.Number(null)returns0, whileNumber(undefined)returnsNaN.- Booleans and objects are also subject to JavaScript coercion rules.
If empty input or a non-string value should not count as a number, check presence and type before conversion instead of relying on Number() alone.
Does Number() preserve very large integers?
No. JavaScript’s ordinary Number uses IEEE 754 binary64 representation, so it cannot exactly represent every integer. The safe integer range is from −(253 − 1) through +(253 − 1), as described by MDN’s Number documentation and the ECMA-262, 12th edition (June 2021).
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
For integer strings that need arbitrary precision, use BigInt where appropriate rather than converting through Number. Do not use parseInt() on a BigInt-formatted string expecting exactness: it can ignore the trailing n, and the resulting Number may have lost precision. Number() applied to a BigInt also returns a Number and may lose precision.
Quick Recap
Which conversion should you choose?
- Complete numeric value, no extra text: use
Number(text), then check finiteness and the allowed range. - Integer prefix in a known base: use
parseInt(text, radix)and specify the radix. - Decimal prefix that may have a fraction or exponent: use
parseFloat(text); validate any required suffix separately. - Input that may be empty, absent, or the wrong type: validate presence and type before coercion.
- Integer values beyond Number’s exact range: consider
BigIntrather than either Number conversion or prefix parsing.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
