How to Check for an Empty Object in JavaScript

By the end of this page, you will understand what an "empty object" means in JavaScript, how to test for it safely, and which approaches are most commonly used in real code. You will also see common mistakes, practical examples, and a small mini-project using data returned from an AJAX-style request.

In JavaScript, an object is considered empty when it has no own enumerable properties.

For example:

const user = {};

This object has no keys, so it is empty.

A common and reliable way to test this is:

Object.keys(user).length === 0

Object.keys(obj) returns an array of the object's own enumerable property names. If that array has length 0, the object has no such properties.

This matters because many APIs, AJAX requests, and configuration objects use objects to return data. Your program often needs to behave differently when:

• data exists
• data is missing
• the object is present but empty

For example, an API might return:

{}

instead of:

{ "name": "Ava" }

Knowing how to detect an empty object helps with:

• showing fallback UI
• skipping processing
• validating responses
• preventing runtime errors

One important detail: not every value that looks object-like should be treated the same. Arrays, null, and class instances are different cases. So in real programs, developers often combine an emptiness check with a type check.

Think of a JavaScript object as a backpack with labeled pockets.

const bag = {
  phone: true,
  keys: true
};

The property names (phone, keys) are the labeled pockets.

An empty object is like an empty backpack:

const emptyBag = {};

There are no labeled pockets inside.

So when you check:

Object.keys(emptyBag).length === 0

you are basically asking:

"How many labeled pockets does this backpack have?"

If the answer is 0, the backpack is empty.

The most common syntax is:

Object.keys(obj).length === 0

Basic example

const a = {};

console.log(Object.keys(a).length === 0); // true

Explanation:

• Object.keys(a) returns []
• [].length is 0
• so the result is true

Example with data

const user = { name: "Maya" };

console.log(Object.keys(user).length === 0); // false

Explanation:

• Object.keys(user) returns ["name"]
• its length is 1
• so the object is not empty

Safer helper function

In real projects, it is common to wrap the check in a function:

function isEmptyObject(value) {
  return value !== null &&
         typeof value === "object" &&
         !Array.isArray(value) &&
         Object.keys(value).length === 0;
}

console.log(isEmptyObject({})); // true
console.log(isEmptyObject({ id: 1 })); // false
console.log(isEmptyObject(null)); // false
console.log(isEmptyObject([])); // false

This helps avoid treating null or arrays as plain empty objects.

Older loop-based approach

function isEmptyObject(obj) {
  for (const key in obj) {
    if (Object.hasOwn(obj, key)) {
      return false;
    }
  }
  return true;
}

This checks whether the object has any own properties. If it finds one, it returns false. Otherwise, it returns true.

Consider this example:

const response = {};

if (Object.keys(response).length === 0) {
  console.log("Empty object");
} else {
  console.log("Has data");
}

Step by step:

1. response is assigned an empty object:

   {}
   

2. Object.keys(response) runs.

   Because response has no own enumerable properties, the result is:

   []
   

3. .length is checked.

   [].length === 0
   

   This becomes:

   0 === 0
   

4. The condition is true, so JavaScript enters the first branch:

   console.log("Empty object");
   

5. Output:

Empty object

Now compare with:

const response = { status: "ok" };

Then:

• Object.keys(response) becomes ["status"]
• .length becomes 1
• 1 === 0 is false
• the else branch runs

Checking for empty objects is common in many practical situations.

API and AJAX responses

const response = {};

if (Object.keys(response).length === 0) {
  console.log("No data returned");
}

Useful when an endpoint returns an empty result instead of null or an error.

Form validation errors

Some apps store validation errors in an object:

const errors = {};

if (Object.keys(errors).length === 0) {
  console.log("Form is valid");
}

If there are no keys, there are no validation messages.

Filter objects

An app may build a search filter object dynamically:

const filters = {};

if (Object.keys(filters).length === 0) {
  console.log("No filters selected");
}

Configuration objects

const options = {};

if (Object.keys(options).length === 0) {
  console.log("Using default settings");
}

State management

In frontend apps, an object may represent loaded data:

const cache = {};

if (Object.keys(cache).length === 0) {
  console.log("Cache is empty");
}

In real codebases, developers usually do more than just check Object.keys(obj).length === 0.

Guard clauses

A guard clause exits early when data is empty:

function renderProfile(profile) {
  if (Object.keys(profile).length === 0) {
    return "No profile data available";
  }

  return `Hello, ${profile.name}`;
}

This keeps the rest of the function simpler.

Validation before processing

function processSettings(settings) {
  if (!settings || Object.keys(settings).length === 0) {
    throw new Error("Settings object is empty");
  }

  // continue processing
}

Defensive type checking

function isPlainEmptyObject(value) {
  return value !== null &&
         typeof value === "object" &&
         !Array.isArray(value) &&
         Object.keys(value).length === 0;
}

This avoids accidental matches with arrays.

Conditional rendering in frontend code

function showUserPanel(user) {
  if (Object.keys(user).length === 0) {
    return "Loading or no user found";
  }

  return user.name;
}

Error handling with remote data

function handleApiResponse(data) {
  if (!data || Object.keys(data).length === 0) {
    console.error("API returned no usable data");
    return;
  }

  console.log("Process data here");
}

A common pattern is: validate first, then continue.

1. Comparing objects directly

This does not work:

const a = {};

console.log(a === {}); // false

Why?

Objects are compared by reference, not by content. These are two different object instances.

Avoid this by using:

Object.keys(a).length === 0

2. Forgetting about null

Broken example:

const value = null;
console.log(Object.keys(value).length === 0);

This throws an error because Object.keys expects an object-like value.

Safer version:

const value = null;
const isEmpty = value !== null && typeof value === "object" && Object.keys(value).length === 0;

3. Treating arrays like plain objects

console.log(Object.keys([]).length === 0); // true

This may be technically true for an empty array, but an array is not the same as a plain object.

If you only want plain objects:

!Array.isArray(value)

4. Ignoring inherited properties in for...in

Broken example:

function isEmpty(obj) {
  for (const key in obj) {
    return false;
  }
  return true;
}

This can be misleading because for...in also sees inherited enumerable properties.

Better:

function isEmpty(obj) {
  for (const key in obj) {
    if (Object.hasOwn(obj, key)) {
      return false;
    }
  }
  return true;
}

5. Assuming all objects should be checked the same way

Some objects come from classes, libraries, or built-in types like Date or Map. A plain object emptiness check may not match your actual intent.

Always ask:

• Is this a plain object?
• Could it be null?
• Could it be an array?
• Do I care about own properties only?

Common ways to test emptiness

Object.keys vs for...in

Plain object vs array

// Most common check
Object.keys(obj).length === 0

Safe plain-object check

function isEmptyObject(value) {
  return value !== null &&
         typeof value === "object" &&
         !Array.isArray(value) &&
         Object.keys(value).length === 0;
}

Rules to remember

• An empty object has no own enumerable properties.
• obj === {} does not test emptiness.
• null must be checked before Object.keys.
• Arrays are objects in JavaScript, but usually should not be treated as plain objects.
• Object.keys(obj) returns an array of property names.

Useful patterns

if (Object.keys(data).length === 0) {
  // handle empty object
}

if (!value || Object.keys(value).length === 0) {
  // handle missing or empty data
}

Be careful: the second pattern also matches other falsy values such as null.

Avoid

obj === {}
JSON.stringify(obj) === "{}" // usually not the best choice

Alternative loop

function isEmptyObject(obj) {
  for (const key in obj) {
    if (Object.hasOwn(obj, key)) {
      return false;
    }
  }
  return true;
}

How do I check if a JavaScript object is empty?

Use:

Object.keys(obj).length === 0

This is the most common modern approach for plain objects.

Why does obj === {} return false?

Because objects are compared by reference, not by their contents. Two separate object literals are different objects.

Should I use Object.keys or for...in?

Usually Object.keys is simpler and clearer. Use for...in only if you need custom iteration logic.

Does this work for arrays?

Object.keys([]).length === 0 returns true for an empty array, but arrays are not plain objects. If you need to exclude arrays, add !Array.isArray(value).

What happens with null?

Object.keys(null) throws an error. Check for null first.

Is JSON.stringify(obj) === "{}" a good way to check?

It works in some simple cases, but it is less clear and usually not the preferred approach.

How do I check for an empty object from an API response safely?

Use a defensive helper:

function isEmptyObject(value) {
  return value !== null &&
         typeof value === "object" &&
         !Array.isArray(value) &&
         Object.keys(value).length === 0;
}

• JavaScript objects — You need to understand how objects store key-value pairs before checking whether they are empty.
• Object.keys() — This method is the most common tool for getting an object's own keys.
• Arrays in JavaScript — Arrays are also objects, so it is important to know how they differ from plain objects.
• typeof operator — Useful for basic type checks when validating data before testing emptiness.
• null in JavaScript — null is a common edge case because it behaves differently from normal objects.
• for...in loop — An alternative way to inspect object properties.
• Own vs inherited properties — Important when deciding whether a property should count during an emptiness check.
• Guard clauses — A practical pattern for exiting early when an object is empty or invalid.