Web Storage QuotaExceededError

A Web Storage `setItem()` call can throw `QuotaExceededError` when the requested write cannot fit within the storage available to that storage area. Frontend code should treat storage writes as fallible rather than assuming `localStorage` or `sessionStorage` always accepts data.

Web Storage provides synchronous key-value storage through `localStorage` and `sessionStorage`. Values are stored as strings, and browsers impose implementation-defined storage limits rather than guaranteeing unlimited capacity.

When `setItem()` cannot complete because the storage area cannot accommodate the new data, the operation can throw a `QuotaExceededError` DOMException. The exception is raised during the write, so checking the approximate size beforehand is not a reliable substitute for handling the actual operation.

A robust frontend pattern is to wrap the write in `try...catch` and handle `QuotaExceededError` explicitly. Depending on the application, recovery might mean removing stale cached entries, reducing the stored payload, falling back to in-memory state, or informing the user that persistence is unavailable.

Storage writes can also fail for reasons other than quota in some browser environments. Therefore, production code should avoid assuming that every storage failure represents a full storage area; inspect the exception and application context before deciding how to recover.

Key points

• `setItem()` can throw `QuotaExceededError` when a write cannot fit in the storage area.
• Web Storage stores values as strings and has finite browser-managed capacity.
• Handle storage writes with `try...catch` because capacity cannot safely be assumed.
• A quota failure can require eviction, smaller data, or a non-persistent fallback.
• Do not make application correctness depend exclusively on Web Storage succeeding.

Interview questions

What is `QuotaExceededError` in Web Storage?

It is a DOM exception that can occur when a Web Storage write cannot fit within the storage quota available to that storage area. A common trigger is calling `setItem()` after the storage area has insufficient capacity. The write does not silently truncate the value; application code should handle the failure. The appropriate recovery depends on whether the data is essential, cacheable, or disposable.

How should a frontend application handle a storage write that throws `QuotaExceededError`?

Wrap the storage operation in `try...catch` and identify the exception before applying quota-specific recovery. If the data is cacheable, the application can remove older entries and retry or store less information. If persistence is optional, an in-memory fallback can preserve functionality for the current page lifetime. Important user data should not be silently discarded merely because storage is unavailable.

Why isn't checking available storage space before `setItem()` sufficient?

A capacity estimate is not a guarantee that a later write will succeed. Storage conditions can change between the check and the write, and browser storage behavior is not something application code should treat as a fixed byte budget. The authoritative operation is the actual write. Therefore, code should still catch failures around `setItem()` even if it performs a size estimate.

What are the trade-offs of using Web Storage for application state?

Web Storage is convenient for small string-based state because its API is simple, but its synchronous operations can block the main thread and its capacity is limited. It also provides no built-in query model for structured records and is not a good substitute for a general client-side database. Applications should therefore keep persisted data small and non-critical where possible. Larger or structured datasets are better candidates for IndexedDB or another purpose-built persistence layer.