JavaScript `typeof` Operator

The `typeof` operator evaluates an expression and returns a string identifying its JavaScript type category. It is useful for runtime type checks, but historical behaviors such as `typeof null` and the treatment of functions require special attention.

`typeof value` produces a string such as `"string"`, `"number"`, `"boolean"`, `"undefined"`, `"object"`, `"function"`, `"symbol"`, or `"bigint"`. The result describes the runtime category rather than the exact constructor or class of the value.

Primitive values have predictable results: strings produce `"string"`, numbers produce `"number"`, booleans produce `"boolean"`, `undefined` produces `"undefined"`, symbols produce `"symbol"`, and BigInts produce `"bigint"`.

Objects normally produce `"object"`, including arrays, dates, regular expressions, and plain objects. A major historical edge case is that `typeof null` is `"object"`, so `typeof` alone cannot distinguish `null` from other objects.

Functions are another special case: `typeof` returns `"function"` for callable function values. This means `typeof` can distinguish functions from ordinary objects, although it does not provide the function's specific kind or class.

For undeclared identifiers, `typeof` has special behavior: `typeof missingName` returns `"undefined"` instead of throwing a `ReferenceError`. This makes it useful for certain existence checks, but it should not be confused with checking whether a declared variable currently contains `undefined`.

Key points

• `typeof` returns a type-category string.
• `typeof null` is `"object"` because of a historical language behavior.
• Arrays and most other objects return `"object"`.
• Callable functions return `"function"`.
• BigInts and Symbols return `"bigint"` and `"symbol"` respectively.
• `typeof` can safely inspect an undeclared identifier without a `ReferenceError`.

Interview questions

What does the JavaScript `typeof` operator do?

It evaluates an expression and returns a string representing the value's runtime type category. Common results include `"string"`, `"number"`, `"boolean"`, `"undefined"`, and `"object"`. Functions produce `"function"`, while Symbols and BigInts produce their corresponding categories. It is primarily a coarse-grained runtime type check.

Why does `typeof null` return `"object"`?

This behavior is a long-standing historical quirk of JavaScript. `null` represents the intentional absence of an object value, but the language's `typeof` behavior preserves the older result of `"object"`. Therefore, `typeof value === "object"` is not sufficient to establish that a value is a non-null object. A common guard is `value !== null && typeof value === "object"`.

What does `typeof` return for arrays and functions?

Arrays return `"object"` because they are objects in JavaScript's runtime model. Functions are treated specially and return `"function"`. Consequently, `typeof value === "object"` cannot identify arrays specifically, and `typeof value === "function"` can identify callable function values at a coarse level. For arrays, `Array.isArray(value)` is the more appropriate test.

What happens when `typeof` is used on an undeclared identifier?

Using `typeof` on an undeclared identifier returns `"undefined"` rather than throwing a `ReferenceError`. This special behavior is useful when code needs to test whether a global name exists. It differs from directly evaluating the same undeclared identifier, which normally causes a `ReferenceError`. The result should still be distinguished from a declared variable whose value happens to be `undefined`.

Why isn't `typeof` enough for precise type checking in a frontend application?

`typeof` deliberately provides broad categories rather than complete structural information. It cannot distinguish arrays from ordinary objects, and it cannot identify specific classes or custom object types by itself. `null` also shares the `"object"` result with many objects. Depending on the requirement, more precise mechanisms such as `Array.isArray()`, `instanceof`, property checks, or explicit validation may be appropriate.