Types, Values & Conversions

A base-10 integer is just a sequence of digits. JavaScript also recognizes hexadecimal (0x), and, since ES6, binary (0b) and octal (0o) integer literals, plus floating-point literals with a decimal point and/or exponential notation:

Underscores may be used inside a numeric literal purely as a visual separator — they carry no meaning and do not affect the value:

Because the IEEE-754 double format exactly represents all integers between -(253 - 1) and 253 - 1, the Number object exposes that boundary directly:

Integers larger than Number.MAX_SAFE_INTEGER can silently lose precision in their trailing digits. Because the underlying format is binary, decimal fractions like 0.1 cannot be represented exactly either, which is the classic source of floating-point surprises:

Arithmetic never throws on overflow, underflow, or division by zero — overflow produces Infinity/-Infinity, underflow produces 0/-0, and 0/0 produces NaN. If floating-point approximation is a problem (financial calculations are the classic case), work with scaled integers — for example, manipulate money as integer cents rather than fractional dollars — or reach for BigInt, below.

BigInt (ES2020) is a separate numeric type for arbitrary-precision integers — values that can have thousands or even millions of digits, not just the ones that fit safely in a double. A BigInt literal is a string of digits with a trailing lowercase n:

The standard arithmetic operators (+ - * / % **) all work on BigInt values, except that division truncates toward zero rather than producing a fraction:

BigInt and regular Number operands cannot be mixed in arithmetic (1n + 1 throws a TypeError) — neither type is strictly more general than the other, since BigInt covers arbitrarily large magnitudes but only integers, while Number covers non-integers but is capped at 64 bits of precision. Comparison operators, however, do accept mixed operands: 1 < 2n and 0 == 0n are both true, though 0 === 0n is false because === also checks the type. BigInt is not suitable for cryptography (implementations make no attempt to prevent timing attacks), and none of the Math object’s functions accept BigInt operands.

A string literal is delimited by single quotes, double quotes, or (since ES6) backticks. Double quotes may appear unescaped inside a single-quoted string and vice versa:

Backtick-delimited strings are template literals, covered below; beyond allowing embedded expressions, they also let a string literal span multiple lines with the line breaks included verbatim, which single- and double-quoted strings do not (those need an escaped \n for a literal newline, or a trailing backslash to merely continue the literal onto the next source line without inserting one).

Strings are immutable: there is no way to alter the character at a given index in place. Every string method that looks like it modifies a string (toUpperCase(), replace(), trim(), …​) actually returns a new string, leaving the original untouched:

Under the hood, JavaScript strings use the UTF-16 encoding: each element of a string is an unsigned 16-bit value, and most common characters (the Unicode "basic multilingual plane") occupy exactly one such element. A character outside that plane — most emoji, for instance — is represented as a surrogate pair of two 16-bit elements, so "😀".length is 2 even though it displays as a single character. Most string methods operate on these raw 16-bit elements and do not treat surrogate pairs specially; since ES6, however, strings are iterable, and iterating with for…​of or the spread operator (…​) walks actual Unicode characters rather than raw 16-bit values.

A template literal can embed arbitrary JavaScript expressions between ${ and }; each expression is evaluated, converted to a string, and spliced into the result:

A template literal may contain any number of expressions and span any number of lines with no special escaping. When a function name immediately precedes the opening backtick, the literal becomes a tagged template literal: instead of producing a string directly, the literal’s pieces are passed to that function (the "tag"), and the tagged template literal’s value is whatever the tag function returns. This is how libraries implement things like automatic HTML/SQL escaping or CSS-in-JS — the tag intercepts every interpolated value before it reaches the final string:

JavaScript ships one built-in tag, String.raw(), which returns the literal text without processing backslash escapes:

The loose equality operator == performs these implicit conversions before comparing; the strict equality operator === never converts and requires both the type and the value to match. Because ==’s conversion rules are a frequent source of surprising results, `=== (and its counterpart !==) is almost always the right operator to reach for:

Note that convertibility does not imply equality: undefined converts to false in a boolean context, but undefined == false is itself false, because == never coerces its operands to booleans — only if and similar constructs do that conversion.

To convert deliberately rather than relying on an operator’s implicit behavior, call the Boolean(), Number(), or String() functions directly (without new — calling them as constructors produces rarely-useful wrapper objects instead of primitives):

A few operator-based idioms achieve the same conversions implicitly and show up often in existing code:

For parsing a numeric value out of a larger string, the global parseInt() and parseFloat() functions are more forgiving than Number(): they skip leading whitespace, parse as many valid numeric characters as they can, and ignore any trailing text, rather than producing NaN for the whole string: