Browser Storage

Overview

There are 3 primary places in a web browser where developer can store data: Local Storage, Session Storage and Cookie. Think of them as 3 different types of “lockers” in the browser’s basement. They all store strings of text, but they have different rules for how long they stay there and who can access them.

Prerequisite Knowlege

We read domains from right to left to determine their level of authority.

• . (The Root): Technically, there is a “dot” at the very end that we don’t usually type (e.g., google.com.). This is the absolute root of the internet.
• Top-Level Domain (TLD): This is the .com part
  • Examples: .com, .org, .gov, or country code like .us or .en.
• Second-Level Domain (SLD): This is google part.
  • This is what we officially “own” and register.
• Subdomain: This is anything to the left of the DLS, like portal or api.
  • We have full control over these once we own the SLD.

Term	Components	Example
TLD	Top-Level	.com
Root Domain	SLD + TLD	google.com
FQDN	Subdomain + SLD + TLD	portal.google.com
Origin	Protocol + FQDN + Port	https://portal.google.com:443

Local Storage (The Permanent Locker)

• Persistence: It stays there forever (or until the user manually clears their browser cache). Even if you close the tab or restart you computer, the data remains.
• Capacity: Largest (usually around 5MB – 10MB per Origin).
• Access: Only JavaScript on your website can read/write to it.
• Use-Cases: Use this for “Set it and Forget it” data that doesn’t need to be sent to the server but should survive a computer restart:
  • User UI Preference
    • Example: Dark Mode vs. Light Mode toggle, sidebar collapsed/expanded state, or language preference.
    • Why: You don’t want to waste server bandwidth sending “Dark Mode” on every API request, but you want the user to see their preferred theme the second they open the page.
  • Auto-Save Drafts
    • Example: A long form in a system. If the user accidentally closes the tab while entering an invoice, you can “recover” their text from Local Storage.
    • Why: It has a large capacity (5MB+), allowing you to store thousands of words of text safely.
  • Performance Caching
    • Example: Storing a list of “State/Province” names for a dropdown menu.
    • Why: These rarely change. Storing them locally saves a network call to the database every time the user opens a “Contact” form.

Session Storage (The Tab-Specific Locker)

• Persistence: It only lasts as long as the browser tab is open. As soon as you close that specific tab, the data is wiped out.
• Capacity: Also Large (around 5MB per Tab + Origin).
• Access: Only Javascript on that specific tab can see it. If you open the same website in a second tab, it gets its own fresh, empty Session Storage.
• Use-Cases: Use this for data that should only exist while the user if performing a specific, one-time task in a single tab:
  • Multi-step Wizards/Workflows:
    • Example: A 5-step registration or checkout process. Data from Step 1 is saved in Session Storage to be used in Step 4.
    • Why: If the user opens the same website in a second tab to start a different registration, the data won’t collide. Once they close the tab, the “half-finished” data is wiped for privacy.
  • Scroll Position Restoration
    • Example: Remembering exactly how far down a user scrolled on a long product list so that when they click “Back” from a detail page, they return to the same spot.

Cookies (The “Traveling” Locker)

• Persistence: You can set an expiration date (e.g., “Delete this in 1 hour”). If no date is set, it’s deleted when the browswer closes.
• Capacity: Tiny (only about 4KB per Cookie and 10-80 KB per Domain, here domain can be root domain or FQDN, depending on our settings, but default is FQDN). You can’t store much here.
• The “Killer Feature”: Unlike the other 2, Cookies are sent to the server automatically with every HTTP request.
• Use-Cases: Use this for anything the Server needs to know about user’s identity or state:
  • Authentication & Session Management
    • Example: Storing an Auth0 session ID or a “Remember Me” token.
    • Why: When set to HttpOnly, these are invisible to hacker’s scripts (preventing XSS). Because they are sent automatically with every request, the server always knows who is asking for data.
  • Cross-Subdomain SSO (Single Sign-On):
    • Example: Logging in at portal.google.com and being automatically recognized at api.google.com.
    • Why: By setting the Domain=google.com, the cookie “travels” across all subdomains. Neither Local Storage nor Session Storage can do this.
  • Server-side Personalization:
    • Example: Knowing a user is a “Premium Memeber” so the server can render a different HTML header beforethe page even loads.

HttpOnly Cookies

• HttpOnly is a special security flag you add to a cookie when the server creates it.