Ticker

6/recent/ticker-posts

💾 localStorage & sessionStorage – What Devs Actually Use in Real Apps

💾 localStorage & sessionStorage – What Devs Actually Use in Real Apps

You build something clean… maybe a theme toggle, maybe a login flow.

Then you refresh.

💀 Everything resets.

Yeah — that’s the moment you realize you need browser storage.

Not a database. Not Redux. Just something simple that remembers stuff on the client.

That’s where localStorage and sessionStorage come in. Super simple APIs… but if you use them wrong, they will bite you later.

Let’s break it down properly.

⚡ What’s the Real Difference?

At surface level, everyone says:

  • localStorage → persists forever
  • sessionStorage → dies when tab closes

That’s true… but here’s the more practical way to think about it:

👉 localStorage = “remember this across visits”
👉 sessionStorage = “remember this only for this tab session”

Also important:

  • Both are synchronous (this matters for performance)
  • Both only store strings
  • Both are scoped per domain

🔎 Basic Usage (Nothing Fancy)

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

const theme = localStorage.getItem("theme");

localStorage.removeItem("theme");

localStorage.clear();

Same exact API for sessionStorage:

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

No magic here.

🔥 Real Use Case: Theme Persistence

This is probably the most legit use of localStorage.

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

// apply on load
const savedTheme = localStorage.getItem("theme");

if (savedTheme) {
  document.documentElement.dataset.theme = savedTheme;
}

Simple. Effective. No backend needed.

📦 Storing Objects (Where People Mess Up)

You can’t store objects directly.

You have to do this:

const user = { name: "John", role: "admin" };

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

And when reading:

const user = JSON.parse(localStorage.getItem("user"));

If you skip this step… things silently break later.

💡 Real Developer Insight

Here’s where things get real.

A lot of devs start using localStorage for everything:

  • auth tokens
  • API responses
  • user data

And it works… until it doesn’t.

⚠️ The big one: Security

Anything in localStorage is accessible via JavaScript.

So if your app has an XSS vulnerability, your data is exposed.

👉 That’s why in production apps:

  • Auth tokens → usually stored in HTTP-only cookies, not localStorage
  • Sensitive data → never stored here

⚠️ The subtle one: Performance

localStorage is blocking (synchronous).

Meaning:

If you read/write large data frequently → it can slow down your app.

Not noticeable at first… but in bigger apps, it adds up.

⚠️ Common Developer Mistakes

1️⃣ Treating localStorage like a database

It’s not. It’s just key-value storage with limits (~5MB).

2️⃣ Storing large API responses

Bad idea. Memory + performance issues incoming.

3️⃣ Not handling null values

const user = JSON.parse(localStorage.getItem("user"));

If nothing exists → null → your app crashes later.

4️⃣ Using sessionStorage without understanding tabs

Each tab has its own sessionStorage.

Open a new tab → data is gone.

🚀 Best Practice Summary

✅ Use localStorage for small, persistent UI data like themes or preferences
✅ Use sessionStorage for temporary, tab-specific data
✅ Always JSON.stringify() before storing objects
✅ Always JSON.parse() when reading stored data
✅ Never store sensitive data like tokens or passwords

Reactions

Post a Comment

0 Comments