jsguides

Number.isFinite() 

Number.isFinite(value)
Returns Boolean· Updated June 2, 2026· Number
javascriptnumberfinitetype-check

The Number.isFinite() method determines whether the passed value is a finite number. In JavaScript, finite numbers are all values that are not Infinity, -Infinity, or NaN. This method is part of the ES6 specification and provides a more reliable way to check for finite numbers compared to the global isFinite() function.

Syntax

Number.isFinite(value)

Parameters

ParameterTypeDescription
valueanyThe value to check for finiteness

Return Value

Returns true if the value is a finite number (a regular number that is not Infinity, -Infinity, or NaN). Returns false for all non-finite numbers and non-number types.

Examples

Basic Usage

Number.isFinite(42);           // true
Number.isFinite(3.14159);     // true
Number.isFinite(-10);         // true
Number.isFinite(0);            // true

The basic cases are straightforward — integers, floats, zero, and negative numbers all return true. The method becomes useful when you encounter values that are not ordinary numbers: Infinity, -Infinity, and NaN. These edge cases pass the global isFinite() check in some contexts but fail Number.isFinite() for good reason.

Non-Finite Numbers

Number.isFinite(Infinity);     // false
Number.isFinite(-Infinity);    // false
Number.isFinite(NaN);          // false

Infinity and NaN are the obvious non-finite values. But Number.isFinite() draws a harder line than the global isFinite() — it rejects every non-number type outright, even values that could be coerced to a finite number. This stricter behavior is what sets it apart.

Edge cases: non-number types

One of the key differences between Number.isFinite() and the global isFinite() is how it handles non-number types:

// These all return false - they are not finite numbers
Number.isFinite('42');         // false (string)
Number.isFinite('hello');      // false (string)
Number.isFinite(undefined);    // false
Number.isFinite(null);         // false
Number.isFinite(true);         // false (boolean)
Number.isFinite({});           // false (object)
Number.isFinite([]);           // false (array)

The edge-case examples prove that strings, objects, and other non-numbers are always rejected — no coercion. This makes Number.isFinite() a reliable guard in validation logic. The next example shows a typical pattern: early-return when input is not a finite number.

Common Patterns

Input Validation

When validating user input that should be a finite number:

function processValue(input) {
  if (!Number.isFinite(input)) {
    return 'Invalid: not a finite number';
  }
  return input * 2;
}

processValue(10);       // 20
processValue(Infinity); // 'Invalid: not a finite number'
processValue('hello'); // 'Invalid: not a finite number'

The guard pattern above rejects non-finite values at the function boundary. A related but distinct problem is division safety: even if both operands are finite, dividing by zero produces Infinity instead of throwing. Wrapping the operation in a finiteness check catches that case before the return value escapes.

Preventing division by zero issues

function calculateRate(total, count) {
  if (!Number.isFinite(total) || !Number.isFinite(count)) {
    return NaN;
  }
  if (count === 0) {
    return Infinity;
  }
  return total / count;
}

calculateRate(100, 0);  // Infinity
calculateRate(100, 4); // 25
calculateRate(NaN, 4); // NaN

The division guard uses Number.isFinite() on both operands to reject edge cases early. If you wrote the same guard with the global isFinite(), you would get different results — and likely bugs — because the global version coerces its argument first.

Difference from Global isFinite()

The global isFinite() coerces its argument to a number before checking:

// Global isFinite() coerces values
isFinite('42');         // true (coerced to 42)
isFinite('hello');      // false (coerced to NaN)
Number.isFinite('42');  // false (no coercion, string is not a number)

// The key difference is with null and empty strings
isFinite(null);         // true (null becomes 0)
Number.isFinite(null);  // false

isFinite('');           // true (empty string becomes 0)
Number.isFinite('');    // false

The coercion difference is the core reason to prefer Number.isFinite() — it never surprises you. A practical way to see this advantage is in array filtering: passing Number.isFinite directly to .filter() strips out every non-finite value in one call, which the global isFinite cannot do without an intermediate mapping step.

Data processing pipeline

const values = [10, 20, Infinity, 30, NaN, 40, -Infinity, 50];

const finiteValues = values.filter(Number.isFinite);
// [10, 20, 30, 40, 50]

const sum = finiteValues.reduce((a, b) => a + b, 0);
// 150

Number.isFinite() vs global isFinite()

The global isFinite() function coerces its argument with Number() before testing, which means isFinite("42") is true and isFinite(null) is true. Number.isFinite() does not coerce — it returns false for any non-number type, including strings that happen to look like numbers. Prefer Number.isFinite() when writing type-safe code, since coercion can hide bugs where the wrong type is passed in.

When Infinity appears in calculations

JavaScript produces Infinity or -Infinity rather than throwing when arithmetic overflows or divides by zero. Division by zero (1 / 0) returns Infinity, not an error. This means a calculation can silently produce infinite values that then propagate through further arithmetic. Checking with Number.isFinite() at validation boundaries — input normalization, after division, after user-entered values are parsed — prevents infinite values from spreading into downstream calculations.

Combining with Number.isNaN()

Number.isFinite() returns false for both NaN and Infinity. If you need to distinguish between the two:

function classify(n) {
  if (!Number.isFinite(n)) {
    if (Number.isNaN(n)) return "NaN";
    return n > 0 ? "+Infinity" : "-Infinity";
  }
  return "finite";
}

A simpler test for “is this a safe, usable number” is Number.isFinite(n) && !Number.isNaN(n), though Number.isFinite() alone already excludes NaN — the two checks are not redundant when you need to produce different error messages for the two cases.

See Also