Casting Values to Integers and Floats in JavaScript

32-bits in JavaScript

Before we get too far into it, we need to cover a common misconception about numbers: JavaScript numbers aren't only floating point numbers. The 64-bit floating point number is the most commonly used number, but it's not the only number. JavaScript has 32-bit signed and unsigned integers as well.

However, the 32-bit integer types are not explicitly typed, and will be converted back to 64-bit floating points at the earliest possible moment. This means it's extremely hard to to retain integers, and many web developers will probably not encounter them naturally. But, the 32-bit integers do exist.

The 32-bit integers are used as inputs and outputs of bitwise operators (& | << >> ^ >>>). Floating point numbers are first cast to a 32-bit integer, ran through the bitwise operator, and then are a 32-bit integer afterwards. There are signed and unsigned variants of the integers, and JavaScript does a bitwise cast between the two. JavaScript also interprets the sign as twos-complement. This means that the value 0xFFFFFFFF will be $-1$ for a signed int and $4,294,967,295$ for an unsigned integer. When converted back to a floating point number, they will both retain their decimal value (so $-1$ for a signed integer becomes $-1$ floating point, and $4,294,967,295$ unsigned integer becomes $4,294,967,295$ floating point).

You can see this with the following code:

// Signed 32-bit integer
console.log(((0xFFFFFFFF) | 0) + 10); // 9

// Unsigned 32-bit integer
console.log(((0xFFFFFFFF) >>> 0) + 10); // 4294967305

BigInt in JavaScript

There is one other integer form in JavaScript called BigInt. BigInt is an arbitrarily large integer that has (mostly) the same operations as a number. They automatically grow in size, so doing left shifts will always increase the size instead of overflow. The biggest difference though, is that BigInt operations can only be done between two BigInts. There is no adding a number to a BigInt. BigInt literals can be made by adding the suffix n to a number (e.g. 123n). Bitwise operations also exist for BigInt. BigInts can be converted back to a number, but care needs to be had to ensure it fits prior to converting. However, BigInt cannot be JSON serialized and deserialized. Trying to will result in an exception.

BigInt allows us to represent much larger numbers (e.g. 64-bit integers), but they struggle to keep a specific bitsize (unless you always bitmask them). They also make it clear we're working with integers and not floats. But the lack of JSON serializability can complicate client-server communications.

There is one additional quirk that needs to be mentiond. BigInts have a separate signed bit while also trying to mimick two's complement and also auto-growing. This means that most of the time you can treat them like two's complement integers, but sometimes you'll encounter a quirk. The most notable quirk is left-shifting always growing the bits rather than ever changing the sign, and multiplication doesn't result in overflow. When trying to mimic twos-complement bitops with BigInt, take extra care to properly mimic sign changes and overflows, otherwise you'll have sneaky bugs!

Casting Floats

There are two primary ways to cast to a floating point number: Number.parseFloat and the prefix + operator. These are both overly permissive of inputs - but in different ways.

Number.parseFloat takes a string as input, and then extracts the first numeric value from the string and returns it. Non-string inputs will be coerced to a string, so Number.parseFloat(123) still works. If the string doesn't start with a numeric value, it will return NaN. If the string is empty, it will return NaN.

The quirk is that Number.parseFloat will extract the first numeric value. So if a string starts with a number you'll get a number, even if the entire string isn't a number. For example, the string "123 Rhino Rd" will return the number 123, even though the string ends with " Rhino Rd". The ending is ignored. In contrast, "Ste. 240" will return NaN because the string does not start with a numeric value. The "parse the start of the string" behavior can lead to subtle bugs when trying to validate user input is indeed a number - so keep that in mind.

In contrast, the prefix + operator will take any input type and coerce to a number. Some types (like arrays) are first coerced to a string and then parsed, while other values (like null) are just converted to a predefined value (e.g. $0$). When it comes to strings, the parsing logic is different than Number.parseFloat. Instead of extracting the first numeric value, the prefix + operator parses the entire string. If any part of the string is not part of a valid numeric value, then NaN will be returned. And there's one little edge case too. An empty string will always return $0$.

The quirk here is that while "123 Rhino Rd" now returns NaN, "" now returns $0$. And while Number.parseFloat will return NaN for null, the prefix + operator returns $0$. This can still lead to subtle bugs when trying to validate user input is a valid number.

The best "is numeric" validation I can think of is to combine both methods. Something like the following:

function isNumeric(val) {
  // Could do !Number.isNaN if you want to allow +Infinity and -Infinity
  return Number.isFinite(Number.parseFloat(val)) && Number.isFinite(+val);
}

There may still be some edge cases, but I've found it to be good-enough. Now that we covered the easy stuff, let's dive into integers.

Casting Integers

There are a lot more ways to "cast" to integers. Here's a list grouped by behavior:

• Number.parseInt
• Math.round, Math.floor, Math.ceil
• Signed bitwise operators (+ | & ^ << >>)
• Unsigned bitwise operators (>>>)

console.log(Number.parseInt('900719925474099112321')); // 900719925474099100000

// The ending digits are different
// But due to precision loss we get the same value
const a = Number.parseInt('900719925474099129252');
const b = Number.parseInt('900719925474099102345');
console.log(a === b); // true

If you need an actual integer value (e.g. 32-bit integer) or to limit to Number.MAX_SAFE_INTEGER, then Number.parseInt will not work by itself.

Next options to try are Math.round, Math.floor and Math.ceil. These take a floating point number as input, and does some sort of rounding to get an "integer" value. These operators will coerce the input to a number using the same rules as the prefix + operator, so they can be used to convert strings to integers. They do share the same drawback as Math.parseInt as they have a full 64-bit floating point number as output, and they don't limit to be less than Number.MAX_SAFE_INTEGER. One thing to keep in mind is that there is some rounding going on instead of just truncation. That said, the rounding is explicit, which can help with readability.

At this point we've ended what I've generally seen accepted into production code by most coding standards. The above methods are generally chosen for "readability" reasons, but typically have nothing to do with actual behavior. Usually most code bases aren't typically working with numbers big enough to worry about the edge cases so far described. But, there are times where an actual integer is needed, or when a bitwise operation needs to be done. In those cases, developers need to understand the remaining integer casts. It gets especially important when porting over code from a langauge which is relying on specific bitwise operations or 32-bit behavior.

Signed bitwise operators will operate on a signed 32-bit integer and unsigned bitwise operators operate on unsigned 32-bit integers. However, when casting from a floating point number to 32-bit integers it gets a little weird. Per the spec[1], the inputs will be converted through code similar to the following:

function toUnsignedBitwiseInput(val) {
  const number = +val; // convert to number (ToNumber in spec)
  // handles non-finite numbers and signed zero
  if (!Number.isFinite(number) || number === +0 || number === -0) {
    return +0;
  }

  // Not using remainder operator since it has different behavior
  function modulo(x, y) {
    // modulo that seems to mimick what is used internally
    // Spec doesn't specify a modulo method, so this is my best guess
    return x - y * Math.floor(x / y);
  }

  // Per the spec, this is the definition of internal "flooring"
  function floor(x) {
    return x - modulo(x, 1);
  }
  // truncation is defined as "floor towards zero"
  const int = number < 0 ? -floor(number) : floor(number);

  const int2To32 = 0x100000000; // 2^32
  const int2To31 = int2To32 >>> 1; // 2^31

  // restrcit to between 0 and 2^32 - 1
  const int32bit = modulo(int, int2To32); // int modulo 2^32
  return int32bit;
}

function toSignedBitwiseInupt(val) {
  const int32bit = toUnsignedBitwiseInput

  // mimic signed integer overflow
  if (int32bit >= int2To31) {
    return int32bit - int2To32;
  }
  return int32bit;
}

For signed casts, this means the following:

1. Signed casting 45.5 will give $45$
2. Signed casting -45.5 will give $-45$
3. Signed casting NaN or Infinity will give $0$
4. Signed casting 0xFFFFFFFF (32 set bits) will give $-1$
5. Signed casting -0xFFFFFFFF will give will give $1$ (the sign is flipped)
6. Signed casting 0x7FFFFFFF will give $2,147,483,647$
7. Signed casting -0x7FFFFFFF will give $-2,147,483,647$
8. Signed casting -0x7FFFFFFF - 1 will give $-2,147,483,648$
9. Signed casting -0x7FFFFFFF - 2 will give $2,147,483,647$
10. Signed casting small integer values will give those values (e.g. $12$, $-12$, $240000$)

With this knowledge, we're ready to get "true" 32-bit integers in JavaScript.

Since all signed bitwise operators do our bitwise cast, we only need to use a bitwise operator that does nothing to cast to a signed bitwise operator. This idea was presented in asm.js[2] (the precursor to WASM), and the proposed operation was a bitwise or with $0$. We can use it similar to the following:

const someValue = getSomeNumericValue();
const signedInt = someValue|0; // cast to signed 32-bit int
const incInt = (someValue + 1)|0; // have to recast to signed 32-bit int
const overflow = (someValue + 0xFFFFFFFF)|0; // maintains twos complement overflow

Theoretically, we could use any signed bitwise operator so long as we don't modify the value (e.g. >> 0, & 0xFFFFFFFF, ^ 0). However, | 0 is both using a bitwise operator that's simple to understand, and using something somewhat standardized (asm.js) so there is at least a precedent. Because of that, I typically stick with | 0 when needing signed 32-bit integers.

We can apply the same methodology to get unsigned 32-bit integers. The only difference is that we have to use a different bitwise operator. Fortunately there is only one choice, the unsigned right shift (>>>). Because of that, I always use >>> 0 when I need an unsigned 32-bit integer.

Casting to BigInt

There's only one real way to cast a value to a BigInt, and that is to use the BigInt method.

BigInt operates very differntly than the other methods we've looked at, in that instead of returning NaN or being weirdly permissive, BigInt just throws on bad input. BigInt will take either an integer string (without any non-integer characters), or a number that doesn't have decimal places. Anything else will result in an exception.

Here's a demonstration:

const b1 = BigInt(23); // ok
const b2 = BigInt('23'); // ok
const b3 = BigInt('23.23'); // Error
const b4 = BigInt('23ab'); // Error
const b5 = BigInt(12.32); // Error
const b6 = BigInt(null); // Error
const b7 = BigInt({}); // Error
const b8 = BigInt([]); // Error

BigInt is the most straightforward way to convert something to an integer value. No weird quirks, and no funky return values.

Wrap Up

Often when people talk about weird JavaScript number behavior, they're really talking about floating point behavior. Issues like 0.1 + 0.2 !== 0.3 are really commonly quoted, but that applies to any floating point language.

Where I find there is more interest (and more issues) is when we get into JavaScript coersions and casts. Without proper knowledge, it's possible to get into sticky situations where stuff is breaking and you don't know why. This especially becomes true when trying to do more server/embedded/game programming in JavaScript.

A good example would be IP Subnetting, which requires operating on bitmasks (with 32-bit and 128-bit masks). Not properly understanding how numbers are cast to integers can cause a lot of issues - especially if you ever heard "JavaScript has 56-bit integers." Additionally, porting native libraries and code which rely on integer overflow can quickly lead to problems.

Also, always take care and consideration when casting values to numbers. Blindly doing Number.parseFlaot or Number.parseInt may work if you have a server catching non-numeric inputs (e.g. "123abc"), but be aware of the limitations. And don't be afraid of using the other conversion methods as needed.Sometimes what you need may look "ugly," but it's the only thing that works.

Bibliography

1. [1] "ECMAScript 2025 Langauge Specification" tc39. https://tc39.es/ecma262/multipage/abstract-operations.html#sec-toint32 (accessed Mar. 20, 2025).
2. [2] "asm.js Working Draft" Herman, David; Wagner, Luke; Zakai, Alon. http://asmjs.org/spec/latest/#introduction (accessed Mar. 20, 2025).