Web Storage APIs: Local Storage and Session Storage

After cookies solver server-driver state, the next challenge was clear:

How can applications store client-only data without sending it to the server every time?

This need gave rise to the Web Storage APIs – localStorage and sessionStorage. These APIs are simple, powerful, and frequently misused.

This chapter explains why they exist, how they work, and when (and when not) to use them.

Why Cookies Were Not Enough

Cookies are automatically sent with HTTP requests. That makes them ideal for:

• Authentication
• Session identification

But terrible for:

• UI state
• Preferences
• Client-side caching

Problem with cookies for client-only data:

• Every request becomes heavier
• Sensitive data exposure risk
• Size limitations
• Server involvement when none is needed

Modern web apps needed storage that belonged purely to the browser.

Introduction to Web Storage APIs

The Web Storage specification introduced two APIs:

• localStorage
• sessionStorage

Both provide:

• Simple key-value storage
• String-based values
• Synchronous APIs
• Origin-based isolation

Despite similar APIs, their lifetime and use cases differ significantly.

LocalStorage: Persistent Client-Side Storage

What Is LocalStorage?

localStorage allows websites to store data persistently in the browser.

Key characteristics:

• Data survives page reloads
• Data survives browser restarts
• Data exists until explicitly cleared

Example:

localStorage.setItem("theme", "dark")
const theme = localStorage.getItem("theme")

Use Cases for LocalStorage

LocalStorage is well-suited for:

• Theme preferences
• Language selection
• Feature flags
• Non-sensitive cached data

It is not suitable for:

• Authentication tokens
• Sensitive user information

Storage Limits and Behavior

• Typically ~5-10 MB per origin
• Shared across all tabs of the same origin
• Blocking (synchronous) API

Because it is synchronous, excessive usage can:

• Block the main thread
• Hurt performance

SessionStorage: Tab-Scoped Storage

What Is SessionStorage?

sessionStorage provides storage scoped to a single browser tab.

Key characteristics:

• Data survives page reloads
• Data is cleared when the tab is closed
• Isolated per tab, even for the same origin

Example:

sessionStorage.setItem("step", "2")

Use Cases for SessionStorage

SessionStorage is ideal for:

• Multi-step forms
• Temporary navigation state
• Wizard-style workflows

It prevents accidental data sharing across tabs.

LocalStorage vs SessionStorage

Choosing between them is mostly about lifetime and isolation, not size.

Security Consideration (Critical)

Both Web Storage APIs are:

• Fully accessible to JavaScript
• Vulnerable to XSS attacks

This means:

Any data stored here here can be stolen if your site has an XSS vulnerability.

Common Mistakes

• Storing JWTs in localStorage
• Storing user PII
• Assuming Web Storage is “secure”

Golden rule:

Never store secrets in Web Storage.

Serialization and Data Modeling

Web Storage only stores strings.

To store objects:

localStorage.setItem("user", JSON.stringify(user))

This creates challenges:

• Manual serialization
• No querying
• No indexing

When data grows complex, Web Storage stops scaling.

Performance and Design Trade-offs

Pros:

• Extremely simple API
• Zero server involvement
• Good for small data

Cons:

• Synchronous blocking
• Poor security
• No structure or queries

This is why modern applications often graduate to IndexedDB for serious data needs.

When Should You Use Web Storage?

Use Web Storage when:

• Data is small
• Data is non-sensitive
• Data is purely client-side
• Simplicity matters

Avoid Web Storage when:

• Security is critical
• Data is large or structured
• Offline-first behavior is required