What Are JavaScript's Data Types?

JavaScript has seven types in the language. Five of them are primitives, which are string, number, boolean, symbol, and bigint. The sixth type is the special one for values that were never assigned. The seventh type is object, and everything that is not a primitive is an object. That includes arrays, functions, dates, regular expressions, and instances of your own classes.

const samples = [
  { label: 'number', value: 42 },
  { label: 'string', value: '42' },
  { label: 'boolean', value: true },
  { label: 'null', value: null },
  { label: 'missing', value: undefined },
  { label: 'bigint', value: 10n },
  { label: 'symbol', value: Symbol('id') },
  { label: 'object', value: { a: 1 } },
  { label: 'array', value: [1, 2, 3] },
  { label: 'function', value: function () {} },
];

for (const sample of samples) {
  console.log(sample.label + ' -> ' + typeof sample.value);
}

The typeof operator is the quick answer, and it is also the most misunderstood one. It returns function for functions, and it returns object for everything else that is not a primitive. That means a plain object and an array both report object. The null value is of the object type as well, so it also reports object. For a value that was never assigned, typeof returns the name of that special type as a piece of text.

There are two better tools when you need to be precise. The instanceof operator asks whether a value sits on a particular chain of prototypes, and that is the right test for your own classes. For anything that is built in, Object.prototype.toString.call(value) gives you the internal class name, so it tells an array apart from a plain object, and a date apart from a regular expression. The constructor property is a third option, but it can be faked easily with a plain object, so it is the least reliable of the three.

One point is worth saying out loud. There is no single primitive wrapper in JavaScript the way there is in Java. Numbers, strings, and booleans do have methods, but those methods live on the prototype of the wrapper object and not on the value itself.

The seven types in the language are the type for values that were never assigned, plus boolean, number, string, symbol, bigint, and object. The typeof operator can return eight different pieces of text, because it treats functions in a special way. Functions are objects in the language, with the extra ability to be called, but typeof reports the text function for them.

So the mismatch runs in two directions, and it is worth being able to explain both of them.

The first direction is that typeof has a dedicated result for functions, and that result is not one of the seven types. This is genuinely useful in practice, because checking whether something is a function is one of the most common type checks that you write.

The second direction is that typeof has no dedicated result for null, even though the language gives null its own special meaning. Since null is of the object type, and typeof cannot tell one object from another, it reports object for it. That is the source of the classic bug where a typeof check on null appears to succeed.

There is also a historical wrinkle in the other direction. typeof reports the name of the special type for a value that was never assigned, and it does the same for a variable that was never declared at all. That is a real convenience, because typeof on a name that does not exist is safe, while reading that name directly throws a ReferenceError. That safety is exactly the trick that people use to check whether a global exists without crashing the page.

If somebody asks why the specification never fixed the behaviour of null, the answer is backwards compatibility. The quirk has been observed for decades, and changing it would break working code on the web.

They answer three different questions. typeof asks what kind of value this is in broad groups. instanceof asks whether this value inherits from a particular prototype. Object.prototype.toString asks what the internal class of the value is.

class Animal {}
class Dog extends Animal {}

const dog = new Dog();

console.log(typeof dog);                          // 'object'
console.log(dog instanceof Dog);                   // true
console.log(dog instanceof Animal);                // true
console.log(Object.prototype.toString.call(dog));  // '[object Object]'
console.log(Object.prototype.toString.call([]));   // '[object Array]'
console.log(Object.prototype.toString.call(null)); // '[object Null]'

The differences show up straight away. typeof on a class instance gives object, which tells you almost nothing. dog instanceof Dog is true, and because Dog extends Animal, dog instanceof Animal is true as well, which is exactly the behaviour you want from a type check. The toString approach reports the internal class, so it separates arrays, dates, and regular expressions from plain objects, but it cannot tell you which of your own classes an instance belongs to unless you override the method yourself.

So reach for instanceof when the question is about your own types and about inheritance. Reach for the toString tag when the question is about built-in container types, because it survives across separate browser windows, which matters if you handle data that came from an iframe. Reach for typeof when you only need to separate primitives from objects, or when you want a check that is safe on a name that might not exist.

There are two caveats. instanceof fails across separate browser windows, because each window has its own Array and its own class objects, so an array from an iframe is not an instance of your Array. And it can be defeated by anything that sets a prototype on the prototype property, which is why a hostile payload can pass a naive instanceof check.