How to check if a key exists in an object in JavaScript

1Object.hasOwnRecommended

Object.hasOwn(obj, key) (ES2022) asks whether the object has the key as its own property, meaning one set on the object itself rather than inherited from its prototype. For plain data like parsed JSON, config and records, that is the question you mean. It is a static function, so it works on every object, including ones with no prototype.

const config = { host: "localhost", port: 8080, debug: false };

console.log(Object.hasOwn(config, "port"));
console.log(Object.hasOwn(config, "timeout"));
console.log(!Object.hasOwn(config, "timeout"));

// hasOwn looks at KEYS only: "localhost" is a value, not a key
console.log(Object.hasOwn(config, "localhost"));
console.log(Object.values(config).includes("localhost"));

// A key from a variable works the same way
const key = "debug";
console.log(Object.hasOwn(config, key));

Prints true, false, true, false, true, true. The last line is the one people get wrong with other checks: debug holds false, and hasOwn still says the key is there, because it never looks at the value. To search values instead of keys, use Object.values(obj).includes(value), which scans every entry.

2The in operator

key in obj is the other built-in check. The difference from hasOwn is that in walks the prototype chain, so it also finds inherited keys. On a plain object that means every method from Object.prototype, such as toString, counts as present.

const config = { host: "localhost", port: 8080 };

console.log("port" in config);
console.log("timeout" in config);

// `in` also walks the prototype chain...
console.log("toString" in config);
console.log(Object.hasOwn(config, "toString"));

// ...which is what you want for class instances
class User {
  constructor(name) {
    this.name = name;
  }
  greet() {
    return `Hi, ${this.name}`;
  }
}
const ada = new User("Ada");
console.log("greet" in ada, Object.hasOwn(ada, "greet"));
console.log("name" in ada, Object.hasOwn(ada, "name"));

"toString" in config prints true for an object that never defined it, and the class instance prints true false for greet: methods live on User.prototype, not on ada. So pick by intent. Use hasOwn for keys in data, and in for "can I call or read this on the object?", which is also how you feature-check an object's capabilities. in needs an object on the right; "a" in "abc" throws a TypeError.

3The trap: obj.key !== undefined

The most common home-made check is obj.key !== undefined (or its older form, typeof obj.key !== "undefined"). It tests the value, not the key, so it can't tell a missing key from a key set to undefined. A plain if (obj.key) is worse: every falsy value, including 0 and "", reads as missing.

const settings = { retries: 0, name: "", proxy: null, timeout: undefined };

for (const key of ["retries", "name", "proxy", "timeout", "missing"]) {
  const exists = Object.hasOwn(settings, key);
  const notUndefined = settings[key] !== undefined;
  const truthy = Boolean(settings[key]);
  console.log(
    key.padEnd(8),
    "exists:", String(exists).padEnd(5),
    "!== undefined:", String(notUndefined).padEnd(5),
    "truthy:", truthy
  );
}

Read the timeout row: exists: true but !== undefined: false, so the value check reports a key that is really there as missing, exactly like the missing row. The truthy column is false for all five rows. If you only care whether there is a usable value, !== undefined is fine. If you need to know the key exists, for example to tell "explicitly set to undefined" apart from "never set", use hasOwn or in.

4hasOwnProperty in older code

Before ES2022 the standard answer was obj.hasOwnProperty(key). It gives the same result as Object.hasOwn on ordinary objects, but it is a method the object inherits, so it breaks whenever the object doesn't have it: objects made with Object.create(null), or data that has its own key called hasOwnProperty.

// An object with no prototype, e.g. a lookup table built with Object.create(null)
const dict = Object.create(null);
dict.apple = 3;

console.log(Object.hasOwn(dict, "apple"));
console.log("hasOwnProperty" in dict);

try {
  dict.hasOwnProperty("apple");
} catch (err) {
  console.log(err.constructor.name + ":", err.message);
}

// The pre-2022 workaround borrows the method from Object.prototype
console.log(Object.prototype.hasOwnProperty.call(dict, "apple"));

// A key named "hasOwnProperty" also breaks the method form
const form = { hasOwnProperty: "yes" };
console.log(Object.hasOwn(form, "hasOwnProperty"));

The method call fails with TypeError: dict.hasOwnProperty is not a function, while Object.hasOwn and the Object.prototype.hasOwnProperty.call(obj, key) workaround both print true. That workaround is what linters (ESLint's no-prototype-builtins) used to require. Object.hasOwn is the same thing with a shorter name, and it is available in every current browser and Node version, so new code has no reason to use the method form.

5Map.has for Map keys

If the data is a Map rather than a plain object, the check is built in: map.has(key). A Map has no prototype keys to trip over, and its keys can be any value, not just strings. The same undefined trap applies to map.get(key), so use has for existence.

const ports = new Map([
  ["http", 80],
  ["https", 443],
  ["legacy", undefined],
]);

console.log(ports.has("https"));
console.log(ports.has("ftp"));

// get() returns undefined for a missing key AND for a stored undefined
console.log(ports.get("ftp"), ports.get("legacy"));
console.log(ports.has("legacy"));

// Keys can be any value, compared by identity (not by string)
const ids = new Map([[1, "one"]]);
console.log(ids.has(1), ids.has("1"));

// Plain objects turn every key into a string
const obj = { 1: "one" };
console.log(Object.hasOwn(obj, 1), Object.hasOwn(obj, "1"));

get prints undefined undefined for the missing ftp and the stored legacy, while has("legacy") prints true. The last two lines show the other difference: the Map keeps 1 and "1" apart (true false), but a plain object converts keys to strings, so both checks print true true. Reach for a Map when keys come from user input or aren't strings.

6Which should you use?

7Nested keys with optional chaining

For a key several levels down, the problem is the levels in between: reading a property of undefined throws. Optional chaining, a?.b?.c, stops at the first null or undefined and returns undefined instead of throwing. Pair it with ?? for a default, or with hasOwn when you need to know that the final key exists.

const data = {
  db: { host: "localhost", port: 0 },
  cache: null,
};

// Plain access throws once a level is missing
try {
  console.log(data.queue.size);
} catch (err) {
  console.log(err.constructor.name + ":", err.message);
}

// ?. stops at the first null or undefined and returns undefined
console.log(data.db?.port);
console.log(data.queue?.size);
console.log(data.cache?.ttl);

// ?? supplies a default, but only for null/undefined, so port 0 survives
console.log(data.db?.port ?? 5432);
console.log(data.db?.port || 5432);

// To check that the nested KEY exists, combine ?. with hasOwn or in
console.log(Object.hasOwn(data.db ?? {}, "port"));
console.log("ttl" in (data.cache ?? {}));

The plain read fails with TypeError: Cannot read properties of undefined (reading 'size'); the ?. versions print 0, undefined, undefined. Note ?? 5432 keeps the real port 0, while || 5432 replaces it with 5432, the falsy trap from section 3 again. Optional chaining shares the undefined limit too: data.db?.port can't tell a missing port from one set to undefined, which is why the last two lines hand the parent (or an empty-object fallback) to hasOwn and in.