Browser Storage and Web APIs

🎯Learning Objectives

A workshop form can collect data and an API loader can receive it, but neither automatically remembers a learner’s choices after the page reloads. Browser storage adds a local record with its own lifetime, failure modes and validation requirements. In this lesson, build a small study preference rather than treating the browser as a permanent database.

Compare ordinary JavaScript memory, localStorage, sessionStorage and cookies. Serialize a controlled record, load it defensively, remove only the record you own and describe when another document receives a storage event. You will also identify where other browser APIs belong in a larger application.

🧠Memory and Persistence Are Different Decisions

A variable or Map belongs to the running JavaScript environment. It is useful for a draft, a current selection or a temporary result. Reloading the document creates a new environment, so a new Map does not contain the old draft. Navigating away can also end that instance.

Persistence means putting data somewhere that can outlive the current script instance. It introduces another source of truth: the editor may contain unsaved changes while the stored record still contains an earlier value. Label Save and Load separately so learners can observe that distinction.

Our preference contains a topic, a study duration and a short note. The default lab mode is memory. Selecting localStorage or sessionStorage does not immediately read or write anything; the learner explicitly chooses an operation. This makes the persistence boundary visible instead of hiding it inside every keystroke.

const draft = new Map();
draft.set("study", "HTML for 15 minutes");
console.log(draft.get("study"));
// A freshly reloaded page creates a new Map.

Resetting form controls is a third action. A reset can restore editor defaults while leaving the saved value untouched. Deleting a saved value should be a clearly named operation, not an unexpected side effect of resetting the screen.

🗂️Compare the Four Storage Choices

Choose a mechanism from the behavior your feature needs. A temporary preview can use memory. A theme preference can use localStorage. A draft intended for one page session can use sessionStorage. A server-managed session commonly uses a cookie carrying a session identifier. These are different contracts, not a ranking from bad to good.

Web Storage values are not automatically attached to HTTP requests. Cookies can accompany matching requests subject to cookie rules and browser policy. A value saved locally is also not automatically synchronized to an account, another device or the server.

None of these choices guarantees that a record is correct merely because it exists. A preference written by an older application version may no longer match today’s fields. Treat persistence as a boundary where data must be checked again.

🌐Origins, Paths and Storage Scope

An origin combines scheme, host and port. For example, https://codebhavya.com and https://www.codebhavya.com have different hosts, so do not assume they share one localStorage area. HTTP and HTTPS are also different origins.

A pathname does not create a separate Web Storage namespace. Lessons under different folders on one origin may use the same localStorage area. A generic key such as data can collide with another feature. Use a descriptive application key and a record version.

A namespaced key prevents accidental collisions; it does not create an access-control boundary between scripts running with the same origin’s privileges. The lab therefore uses a fictional study note and never asks for credentials or confidential information.

const key = "codebhavya-wt19-storage-lab-v1";
// Same-origin paths can share this localStorage key.
// sessionStorage uses a different area for the same key text.

💾localStorage — Remember a Small Preference

The localStorage property gives access to a synchronous key/value store. Use setItem to write a string, getItem to read one and removeItem to delete a named entry. A successful write is available to later reads from the same applicable storage area.

Local data can survive reloads and restarts, but “local” does not mean guaranteed forever. Users can clear site data, private browsing has its own lifetime and browser policies can prevent access. A site must remain usable when a preference is missing.

In the lab, Save in local mode is the only preference-writing action. After a reload, select local mode again and press Load. The editor starts with defaults and does not silently import the old note. Delete this lab key when you finish the experiment.

try {
  const store = window.localStorage;
  store.setItem("study-topic", "html");
  const topic = store.getItem("study-topic");
  store.removeItem("study-topic");
} catch (error) {
  console.error("Preference storage unavailable", error.name);
}

This teaching snippet uses a separate example key. Do not run broad cleanup code on a shared site. Catch property access as well as method calls, since failure can occur before you obtain the Storage object.

🪟sessionStorage — A Page Session, Not a Login

Session storage is partitioned by origin and top-level browsing context, usually a tab. A reload within that page session can retain its values. Ending the page session clears its session storage; browser restoration behavior should not be treated as an application backup guarantee.

A newly opened page with an opener can start with a copy of the opener’s session storage. The two copies then evolve independently. A fresh independent tab and a duplicated or restored tab need not provide the same starting experiment.

SessionStorage is not the server’s authenticated session. Saving loggedIn = true cannot authenticate a user. The next lesson will connect server requests, sessions and server-side checks. Here, use session mode only to explore a local draft lifetime.

try {
  window.sessionStorage.setItem("draft-topic", "css");
  console.log(window.sessionStorage.getItem("draft-topic"));
} catch (error) {
  console.error("Draft storage unavailable", error.name);
}

For a controlled browser check, reload the same tab and Load the lab key. Then compare with an independently opened tab. Describe how you opened it before concluding that session data is shared.

🔤Strings, JSON and Missing Values

Storage keys and values are strings. Passing a plain object directly to setItem does not preserve its useful field structure. Serialize a simple record with JSON.stringify, and parse retrieved text with JSON.parse.

GetItem returns null when a key is absent. The stored string "null" is a present value that parses into null; an empty string is another present value. Check absence before parsing rather than using a truthiness check that mixes these cases.

JSON cannot preserve every JavaScript value. Functions, undefined fields, cyclic objects and special class instances need separate decisions. A small record made only of strings and ordinary numbers is a good starting contract.

const preference = {
  version: 1, topic: "html", minutes: 15, note: "Review forms"
};
const text = JSON.stringify(preference);
// After reading: distinguish null from stored text.
if (text !== null) {
  const parsed = JSON.parse(text);
  console.log(parsed.topic);
}

The text variable above represents serialization, not an actual storage read. In a real loader, obtain raw text from getItem inside the error-handling boundary. Parsing can throw, and a successful parse still needs the next section’s validation.

✅Validate the Record and Its Version

Our exact record contract is {version, topic, minutes, note}. Version must be numeric 1. Topic must be html, css or javascript. Minutes must be numeric 15, 30 or 45. Note must be a string whose trimmed length is at most 160 characters; an empty note is allowed. Unexpected fields are rejected so the exercise has one explicit shape.

The editor converts its known duration select value into a number before validating. Loaded JSON does not receive that conversion: the string "30" is rejected. This difference helps distinguish deliberate input normalization from blindly repairing stored data.

The loader limits raw text to 4096 characters before parsing and checks the whole record before replacing any editor field. Malformed JSON, an unknown version or a wrong shape leaves unsaved editor content intact. The learner can inspect the raw text and deliberately delete the lab record if needed.

if (record.version !== 1) throw new Error("Unsupported version");
if (![15, 30, 45].includes(record.minutes)) {
  throw new Error("Invalid study duration");
}
// Also check object shape, topic and bounded note.
// Only then update editor fields.

A production migration should explicitly convert an old supported version into the new contract and validate the result. Do not claim to migrate a record by ignoring its version. The JSON checker below validates pasted examples without writing them to browser storage.

🛠️Denied Access, Quotas and Honest Feedback

Storage can fail because access is denied or a write cannot be accommodated. Existence of window.localStorage is not proof that a specific write will succeed. Keep the read or write in try/catch and report the outcome of the operation actually attempted.

The lab has two clearly labeled simulations. Blocked access throws a SecurityError before using the selected backend. Quota failure throws a QuotaExceededError only for Save; Load, Inspect and Delete can still operate. These switches do not change browser settings or fill real storage.

Native browser errors are also caught. A failed Save must not announce success, erase the previous record or silently write into another backend. The editor remains available, so the learner can choose memory explicitly if persistent storage is unavailable.

try {
  store.setItem(key, JSON.stringify(validated));
  showStatus("Saved in the selected storage area.");
} catch (error) {
  showStatus("Save failed: " + error.name);
}

Avoid a misleading “saved” message before setItem returns. Storage failure and validation failure need different descriptions: one concerns the backend, while the other concerns the attempted data.

🔑Delete One Key and Keep Other Features Intact

A website can store theme choices, completion markers and unrelated feature records in one origin’s area. RemoveItem(key) deletes the named entry. Storage.clear() removes every entry in that area and is inappropriate for a lesson’s cleanup button.

The lab uses one key in each selected backend. Delete in local mode does not delete the session-mode record, and resetting editor fields does not delete either. The memory record is independent as well. This gives three observable locations for the same named preference.

Inspect shows bounded literal text with textContent. It does not insert stored notes as HTML. A note containing angle brackets should remain visible text rather than creating a new element.

store.removeItem("codebhavya-wt19-storage-lab-v1");
// Preserve unrelated keys, including course completion.
output.textContent = rawText;
// Display saved text as text, rather than HTML.

Deleting a missing key is harmless. Still report the selected area so a learner understands why a record in another backend remains. Do not imply that deleting this key clears all personal data on the site.

🔔Storage Events and Unsaved Work

A storage event informs other documents that share the changed storage area. The document performing a change does not receive its own event. Local storage changes can notify other same-origin tabs; session storage notifications stay within the same top-level context, such as a same-origin iframe in that tab.

The event includes key, oldValue, newValue and storageArea. A key of null can represent a clear operation. Filter by the storage area and the key your feature owns. Receiving an event about a different feature is not a reason to reload this preference.

The lab listens only for relevant localStorage events while local mode and normal access are selected. It announces that the saved record changed elsewhere and offers Load. It does not automatically replace unsaved editor fields. Concurrent updates still need an application conflict policy; this exercise uses explicit Save and Load.

window.addEventListener("storage", event => {
  if (event.storageArea !== window.localStorage) return;
  if (event.key !== key && event.key !== null) return;
  showStatus("Saved data changed elsewhere. Load to inspect.");
});

A single-tab test cannot demonstrate a native cross-tab notification. Open the deployed lesson in two same-origin tabs, select local mode in both and save a changed record in one. Check the other tab’s notice before deliberately loading it.

🍪Cookies — Data Attached to Matching Requests

Cookies serve a different purpose from a local preference store: they can accompany HTTP requests according to domain, path, expiry and browser policy. A server can set them with the Set-Cookie response header. A server session cookie often carries an opaque identifier while the server keeps session data.

Secure restricts transmission to secure contexts such as HTTPS. HttpOnly prevents JavaScript from reading the cookie. SameSite governs cross-site sending behavior; SameSite=None requires Secure. These settings address different concerns and do not replace server validation.

JavaScript cannot set an HttpOnly cookie using document.cookie. Avoid putting passwords or a trusted authentication decision in a study preference. The lab does not create cookies or implement login; it compares their role with browser-side storage.

Set-Cookie: session_id=opaque-example; Path=/; Secure; HttpOnly; SameSite=Lax

This line illustrates an HTTP response header, not JavaScript to paste into the lab. A real server must create, validate and expire session identifiers correctly. Cookie attributes should match the application’s intended request flow.

🧰Other Browser APIs — Choose by the Task

The browser offers many capabilities beyond string storage. IndexedDB is suitable for larger structured collections and asynchronous database operations. The Cache API handles stored request/response pairs. Neither is simply another spelling of localStorage, and both require a deliberate lifecycle and error strategy.

URL and URLSearchParams help construct and inspect URL data. History APIs change navigation state, not permanent account data. Clipboard and geolocation capabilities bring permission and context requirements that vary by API and browser. Check a capability’s contract before using it.

Match the feature to the data: a short display preference can remain in Web Storage, a substantial offline collection may need IndexedDB, and downloaded resources may belong in a caching strategy. A server remains responsible for authoritative shared records.

This lesson introduces these alternatives; its interactive exercise deliberately stays with one tiny string record. Implementing a complete offline database or service worker would require its own lesson and tests.

🛡️Privacy and Trust Boundaries

Minimize the data a feature keeps. A fictional study topic and duration are enough to learn the mechanics. Do not ask learners to put passwords, payment information or confidential notes into a storage demonstration. Explain how to remove the demonstration record.

Same-origin script access means localStorage is not a secret vault. A successful parse, a stored completion flag or a local boolean does not prove identity, permissions or ownership on the server. Trusted decisions must be checked at the relevant authority.

Render accepted notes as text. Validate records loaded from storage just as you validate a response from an API: they can be old, manually modified or produced by another script. Keep deletion narrow and expose failure clearly.

A real product may have consent and retention requirements based on its purpose and jurisdiction. A storage API alone does not decide those requirements. The exercise demonstrates explicit user actions without claiming that it establishes a complete privacy policy.

🧭Design the Save and Load Lifecycle

Separate editor state from saved state. On Save, validate all fields, serialize the accepted record and write it to the selected backend. Announce success only after the write returns. On Load, check for absence, parse bounded text, validate the contract and then update the editor together.

On failure, preserve the draft and identify the failed stage. On Reset fields, restore the editor defaults and clear its display output while leaving the saved record intact. On Delete, remove only the owned key from the selected backend.

The visualizer follows a normal Save then Load journey. The lab lets you introduce missing data, failed access, failed writes and bad JSON separately. These paths are part of the feature, rather than exceptional details to add after the happy path is finished.

Before marking complete, reproduce the failure paths and explain why they do not overwrite the editor or remove unrelated site records. Then compare memory loss on reload with the selected browser storage lifetime.

🧪Premium Interactive — Study Preference Storage Lab

Memory mode is the default and lasts only for this page instance. Local and session modes use the real browser storage areas when available. Select a backend, edit a fictional preference and explicitly Save or Load. No preference is automatically read or written when you switch modes.

The single key is codebhavya-wt19-storage-lab-v1. Delete removes only this key from the selected backend. Reset fields restores editor defaults without deleting saved data. Use a short fictional note, then delete the lab key from local and session modes when finished.

Failure switches simulate blocked access or a quota failure without changing browser policy or filling storage. Native errors are also caught. The separate JSON checker validates pasted text without writing it into any storage area.

No operation yet.

No JSON checked yet.

🛠️Debugging — Find the Storage Boundary

If the editor returns to defaults after reload, select the original backend and Load. Memory cannot recover an earlier script instance. If a stored record is present but fails validation, inspect the raw value and the expected version instead of overwriting the current draft.

If another tab does not show a notice, check that both pages have the same origin, local mode is selected and a value actually changed. Session storage is not a cross-tab message bus. An event caused by another feature should not reload this editor.

If Reset seems not to erase data, that is its intended contract: Reset fields keeps the saved record. Use Delete this lab key in the selected backend and then Load to observe the missing outcome.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Choose the Storage Behavior

💻Extra Practice — Observe Specific Storage Outcomes

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — A Defensive Preference Store

Build a study preference with an explicit backend selector and separate Save, Load, Delete and Reset fields actions. Start in memory. Use one namespaced key in each browser storage area and keep a numeric record version.

Validate before writing and again after reading. Distinguish absence from malformed text and a wrong contract. Preserve the draft on failure and report real backend failures without silent fallback. Show raw saved data as literal text.

Demonstrate normal round trips, reload lifetimes, blocked access, quota failure and invalid JSON. Keep unrelated site keys intact. In a deployed browser, check a two-tab local change notice without replacing unsaved work. Delete the demonstration key after the experiment.

Success criterion: explain where data lives, when it can disappear and why saved text is still untrusted input. Level 20 will introduce server-side execution and application flow.