Storage Quotas in Web Storage

Browsers impose implementation-dependent limits on Web Storage, so applications cannot assume unlimited `localStorage` or `sessionStorage`. A write can fail when the applicable storage limit is exceeded, commonly by throwing `QuotaExceededError`.

Web Storage provides the `localStorage` and `sessionStorage` APIs for storing string key-value pairs in the browser. `localStorage` generally persists across browser sessions for an origin, while `sessionStorage` is associated with a page session.

Storage capacity is controlled by the browser and can vary by implementation, environment, origin, and storage type. Therefore, frontend code should not hard-code an assumption such as a universal maximum number of megabytes.

A call such as `localStorage.setItem()` can fail if storing the new value would exceed the available quota. Code that depends on successful persistence should handle this failure rather than assuming every write succeeds.

The typical failure is represented by `QuotaExceededError`. A robust application can catch the exception, reduce or remove stored data, fall back to another strategy, or tell the user that persistent storage is unavailable.

Because Web Storage stores strings, serialized objects can also consume substantially more space than their original in-memory representation. Large application caches are usually better suited to storage mechanisms designed for larger structured datasets, such as IndexedDB.

Key points

• Web Storage capacity is browser-dependent rather than a single universal constant.
• `localStorage.setItem()` can throw `QuotaExceededError` when a write cannot fit.
• Storage values are strings, so objects normally require serialization.
• Production code should handle storage failures instead of assuming writes always succeed.
• Use IndexedDB or another appropriate storage mechanism for larger structured client-side data.

Interview questions

How would you safely store an object in Web Storage?

Web Storage values are strings, so an object is commonly converted with `JSON.stringify()` before calling `setItem()`. When reading it back, `JSON.parse()` can reconstruct the object. Both serialization and storage operations can fail, so production code should validate the data and handle exceptions where appropriate. Large serialized objects also consume storage space.

What is a storage quota in Web Storage?

A storage quota is the amount of client-side storage the browser permits an application to use for a particular storage mechanism or origin. For Web Storage, the exact capacity is implementation-dependent rather than guaranteed by one universal number. If an application attempts to store data beyond the available limit, the write can fail. Frontend code should therefore treat storage as finite and handle failures.

What happens when `localStorage.setItem()` cannot fit the new value?

The write can throw a `QuotaExceededError`. Code should catch the exception when persistence is important and decide how to recover. Recovery might involve deleting obsolete cached data, reducing the amount stored, or using another persistence mechanism. The application should not assume that a storage write always succeeds.

Why shouldn't a frontend application assume that Web Storage has a fixed number of megabytes available?

Web Storage capacity is determined by the browser implementation and execution environment, so a single hard-coded capacity is not a reliable cross-browser contract. Available space can also depend on the storage context and current usage. A robust application should design around the possibility of failure instead of relying on an exact quota. If it needs substantial storage, it should consider a more suitable browser storage API.