Storage Availability Detection

Web Storage availability is not guaranteed merely because `window.localStorage` exists. A robust application should test whether storage can actually be written and read, because privacy settings, browser policies, sandboxing, or quota restrictions can make the API unusable.

Feature detection should test the operation the application needs, not just the presence of an API property. Checking `"localStorage" in window` or reading `window.localStorage` only establishes that the interface is exposed; it does not prove that a write will succeed.

A practical approach is to obtain the storage object and perform a small write-read-remove cycle inside `try`/`catch`. A `setItem()` call can throw, commonly with a `DOMException`, when storage is blocked or unavailable. Removing the test key afterward prevents the probe from leaving application data behind.

The distinction matters because browser privacy modes, embedded contexts, sandbox restrictions, user settings, and storage limits can affect whether Web Storage is usable. In particular, third-party embedded content can face additional storage restrictions.

Applications should treat storage as an optional capability and provide a fallback when the probe fails. Depending on the requirement, that fallback might be in-memory state, cookies where appropriate, IndexedDB, or server-side persistence.

Key points

• Test actual storage operations rather than only checking whether the API exists.
• Wrap storage access in `try`/`catch` because reads or writes can fail.
• Use a temporary key and remove it after a successful probe.
• Treat Web Storage as an optional capability and provide an appropriate fallback.
• `localStorage` is scoped by origin, while `sessionStorage` is additionally scoped to a browsing tab.

Interview questions

Why isn't checking `window.localStorage` enough to determine whether local storage is available?

The property being present only tells us that the browser exposes the Web Storage interface. A browser or privacy policy can still prevent storage operations from succeeding. The application should attempt a small write and handle failure with `try`/`catch`. This lets the code detect practical usability rather than just API presence.

How would you implement a robust `localStorage` availability check?

I would access `window.localStorage` inside a `try` block, write a temporary key, read or otherwise validate the operation, and remove the key. If any part fails, I would return `false` rather than allowing the exception to escape. The probe should avoid overwriting application data and should clean up after itself. The result can then determine whether the application uses local storage or a fallback.

What browser conditions can make Web Storage unavailable or restricted?

Privacy settings and browser policies can restrict storage even when the API is exposed. Sandboxed documents and some third-party embedded contexts can also have additional restrictions. Storage operations can therefore fail at runtime. Code should avoid assuming that API exposure implies successful persistence.

Why should storage availability be treated as a capability rather than a guarantee?

Client-side persistence is controlled by the user agent and its policies, so an application cannot assume that a browser-exposed API will remain usable in every context. Capability detection makes the persistence layer resilient to those environmental differences. The application can then choose a suitable fallback based on whether persistence is required or merely an optimization. This also keeps storage failures from unnecessarily breaking core functionality.