Modern web applications often need to store data directly in the user’s browser.

Simple browser storage options such as cookies, local storage, and session storage are useful for small amounts of data. However, they are not designed to manage large amounts of structured information.

This is where IndexedDB becomes useful.

IndexedDB is a built-in browser database that allows web applications to store structured data on the user’s device. It can store more complex information than simple key-value strings and supports features such as indexes, transactions, and asynchronous operations.

For example, a web application can use IndexedDB to store:

• User-created data
• Application settings
• Offline data
• Product information
• Cached application content
• Large collections of records

As a result, IndexedDB is useful for modern applications that need more advanced client-side storage.

In this article, we’ll explain what IndexedDB is, how it works, its main features, common use cases, and how it differs from cookies, local storage, and session storage.

---

What Is IndexedDB?

IndexedDB is a browser-based database that allows websites to store structured data locally.

Unlike local storage and session storage, IndexedDB is designed to work with larger and more complex datasets.

It is commonly used by web applications that need to store information directly in the browser.

For example, an application could store a user object like this:

{
  id: 1,
  name: "John",
  role: "Developer"
}

IndexedDB can store structured JavaScript data, including objects and arrays.

Therefore, developers do not need to manually convert every object into a JSON string before storing it in the same way they typically do with local storage.

---

Why Is IndexedDB Needed?

Local storage is useful for simple data.

For example:

localStorage.setItem("theme", "dark");

However, problems can appear when an application needs to manage many records.

Imagine an application that needs to store thousands of products:

Product 1
Product 2
Product 3
Product 4
...

Managing this type of structured data with local storage can become difficult.

IndexedDB provides a more database-like approach.

It allows applications to organize data into:

• Databases
• Object stores
• Records
• Indexes
• Transactions

As a result, developers can store and retrieve structured browser data more efficiently.

---

How Does IndexedDB Work?

The basic IndexedDB process looks like this:

Web Application → Open Database → Create Object Store → Add Data → Store Data in Browser → Retrieve Data When Needed

Let’s understand this step by step.

---

Step 1: The Application Opens a Database

First, the application opens an IndexedDB database.

For example:

const request = indexedDB.open("MyDatabase", 1);

In this example:

• MyDatabase is the database name.
• 1 is the database version.

The browser checks whether the database already exists.

If it does not exist, the application can create the database structure.

---

Step 2: The Application Creates an Object Store

An object store is similar to a table in a traditional database.

For example, an application might create a users object store.

Conceptually:

Database
   │
   ├── users
   ├── products
   └── orders

Each object store can contain multiple records.

For example:

users
   │
   ├── User 1
   ├── User 2
   └── User 3

The object store helps organize related information.

---

Step 3: The Application Stores Data

Once an object store exists, the application can add records.

For example:

const user = {
  id: 1,
  name: "John",
  role: "Developer"
};

This object can be stored inside IndexedDB.

Conceptually:

users
│
├── {
│     id: 1,
│     name: "John",
│     role: "Developer"
│   }

The browser stores this data locally on the user’s device.

---

Step 4: IndexedDB Uses Keys

IndexedDB uses keys to identify records.

For example:

Key: 1

Value:
{
  name: "John",
  role: "Developer"
}

The key allows the application to retrieve a specific record.

For example:

Get User → Key 1

The browser can then return the related record.

---

Step 5: The Application Retrieves Data

When the application needs the stored information, it can retrieve it from IndexedDB.

For example:

Web Application
      ↓
Request User ID 1
      ↓
IndexedDB
      ↓
Return User Data

As a result, the application can access previously stored data without automatically sending a request to the server.

---

IndexedDB Is Asynchronous

One of the most important things to understand about IndexedDB is that its API is asynchronous.

Database operations may take time.

For example, retrieving data should not unnecessarily freeze the web application’s user interface.

IndexedDB operations use requests and events.

Conceptually:

Application
    ↓
Request Data
    ↓
Browser Processes Request
    ↓
Operation Completes
    ↓
Application Receives Result

This approach helps applications continue running while database operations are processed.

---

A Simple IndexedDB Example

Here is a basic example of opening a database:

const request = indexedDB.open("MyDatabase", 1);

When the database is created or its version changes, the onupgradeneeded event can be used to create or update object stores.

For example:

request.onupgradeneeded = function (event) {
  const db = event.target.result;

  db.createObjectStore("users", {
    keyPath: "id"
  });
};

This creates an object store called:

users

The id property is used as the key for records.

---

Adding Data to IndexedDB

Suppose we have a user:

const user = {
  id: 1,
  name: "John",
  role: "Developer"
};

First, the application creates a transaction.

Then, it accesses the object store.

Conceptually:

const transaction = db.transaction(
  "users",
  "readwrite"
);

const store = transaction.objectStore("users");

store.add(user);

The record is then stored inside the browser database.

---

What Is an Object Store?

An object store is one of the main parts of IndexedDB.

It stores related records.

For example:

MyDatabase
│
├── users
│
├── products
│
└── orders

Each object store can contain different types of data.

For example, the users store might contain:

{
  id: 1,
  name: "John"
}

Meanwhile, the products store might contain:

{
  id: 101,
  name: "Laptop",
  price: 50000
}

This structure helps applications organize their browser data.

---

What Are Indexes in IndexedDB?

Indexes make it easier to search data using properties other than the primary key.

For example, imagine the following user:

{
  id: 1,
  name: "John",
  email: "john@example.com"
}

The primary key may be:

id

However, the application may also want to search users by email.

An index can support that type of lookup.

Conceptually:

users
│
├── Primary Key → id
│
└── Index → email

Indexes can make certain data retrieval operations more convenient.

---

What Are Transactions in IndexedDB?

IndexedDB uses transactions for database operations.

A transaction represents a group of database actions.

For example, an application may want to:

1. Update a product.
2. Update the user’s cart.
3. Save both changes.

Transactions help manage database operations in a controlled way.

IndexedDB supports different transaction modes, including:

• readonly
• readwrite

For example:

const transaction = db.transaction(
  "users",
  "readonly"
);

This transaction is intended for reading data.

A transaction using readwrite can modify data.

---

What Types of Data Can IndexedDB Store?

IndexedDB can store more than simple strings.

It can store structured JavaScript data such as:

• Objects
• Arrays
• Strings
• Numbers
• Dates
• Blobs and files in supported use cases

For example:

const product = {
  id: 101,
  name: "Laptop",
  price: 50000,
  features: [
    "16GB RAM",
    "512GB SSD"
  ]
};

This makes IndexedDB more flexible than simple browser storage systems that mainly work with string values.

---

Common Uses of IndexedDB

IndexedDB can be useful in many types of web applications.

---

1. Offline Web Applications

One of the most common uses of IndexedDB is offline functionality.

Suppose a user opens an application while connected to the internet.

The application can store important data locally.

Later, if the internet connection becomes unavailable, the application may still access previously stored information.

For example:

Internet Available
      ↓
Application Downloads Data
      ↓
IndexedDB Stores Data
      ↓
Internet Unavailable
      ↓
Application Reads Local Data

As a result, IndexedDB can support offline-first application experiences.

---

2. Storing Application Data

Web applications can store structured data locally.

For example:

• Notes
• Tasks
• Messages
• Drafts
• Product information

This can improve the application’s responsiveness because some data can be accessed locally.

---

3. Saving User Drafts

Imagine a user writing a long article.

The application can periodically save the draft in IndexedDB.

If the user accidentally refreshes the page, the application may be able to recover the locally stored draft.

For example:

User Types Content
      ↓
Application Saves Draft
      ↓
IndexedDB

This can improve the user experience.

---

4. Caching Application Data

Applications can store previously retrieved data in IndexedDB.

For example:

Server
   ↓
Application Receives Data
   ↓
IndexedDB Stores Data
   ↓
Future Request Uses Local Data

However, developers need to manage cached data carefully to avoid showing outdated information.

---

5. Progressive Web Applications

Progressive Web Applications, often called PWAs, may use browser storage technologies to support offline and app-like experiences.

IndexedDB can be useful for storing application data locally.

For example, a PWA might store:

• User-created content
• Previously loaded records
• Offline changes

The application can later synchronize changes with a server when appropriate.

---

IndexedDB vs Local Storage

Both IndexedDB and local storage store information in the browser.

However, they are designed for different purposes.

Feature	IndexedDB	Local Storage
Stores structured data	Yes	Primarily strings
Suitable for larger datasets	Yes	Better for small amounts
Asynchronous API	Yes	No, API is synchronous
Supports indexes	Yes	No
Supports transactions	Yes	No
Suitable for complex data	Yes	Limited
Automatically sent to server	No	No

Local storage is useful for simple information such as:

Theme = Dark
Language = English

IndexedDB is better suited to more complex application data.

---

IndexedDB vs Session Storage

Session storage is designed for temporary browser data.

IndexedDB can store data that persists beyond a single browser tab session, subject to browser storage policies and user actions.

Feature	IndexedDB	Session Storage
Stores structured data	Yes	Primarily strings
Suitable for complex records	Yes	Limited
Designed for larger datasets	Yes	Better for small temporary data
Usually remains after tab closes	Yes	Generally no
Shared as a database for the origin	Yes	Tab/session-specific
Automatically sent to server	No	No

Therefore, session storage is useful for temporary state, while IndexedDB is better suited to structured application data that may need to remain available longer.

---

IndexedDB vs Cookies

Cookies serve a different purpose.

Cookies are often used when information needs to be included with applicable HTTP requests.

Feature	IndexedDB	Cookies
Stored in browser	Yes	Yes
Automatically sent with requests	No	Yes, when applicable
Supports structured data	Yes	Limited to small values
Suitable for large datasets	Yes	No
Supports indexes	Yes	No
Common authentication use	Not typically	Yes
Accessible to JavaScript	Yes	Depends on HttpOnly

Therefore, IndexedDB is mainly used as client-side application storage rather than a replacement for authentication cookies.

---

Is IndexedDB Secure?

IndexedDB follows the browser’s same-origin security model.

In simple terms, data stored by one website is generally isolated from unrelated websites.

For example, data stored for:

example.com

is not normally available to:

anotherwebsite.com

However, IndexedDB should not be treated as a secure place for highly sensitive secrets.

JavaScript running within the same web origin can potentially access IndexedDB data.

Therefore, an application with an XSS vulnerability may expose data accessible to malicious scripts.

For this reason, developers should carefully consider what information is stored in browser-accessible storage.

---

Advantages of IndexedDB

IndexedDB provides several important benefits.

1. Stores Complex Data

It can store structured JavaScript data.

Therefore, applications can work with objects and collections more naturally.

---

2. Supports Larger Datasets

IndexedDB is designed for more substantial client-side data than simple key-value browser storage.

---

3. Works Asynchronously

Database operations are asynchronous.

As a result, applications can perform database work without relying on synchronous storage operations that may block the main thread.

---

4. Supports Indexes

Indexes help applications retrieve records based on specific properties.

---

5. Supports Offline Experiences

Applications can store data locally and use it when a network connection is unavailable.

---

Limitations of IndexedDB

IndexedDB also has some limitations.

1. More Complex Than Local Storage

The IndexedDB API requires more code and understanding.

For simple values, local storage may be easier.

---

2. Data Is Stored on the User’s Device

Browser storage can be cleared by the user or removed according to browser storage policies.

Therefore, IndexedDB should not be the only location for critical server-side data.

---

3. Security Requires Careful Planning

Data accessible to JavaScript can potentially be exposed if the application has a serious client-side security vulnerability.

Therefore, highly sensitive information should be handled carefully.

---

4. Browser Storage Limits Can Vary

Available storage can depend on the browser, device, user settings, and storage policies.

Therefore, applications should not assume unlimited browser storage.

---

When Should You Use IndexedDB?

IndexedDB is a good choice when your application needs to store:

• Structured records
• Offline application data
• Large collections of client-side information
• User-created drafts
• Cached application data
• Complex browser-based data

For example, it can be useful for applications such as:

• Note-taking applications
• Offline task managers
• Progressive Web Applications
• E-commerce applications
• Data-heavy dashboards

---

When Should You Not Use IndexedDB?

IndexedDB may not be necessary for simple data.

For example, if you only need to store:

Theme = Dark
Language = English

Local storage may be simpler.

You should also avoid treating IndexedDB as the only source of important business data that must be reliably available across devices.

For critical data, applications should normally use appropriate server-side storage and synchronization.

---

A Simple IndexedDB Data Flow

Here is a simplified example of how IndexedDB works:

Step 1: Application Opens the Database

Application
     ↓
Open IndexedDB

Step 2: Database Structure Is Created

Database
   ↓
Object Store Created

Step 3: Application Stores Data

JavaScript Object
      ↓
IndexedDB Object Store

Step 4: User Continues Using the Application

The application can read local data when needed.

Step 5: Application Retrieves Data

IndexedDB
      ↓
JavaScript
      ↓
Display Data

The complete process can be summarized as:

Open Database → Create Object Store → Store Structured Data → Retrieve Data → Update or Delete Data When Needed

---

IndexedDB Example in JavaScript

Here is a simplified example:

const request = indexedDB.open("MyDatabase", 1);

request.onupgradeneeded = function (event) {
  const db = event.target.result;

  db.createObjectStore("users", {
    keyPath: "id"
  });
};

request.onsuccess = function (event) {
  const db = event.target.result;

  const transaction = db.transaction(
    "users",
    "readwrite"
  );

  const store = transaction.objectStore("users");

  store.add({
    id: 1,
    name: "John",
    role: "Developer"
  });
};

This example demonstrates the basic flow:

1. Open the database.
2. Create an object store.
3. Create a transaction.
4. Add data.

Real-world applications may require additional error handling, database upgrades, and more advanced data management.

---

Best Practices for Using IndexedDB

Developers should follow several good practices.

1. Design Object Stores Carefully

Plan how your data should be organized before storing large amounts of information.

---

2. Use Indexes When Needed

Indexes can make it easier to retrieve data using commonly searched properties.

---

3. Handle Errors

Database operations can fail.

Therefore, applications should handle errors and unexpected situations.

---

4. Avoid Storing Highly Sensitive Secrets

Browser-accessible storage should be used carefully.

---

5. Manage Old Data

Applications should remove or update data that is no longer needed.

---

6. Keep Important Data on the Server

Critical information should not depend only on browser storage.

Instead, IndexedDB can be used as part of a broader application storage strategy.

---

Final Thoughts: How Does IndexedDB Work?

IndexedDB is a built-in browser database for storing structured client-side data.

It allows web applications to create databases, organize information into object stores, retrieve records, and use indexes for certain lookups.

Unlike local storage and session storage, IndexedDB is designed for more complex data and uses an asynchronous API.

The key idea is simple:

Web Application → Opens IndexedDB → Stores Structured Data → Browser Saves Data Locally → Application Retrieves Data When Needed

This makes IndexedDB particularly useful for modern web applications that need offline support or more advanced client-side data storage.

---

Conclusion

IndexedDB is a powerful browser storage technology for modern web applications.

It provides a database-like way to store structured information directly on the user’s device.

Developers can use it for offline applications, cached data, drafts, records, and other complex client-side data.

However, IndexedDB is more complex than local storage or session storage.

Therefore, developers should choose it when an application genuinely needs structured, persistent browser-based storage.

Understanding IndexedDB, cookies, local storage, and session storage can help developers choose the right storage solution for each situation.

The best option depends on the type of data, how long it needs to exist, whether the server needs access to it, and the application’s security requirements.